Nextcloud S3 object storage and external storage guide

Nextcloud S3 object storage or external mounts: which fits your data

Choose primary storage before the first user uploads a file. For most organizations that want all file content kept inside their own infrastructure, the decision is between the local data directory and S3-compatible object storage used as Nextcloud primary storage. External storage mounts are a different tool: they expose existing file systems or object stores inside Nextcloud without making them the place where Nextcloud keeps its own files. The choice shapes backup design, performance, recovery and how hard a later change will be, so it should be settled in the design phase rather than treated as a setting to revisit. The three options work differently. The local data directory stores each file as a regular file on a file system that the Nextcloud server mounts, which is the simplest model to back up and troubleshoot with standard tools. S3-compatible primary object storage stores file content as objects in a bucket managed by Nextcloud, which suits large volumes and horizontally scaled app servers but adds a dependency on the object store's availability, latency and credentials. External storage mounts connect Nextcloud to existing shares, SMB or NFS locations, or buckets, so users can browse and share content that stays under another system's control. Each option runs inside your own cloud account, data center or air-gapped network, so the decision concerns control, performance and operations, not where the data is hosted. The choice is hard to reverse. Primary storage is set during installation, and moving file content from one primary backend to another later is a migration project with its own verification, downtime planning and rollback steps. The database still holds file metadata in every option, including paths, ownership, shares, versions and encryption state, so a storage change never removes the database from the design. Metadata and content must stay consistent, which means a move that copies bytes without updating the database, or the reverse, can leave users with missing or orphaned files. Before you decide, confirm several points with your Nextcloud partner or the current Nextcloud admin documentation: which S3-compatible service you will use and whether it meets your durability and locality requirements, how the data directory will be backed up while the instance runs, whether your chosen encryption approach works with object primary storage, and how external mounts will authenticate and log access. Write these answers into your design record. They determine whether you need one storage model for all users or a primary store plus targeted mounts for departmental content.

What stores Nextcloud files, metadata and mounted data

A Nextcloud deployment spreads its state across several places: a database, a primary storage backend, a configuration directory and any external mounts. Each holds a different kind of data, and a restore is only consistent when these parts are backed up and recovered together.

The database holds metadata

The database records file metadata, shares, users, groups and file locks. Files in the primary storage are not readable as a set without it, so a database restored from a different point in time than the file store can show shares or file listings that no longer match the content. Confirm the database engine and version against the Nextcloud 35 system requirements or the release you will run, and plan replication or dump scheduling accordingly.

Local data directory as primary storage

With local primary storage, file contents sit in a data directory on the server's filesystem, alongside Nextcloud's own working files. Backups of that directory must be taken in step with the database so that metadata and content agree. Check disk capacity, filesystem permissions for the web server user and how the directory is mounted, since these determine performance and recovery effort.

S3-compatible bucket as primary storage

With an S3-compatible bucket as primary storage, file contents are stored as objects while the database still holds the metadata that maps users and paths to them. Ask your storage provider how it handles object versioning, retention, replication and consistency, and confirm the bucket settings and object storage keys in the Nextcloud admin manual for your version. Do not assume a bucket snapshot covers the database.

Configuration directory holds secrets

The config directory contains the instance configuration, including database credentials, the instance secret, the trusted domains list and the storage configuration. Losing it, or restoring an old copy, can stop the instance from starting or make encrypted or stored data unreadable. Treat it as sensitive, restrict access, and back it up alongside the database and primary storage every time.

External storage mounts expose other systems

External storage mounts make systems such as SMB shares, SFTP servers or other object stores appear as folders inside Nextcloud. The files stay in the source system, so Nextcloud backups do not protect them, and the source system's permissions, availability and latency affect users directly. Identify which mounts are enabled, who may create them, and which backup regime covers the external source.

Back up the parts together

Because metadata, content, configuration and mounted data each live in different places, a restore is a coordinated operation rather than a set of separate copies. Agree a backup point that captures the database, primary storage and config directory consistently, often with maintenance mode during the capture, and test a restore against that point. Confirm the exact procedure for your release in the Nextcloud admin manual and in any backup tool you adopt.

Which storage model fits your data, users and recovery needs

This table compares local primary storage, S3-compatible primary storage and external storage mounts in Nextcloud. Read each row as a question to answer for your own data, then use the hybrid row to see where the models can be combined. The main takeaway is that the storage model shapes backup, encryption, performance and migration effort, so it should be settled before the first user is onboarded.

Decision factor	Local primary storage	S3-compatible primary storage	External storage mounts
When it fits	Moderate data volume, a team that runs its own file server or VM disks, and no existing object platform to reuse	Data volume growing faster than local disks can be added, or an existing S3-compatible platform the organization already operates and backs up	Data already on file servers or in another system that must stay there, with users needing access through Nextcloud without a bulk copy
Data volume growth	Capacity depends on attaching and expanding disks on the app host or storage network; confirm growth limits with your storage team	Capacity is managed in the object platform, which is often separate from the application servers; confirm the platform's scaling and billing model	Growth happens in the source system, so Nextcloud does not own its capacity planning; confirm quota and performance behavior with that system's owners
Backup coordination	Data directory, database and config must be captured together and kept consistent, typically with maintenance mode during the backup window	Object data and database must be backed up together, and bucket versioning or replication needs confirmation with the object platform team	Nextcloud does not hold the source data, so backups depend on the external system; confirm that Nextcloud metadata and the external source are both recoverable
Performance dependencies	Depends mainly on local disk and network throughput to the app host and database	Depends on network latency and throughput to the object endpoint, which affects previews, uploads and sync	Depends on the speed and availability of the external system and the protocol used to reach it; latency often becomes visible in sync clients
Encryption model	Server-side encryption options and disk-level encryption are configured on the host; confirm the key management approach with your security team before go-live	Encryption depends on the object platform and Nextcloud configuration; confirm which keys hold the data and who can access them	Encryption at rest is controlled by the external system, so Nextcloud encryption settings may not cover that data; confirm before sharing sensitive content
Migration effort later	Moving to object storage later requires a planned data copy and metadata consistency check, with downtime planning for the cutover	Moving back to local or to another object platform requires a planned copy of objects and database references, with a tested rollback path	Changing the source system or path changes mount definitions and permissions; plan the change with the source system owners and test with a pilot group
Hybrid designs	Local primary storage with selected external mounts for shared departmental folders that must remain on existing file servers	Object primary storage with external mounts for legacy archives, provided ownership of each data set is clear	Confirm which data is primary and which is referenced, so that backup scope, sharing rules and encryption responsibilities do not overlap
Record the choice	Record the storage model, data locations, backup owner and encryption owner in the design document before the first user is onboarded	Record the bucket design, endpoint, backup owner and encryption owner in the design document before the first user is onboarded	Record each mount, its source owner, permission model and recovery responsibility in the design document before the first user is onboarded

How to configure S3 primary storage in Nextcloud safely

This sequence takes a team from version and database checks through a dedicated, TLS-protected bucket to a tested Nextcloud instance with S3 primary storage, verified backup and restore, before any real users arrive. Each step ends with a check that tells you whether to continue.

Confirm version, database and PHP requirements
The platform engineer checks the Nextcloud version you intend to run against the official system requirements for that release, including the supported database, PHP version and web server. Confirm the current release and its end-of-life date in the maintenance and release schedule before you commit, because a major version is supported for only one year. Use the figures published for the exact version you select: for Nextcloud 35, the requirements page recommends MariaDB 11.8 or PostgreSQL 18, PHP 8.5 and Apache 2.4 or nginx with php-fpm, with other versions listed as supported. Done when you have a written version and database pair that the requirements page lists for that release, and the owner has signed off on the support window.
Provision a dedicated bucket and scoped credentials
The storage or cloud engineer creates a bucket used only by Nextcloud, in the region and with the redundancy your data policy requires, and creates a separate access identity for it. Grant that identity only the object actions Nextcloud needs on that bucket, and no account-wide or administrative permissions. Confirm in the admin manual for your version which bucket and object permissions the primary storage configuration expects, and in your provider's documentation which actions a list, read, write and delete policy requires. Done when the identity can read and write objects in the bucket and is denied access to any other bucket in a test call.
Place the S3 endpoint behind valid TLS
The network or platform engineer makes the S3-compatible endpoint reachable only over HTTPS, with a certificate issued by a trusted authority and a hostname that matches the configuration. Confirm the endpoint, path-style or virtual-host addressing and region options your storage product supports, and check the admin manual for how the Nextcloud configuration accepts a custom endpoint and certificate trust. Plain HTTP or a self-signed certificate that is accepted without verification is a finding to fix before go-live. Done when a request from the Nextcloud application host succeeds over TLS, and a request with an untrusted certificate fails.
Configure primary storage in a test instance
The Nextcloud administrator builds a separate staging instance on the chosen version and database, then sets the S3 object store as primary storage using the bucket, endpoint, region and credentials from the earlier steps. Do not use the production configuration or production credentials here. Confirm the exact configuration keys and their behavior in the admin manual for your version, since names and options change between releases. Keep the local data directory location and the database connection documented, because both still hold metadata and must be backed up. Done when the instance starts, the admin page reports no storage errors, and a new object appears in the bucket after a test file is saved.
Run a test upload, sync and share
A tester creates two test accounts in staging and runs an upload through the web interface and a desktop or mobile client, then shares the file from one account to the other, including a public link with a password. Confirm the file lands in the bucket under the expected storage layout and that the recipient can open and download it. Check the share permissions and expiry behavior that your version supports. Done when the upload, client sync, internal share and public link all complete, and the object count in the bucket matches the files visible to users.
Confirm previews, trash and versions
The tester checks that previews generate for images and documents, that deleted files move to the trash and can be restored, and that file versions behave as expected. Confirm in the admin manual for your version how previews and trash are stored and expired when primary storage is object storage, because retention and cleanup jobs can differ from local disk. Confirm background job scheduling is set to cron as documented for your version. Done when a preview appears in the browser, a deleted file restores from the trash, and a version can be restored, with the results recorded.
Test backup and restore before onboarding users
The platform team backs up the staging database, configuration and bucket contents using the method your organization uses for object storage, then restores them into a separate instance and confirms that files and shares are intact. Check how the admin manual describes consistent backups, including maintenance mode during the database and configuration copy. Record the restore steps and who runs them. Done when the restored instance serves the test files and shares and the restore runbook has been reviewed by someone other than its author, which is the gate for onboarding real users.

How storage design changes on single node, clustered and air-gapped sites

On a single Nextcloud server, primary storage usually sits on the same host or attached volume as the application, so the data directory, the database and the configuration are tightly coupled. An S3-compatible primary store adds a second service that must be running, reachable and backed up, which is often more than a single-server team wants to operate. External storage mounts add the same kind of dependency, but for only a subset of users or folders.

What changes in this model:

Placement: Local disk keeps the fewest moving parts. If object storage is chosen, decide whether it runs on separate hardware or on the same host, and confirm that the host has capacity for both.
Backups: One host means one backup job must capture the data directory or bucket, the database and the config together, with maintenance mode used for a consistent copy.
Endpoint reachability: The object endpoint is usually local and not exposed. Confirm that only the Nextcloud process can reach it and that firewall rules match that intent.
Upgrades: Each major version is applied to one host, with a backup taken first. Confirm that the object store version is compatible with the release plan.
Confirm with the platform team: who restores the object store, how long a restore takes on this hardware, and whether the same host can absorb the extra I/O during preview generation and background jobs.

Before committing, ask the platform team to describe the restore path for each data type on this one host, not only the backup schedule.

What drives the cost and effort of object storage work

This table lists the factors that change how much work an S3 object storage or external storage project takes, and what each one means for the scope you request. Read each row as a question to answer before asking for a quote. Most of the effort that recurs after go-live comes from the rows on backup, restore testing and key management.

Driver	Why it changes effort or cost	What to ask for in a written scope
Number of users and expected data volume	Larger user counts and data sets increase bucket sizing, capacity planning, object lifecycle work and the time needed for initial data load. Growth after go-live adds ongoing capacity management.	Named user count, current and projected data volume, growth assumptions, and who owns capacity forecasts after handover.
Number of existing sources to mount or migrate	Each external storage mount (SMB, NFS, WebDAV, other S3 buckets) needs its own connection, permission mapping and testing. Migrating data into object storage adds copy, verification and cutover steps per source.	A list of each source with protocol, size, owner and whether data moves or is only mounted, plus the verification method for each.
Existing S3-compatible service	If an S3-compatible service already runs, the work shifts to configuration, access policies and capacity review. If none exists, the scope includes selecting, deploying and operating the service itself, which is usually a larger effort.	Confirmation of the current service, version, owner, capacity and support model, or the decision and deployment scope for a new one.
Environments (development, test, production)	Each environment needs its own buckets, credentials and configuration. Keeping them consistent and running the same restore and upgrade tests in each adds repeated effort.	The environments in scope, how configuration is promoted between them, and whether test data is masked or synthetic.
Encryption and key management	Server-side encryption with keys managed by the organization requires a key store, access rules, rotation procedures and documented recovery. Client-side or external key requirements add further design and testing work.	Encryption model, key custodian, key store location, rotation schedule, and the procedure for key loss or compromise.
Retention, lifecycle and restore testing	Retention rules and object lifecycle policies must match legal and business requirements. Restore testing is repeated work: each test needs a documented scenario, a run and a recorded result. Frequency drives recurring effort.	Retention periods by data type, restore test scenarios and frequency, who runs tests, and where results are recorded.
Identity and access integration	Linking the object store to directory or SSO identities for access control, and mapping groups to buckets or mounts, adds configuration and testing. Deprovisioning must be verified for stored data as well as application access.	Identity provider in use, group-to-storage mapping rules, provisioning and deprovisioning process, and who approves access changes.
Backup tooling integration	Object storage changes how backups are taken. Consistent backups of Nextcloud data, database and object storage may need coordinated jobs, snapshot or versioning settings, and a separate copy outside the primary store. Each backup job adds monitoring and recurring checks.	Backup tool and target, the consistency method used across database and object data, retention of backup copies, and monitoring responsibilities.

How to protect object storage credentials, data and encryption

Object storage gives Nextcloud a durable primary store, and it also gives anyone holding its credentials a direct path to every file. The cards below cover the controls that keep that path narrow: who can reach the bucket, how keys are kept out of plain sight, how traffic is protected, and where encryption happens and what it costs in features.

Dedicated service account per bucket

Create a separate storage identity for Nextcloud, scoped to one bucket with only the object actions the primary store needs. Do not reuse root keys, administrator keys or keys shared with backup jobs or other applications. Ask the storage team to confirm that the account cannot list or modify other buckets, and record who holds the credential and how it is rotated.

Least privilege for object actions

Grant only the permissions Nextcloud needs to read, write, list and delete objects in its bucket, and test them against a non-production bucket before go-live. Avoid bucket policies or administrative rights that allow changing lifecycle, versioning or access settings from the application side. Review the policy again after each Nextcloud major upgrade, since new app behavior can need additional actions.

Keeping storage secrets out of plain config

Access keys and secret keys should not sit in readable files shared through version control, tickets or general administrator access. Decide whether they live in environment variables, a secrets manager or a protected config file with restricted permissions, and confirm that Nextcloud's config, container definitions and backup archives do not expose them in clear text. Agree on a rotation procedure that includes a planned restart and a check that uploads still succeed.

TLS to the storage endpoint

Nextcloud should reach the S3-compatible endpoint over HTTPS with certificate validation enabled, using a certificate issued by a CA the Nextcloud host trusts. Disabling verification to get a connection working hides a man-in-the-middle risk on the path that carries every file. Confirm the endpoint's supported TLS versions and cipher policy with the storage vendor, and plan certificate renewal so that expiry does not silently stop file access.

Network reachability limits

Restrict which hosts can reach the object storage endpoint, ideally allowing only the Nextcloud application and worker servers on a private network path. Users should never connect to the bucket directly, so access stays mediated by Nextcloud's authorization and logging. Check that background jobs, preview generation and backup tooling each run from approved sources, and document any egress rules needed for external storage mounts.

Server-side encryption at the Nextcloud layer

Nextcloud server-side encryption encrypts file content before it is written to the bucket, so the storage provider holds only ciphertext. It protects against a storage operator or a leaked bucket, but it also restricts server-side search, previews and some sharing or external access, because the server must handle decryption keys. Treat it as a design decision with a trade-off review, and use the Nextcloud security hardening topic for the full assessment of its effects.

Encryption at the storage layer

Encryption at rest in the object store protects stored objects without changing how Nextcloud reads and indexes files, so search, previews and most client features keep working. It does not stop a user or process with valid Nextcloud or storage credentials from reading content. Ask the storage vendor how keys are managed, who can access them, and whether key rotation can be done without re-uploading every object.

How to test that Nextcloud object storage works and fails safely

The test plan for Nextcloud object storage should prove two things before users rely on it: that everyday file behavior works end to end on the object store, and that a failure in the bucket, the credentials or the network produces a clear error instead of silent data loss or writes to an unexpected place. Run the functional tests against the same configuration you will operate, meaning the same primary storage or external mount type, the same endpoint and TLS settings, and the same service account, not a convenience test setup. Each test should have a named owner, an expected result written down in advance, and a recorded outcome. The functional set should cover upload and download through the web interface and WebDAV, a large file upload that exceeds your reverse proxy and PHP limits so that chunked uploads are exercised, and sync client behavior on at least one desktop and one mobile client, including a conflict and a rename. Create a share with a link and a share to an internal user, then open the link as an external recipient who has no account. Check previews and thumbnails for common types, confirm that the trash can restore a deleted file, and confirm that a restored version matches the original bytes. Finally, trigger a background job such as preview generation or a scheduled cron task and confirm that it completes, because a job that silently stalls against slow object storage is easy to miss in daily use. The failure tests matter most for regulated environments. Revoke or disable the service account credentials for a test bucket, then confirm that users see a clear error message, that the failed operation does not appear as successful, and that no new objects land in an unexpected bucket, prefix or local data directory. Repeat with the bucket made unavailable at the network level. Inject endpoint latency with a traffic shaping tool or proxy, and observe whether uploads time out cleanly, whether the sync client retries, and whether the server log records the event with enough detail for an operator. Confirm the exact Nextcloud version and object storage product behavior with your vendor, because error handling differs between implementations. The restore test is the one most often skipped. Take a backup that covers the database, configuration and the object store data according to your backup design, restore it into a separate Nextcloud instance with its own database and bucket, and verify that file counts, checksums on a sample, shares and user accounts match the source. Record the time it took, since that is the only real input to a recovery time target. Do not point the restored instance at production credentials or buckets. For the handover, keep a single evidence pack: the test plan with owners, the dated results for each case, screenshots or log excerpts showing the error states, the configuration files with secrets removed, the restore report with checksums and timings, and a list of open defects with their accepted risk. Ask your implementation partner or internal team to confirm which items the auditors or internal control owners expect, because DeployOpen prepares this evidence but does not issue audit reports or certifications.

What to monitor, back up and document after go-live

Once Nextcloud reads and writes to S3 or an external mount, the risk moves from installation to operation. The items below connect because a failure in one, such as an expired certificate or a backup taken without its matching bucket state, usually surfaces as file errors or unrecoverable data later.

Storage endpoint availability

Probe the S3-compatible endpoint from the Nextcloud app servers, not only from your monitoring host, so DNS, firewall and proxy paths are tested as users experience them. Alert on failed requests, elevated latency and authentication errors separately, since each points to a different owner. Confirm which endpoint is primary and whether external mounts depend on a second service that also needs checks.

Error logs and failed file operations

Review the Nextcloud log and the object store's own access logs for upload failures, timeouts, multipart errors and permission denials. Look for patterns such as one bucket, one app server or one user group rather than isolated errors. Set a regular review owner and a threshold that triggers investigation, and confirm log retention meets your audit requirements.

Bucket growth and storage cost

Track object count, total bytes, and growth per week for each bucket, and compare them with Nextcloud quota settings and user counts. Watch for orphaned objects left after deletions or failed uploads, and for version or trash retention that multiplies stored data. Ask your provider how storage, request and egress charges are billed so cost alerts reflect real spend.

Background job health

Nextcloud relies on background jobs for tasks such as trash expiry, file scanning and external storage sync. Confirm the system cron runs at the configured interval and that the admin overview reports no stalled or overdue jobs. A job that stops silently can leave deleted objects in the bucket or stale mounts that users only notice later.

Certificate expiry for endpoints and proxies

List every TLS certificate on the object endpoint, the reverse proxy and any external mount target, with its expiry date and renewal method. Alert well before expiry and test renewal in a non-production path, because an expired certificate on the storage endpoint stops all file access at once. Record the renewal owner in the storage design record.

Coordinated backups across three components

A consistent Nextcloud backup covers the database, the config directory and the bucket contents, and these must match one point in time. Metadata in the database maps users and paths to object keys, so restoring a database that references objects missing from the bucket, or the reverse, produces broken files. Decide how you will quiesce writes or use bucket versioning, then test a full restore.

Upgrades one major version at a time

Nextcloud does not allow skipping major releases, so plan each upgrade as a sequence: back up first, upgrade to the next major, verify, then repeat. Disable third-party apps before each step and re-enable them only after confirming compatibility. Schedule the sequence against the support windows published in the release schedule, and see the upgrades and backup topics for the detailed procedure.

Storage design record, credentials and restore runbook

Keep a storage design record stating the primary storage type, bucket layout, encryption choice, external mounts and endpoints. Document the credential rotation procedure, including which Nextcloud configuration entries and external mount settings change, and the restore runbook with its order of steps. Assign a named owner to each item and review ownership whenever staff change.

Common questions about Nextcloud S3 storage and external mounts

Can we switch Nextcloud from local storage to S3 object storage later?

Yes, but it is a migration project, not a setting you flip. Moving primary storage means provisioning the bucket, copying existing file data into object storage, updating the configuration, and verifying that every file, version and share resolves correctly afterward. Plan a maintenance window, a full backup before the cut, and a rollback path. The effort depends on the number of files, total data volume, the database size and whether clients will reconnect during the move. Ask your partner to state in writing how the existing data will be transferred, how integrity will be checked, and how the cutover will be tested before go-live. Confirm the exact configuration steps against the Nextcloud documentation for your target major version, since the supported object storage options and procedures can change between releases.

Can an external storage mount replace S3 as primary storage?

Usually not for the whole installation. An external storage mount makes a bucket or other remote store appear as a folder inside Nextcloud, which suits shared repositories, legacy file shares or content that must stay in place. Primary object storage holds the files Nextcloud itself manages, including versions, trash and user data, and it works differently under the hood. Mounts depend on the remote system's latency and availability, and they can behave differently for previews, search, sync and permissions. Decide per use case: use primary storage for user data you want Nextcloud to manage end to end, and mounts for specific external content. Test the behavior of each mount with representative users before deciding, and confirm what your Nextcloud version supports for each storage type.

What must our team provide before a Nextcloud S3 storage project starts?

Your team typically provides the access and information the implementer cannot create alone. That usually includes the bucket or buckets with agreed names, regions and lifecycle settings, the S3-compatible endpoint URL and TLS certificate trust chain, dedicated service credentials with the least privilege needed, a sample of test users and groups, and a test window with the people who will validate results. You should also supply network paths between the Nextcloud servers and the storage endpoint, a decision on encryption keys and who holds them, and a named approver for the cutover. Ask the implementer to list these inputs in the written scope so gaps are visible early, and to confirm which items they will verify in your environment.

Can an internal team build Nextcloud S3 storage without a partner?

Often yes, if the team already runs Nextcloud in production, understands object storage and can plan a controlled migration. The skills needed span Linux and PHP administration, the database, S3 access policies, TLS, backup and restore, and user testing. The main risks are data loss during the move, a configuration that works for admins but fails for sync clients, and an upgrade later that breaks the storage setup. A partner adds the most value when the team lacks recent experience with this exact migration, when the data volume is large, or when the work must be done inside a tight window. Estimate the internal effort by listing each skill gap, the test environment needed and the people who must be available during cutover, then compare that with a written scope.

How is a Nextcloud S3 storage engagement scoped and quoted?

DeployOpen engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of storage backends and buckets, the data volume and file count to migrate, the number of apps and integrations touching files, the identity and encryption design, the number of test cases and users, and whether the work happens in a live window. Ask for a quote that separates one-time work (design, migration, testing, documentation) from recurring items (monitoring, upgrades, support), lists assumptions about your environment, and names the client-provided inputs. Ask who performs each task and what evidence you will receive at handover.

How does server-side encryption affect previews and search with S3 storage?

Encryption choice changes what the server can read, and that affects features that inspect file content. With Nextcloud server-side encryption enabled, the server must decrypt files to generate previews and index content for full-text search, so those features need the keys to be available and add processing load. Encryption also changes backup, restore and migration steps, because the keys must be preserved and tested. Some encryption modes carry restrictions or are deprecated in newer releases, so verify the mode you plan to use against the Nextcloud documentation for your version. Ask your implementer to test previews, search, sharing and restore with encryption enabled before you commit, and to document who holds the keys and how they are recovered.

Which Nextcloud versions and databases should we confirm for S3 storage?

Confirm the target major version first, since Nextcloud publishes a new major release every four months and supports each for one year, and upgrades must go one major version at a time. Nextcloud 35 was released on 16 September 2026 with end of life in September 2027, and Nextcloud 36 is scheduled for 17 February 2027. For the database, Nextcloud 35's system requirements recommend MariaDB 11.8 or PostgreSQL 18, with MariaDB 10.11 to 12.3, PostgreSQL 14 to 18 and MySQL 8.4 or 9.7 listed as supported, and Oracle Database available only with an enterprise subscription. Also confirm PHP, web server and object storage compatibility for your chosen version, and check every app in use before the upgrade.

How DeployOpen scopes, builds and hands over Nextcloud storage

DeployOpen starts by deciding where Nextcloud keeps file data, whether on local disk, in S3-compatible primary storage or in external mounts, and what that choice means for performance, backup, later migration and encryption. Each engagement is planned, built and documented inside the client's own infrastructure, with the storage design agreed in writing before work begins.

How we scope

Engagements are fixed-scope, with the storage design, deliverables and timeline agreed in writing before work starts.
The written scope names each storage location, the mount points or buckets used, and the systems that depend on them.
Scope also records the backup, encryption and later-migration assumptions that the chosen storage model affects.

How we build

Storage is configured in the client's own cloud account, data center or air-gapped network, with access controls set before data arrives.
External storage mounts are tested for permissions, sync behavior and failure handling before users are onboarded.
Each storage path is verified with restore and performance checks that the written scope defines for this deployment.

How we hand over

Handover includes configuration documentation for the storage backend, mounts, credentials handling and encryption settings.
Runbooks describe backup coverage, maintenance mode steps and how to recover data from object storage or the data directory.
The client receives a record of tests run, open items and the decisions needed for future storage changes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Storage-related changes, such as adding a bucket or a new external mount, follow the same written scope process.
Ask any provider to confirm which Nextcloud versions and storage backends their support covers before signing.