Nextcloud object storage vs local storage: when to choose

Nextcloud object storage vs local storage: which fits your team

If you are deciding where a new Nextcloud instance keeps its files, local or NFS disks suit most smaller and single-site deployments, while primary object storage on S3, Swift or Azure Blob fits teams that need its scaling model and can accept a different backup design. This choice is one-way for an existing instance: the admin manual warns that enabling a primary object store on a running instance makes all existing files inaccessible, so you must pick the storage model before the first user uploads anything.

Local or NFS storage fits when your user count, data volume and site count stay within what one well-sized storage backend can serve, and when your team already runs filesystem backups and snapshots that it trusts. Its main advantage is a simple recovery path: files sit on disks you can inspect, back up with existing tools and restore without Nextcloud's database in the loop. Confirm your NFS vendor's locking and latency behavior with your own load tests before you rely on it for many concurrent sync clients.

Primary object storage fits when you need to grow capacity by adding buckets or object store nodes rather than extending a single filesystem, or when your organization already operates S3, Swift or Azure Blob with its own durability and replication controls. It also brings the option of SSE-C on compatible providers and multibucket spreading, which is set when users are created. The cost is a split backup design: Nextcloud's database holds all filenames and directory structure, so you must back up the database and the object store together and test restores of both. Plan that design with your storage team before go-live.

How object and local storage compare for Nextcloud

This table compares object storage (S3, Swift or Azure Blob) as Nextcloud primary storage with local or NFS disks across backups, recovery, scaling, encryption, access and migration. Read each row as a decision point, and treat the items marked for confirmation as questions to put to your storage vendor before you commit. The main takeaway is that this choice shapes your backup design from day one and is hard to reverse once users have data.

Factor	Object storage as primary storage	Local or NFS disk storage
Where metadata lives	Filenames, directory structure and other metadata stay in the Nextcloud database, while the object store holds file content by unique identifier.	Files sit on the filesystem and Nextcloud keeps its own database index alongside them, so the disk holds the files in a recognizable layout.
What backups must cover	The database and the buckets must be backed up together and kept in step, because neither is useful without the other.	Backups cover the data directory and the database, and both are typically captured with the same file-level or snapshot tooling.
Recovery path	Restoring requires matching database and bucket states. Confirm with your vendor how bucket versioning, replication or snapshots interact with Nextcloud restores.	Restores copy files back to the data directory and database, and a single host or volume snapshot can cover much of the content.
Direct file access outside Nextcloud	Files cannot be reached by bypassing Nextcloud, because the object keys mean nothing without its database.	Files can be read directly from the disk or NFS export, which helps with forensic work but also bypasses Nextcloud access controls.
Bucket or disk scaling	Multibucket spreads data across buckets, with 64 buckets by default. Changing the bucket count affects only newly created users.	Capacity grows by adding volumes or NFS capacity, and the performance limits depend on the storage array and network, which you must size.
Encryption options	Nextcloud supports S3 server-side encryption with customer-provided keys (SSE-C) on compatible providers. Confirm SSE-C support and key handling with your provider.	Encryption depends on the disk or volume layer, such as full-disk encryption on the host. Nextcloud's own encryption options must be checked against your requirements.
Switching to object storage later	Enabling primary object storage on an existing instance makes all existing files inaccessible, so the choice must be made before data exists or through a planned migration.	Moving to object storage later is a planned migration project, with the data and database converted or re-ingested under a tested procedure.
Who operates the storage backend	Your team or your storage provider must run the object store, its replication, keys and capacity. Confirm who owns SLAs and recovery targets.	Your infrastructure or hypervisor team typically runs the disks, NFS server and their backups, which may already be an established service.
Items to confirm with your vendor	Versioning, object lock, cross-region replication, SSE-C key rotation and S3 compatibility level for Nextcloud.	NFS locking behavior, latency under load, snapshot consistency with the database and filesystem performance at your user count.

What changes for backups and recovery

With primary object storage, a usable backup is not a copy of one disk or one bucket. Nextcloud keeps filenames, directory structure and the mapping to each file in its database, while the object store holds only file content under unique identifiers. A restore is only consistent when the database snapshot and the bucket contents come from the same point in time. If the database is restored from Tuesday and the buckets from Thursday, users see files that no longer have content, or content that no longer appears in any folder. Ask the DBA and the storage team to agree on one backup window, one snapshot method and one restore order before the first production user is onboarded.

The second change is access control. On local storage, an administrator can still find files on disk through the filesystem, which helps with forensic copies and some manual recovery. With primary object storage, files can no longer be reached by bypassing Nextcloud, so the application and its database are the only practical path to any file. The Nextcloud admin manual states that the backup strategy must change under this model, and it also warns that enabling a primary object store on an existing instance makes all existing files inaccessible. Treat the backup design as a decision to take during planning, not as an adjustment to make after go-live.

Before you commit, ask the storage team what their object platform offers for bucket versioning, object lock and replication, and whether those features cover the buckets Nextcloud writes to. Ask the DBA how database backups are taken and whether they can be coordinated with the storage snapshots. Then write a restore runbook and rehearse it on a copy of the environment, recording how long each step takes in your own infrastructure. Recovery timing depends on your data volume, network and provider, so any figure should come from your own test rather than from a vendor claim. The Nextcloud primary storage documentation is the starting point for the exact backup guidance that applies to your version.

Why the storage choice must be made before data exists

The sequence fixes the storage target while the instance is empty, so no migration is needed and the backup design is set from day one. Teams that skip this order turn a configuration choice into a separate migration project.

Define the storage target and backup design
The platform owner, storage team and security lead agree which object store will hold file content (Amazon S3, OpenStack Swift, Azure Blob Storage, or an S3-compatible store such as MinIO or Ceph Object Gateway) or confirm that local or NFS disks remain the target. They also record how backups, restores and disaster recovery will work for each layer, since the database and the object store must be protected together. The output is a signed design note listing the store, the bucket strategy, the encryption approach and the restore procedure. Confirm with the storage vendor that the chosen product is supported as primary storage for the Nextcloud version you plan to run.
Confirm the target is still empty
Before any configuration, the administrator checks that no users have logged in, no files have been uploaded and no sync clients are connected to the instance. This matters because the admin manual warns that enabling a primary object store on an existing instance makes all existing files inaccessible. The output is a written confirmation from the platform owner that the instance is a fresh install with no user data.
Provision the object store and credentials
The storage team creates the bucket or buckets, access keys with the narrowest permissions Nextcloud needs, and any server-side encryption settings. If the design calls for multibucket storage, they plan the bucket count now, because the admin manual notes that changing it affects only newly created users. If customer-provided keys (SSE-C) are part of the design, the key custody process is documented before the first file is written. The output is a tested write and read from the Nextcloud host to the bucket using the planned credentials.
Configure primary object storage on the new instance
The Nextcloud administrator sets the primary object store in the server configuration on the fresh instance, before the first user is created. The administrator then runs a basic health check that confirms the instance starts, the database connects and the object store responds. The output is a configuration file reviewed by a second person, with the change recorded in the change log.
Create a test user and verify storage placement
The administrator creates a test account, uploads a file through the web interface and a sync client, and checks that the content appears in the bucket while filenames and directory structure remain in the database. The team also confirms that the file cannot be read by browsing the bucket directly, since the admin manual states that files can no longer be reached by bypassing Nextcloud. The output is a short test record that the backup and restore procedure was exercised against this test data.
Load users and files into the new instance
Only after the storage configuration passes testing does the team onboard real users, whether through directory integration or manual creation, and begin the content load. Each user's data is written to the object store as it arrives, so the storage design is in effect from the first byte. The output is a user onboarding log and a backup job that has completed at least one full cycle against production data.
Scope any later move as a separate migration
If a local-storage instance already holds data and the team wants object storage, the switch is not a configuration change. Moving existing files is a migration project with its own plan, rehearsal, cutover window and rollback path, and it should be scoped in writing with the implementation partner or internal team before work begins. The output is a signed migration statement of work that names the source, target, validation method and acceptance criteria. Ask the vendor to confirm the supported migration path for your Nextcloud version.

Multibucket scaling and SSE-C encryption in practice

Nextcloud can spread primary object storage across several buckets through its multibucket setting, which defaults to 64 buckets. Users are assigned to buckets, so the layout determines how content is distributed across the object store as the user base grows. The bucket count is fixed for each user at creation: changing it affects only newly created users, not existing ones.

Default count: The admin manual documents 64 buckets as the default, so confirm whether that number fits your planned growth before deploying.
Assignment scope: Buckets are spread across users, not across individual files, so plan around user population and not only raw capacity.
Existing users: Raising or lowering the bucket count does not reshuffle users already on the system.
Provider limits: Confirm with your object storage provider how many buckets an account, cluster or tenant can hold before you commit to a layout.
Backup mapping: Record which buckets belong to which users so restore runs target the correct buckets.

Before go-live, write down the bucket count, the provider limits and the backup procedure for each bucket, and confirm them with your storage team.

The scale at which object storage pays off

No single volume figure settles this choice. The drivers below work together: how much data you hold, how fast it grows, what your team already runs, how mature your backup tooling is, and what encryption and audit rules apply. Model your own numbers and confirm each point with Nextcloud before you commit.

User and file volume

Object storage tends to suit large, long-lived stores where capacity must scale independently of the Nextcloud servers. Small teams with modest file counts rarely gain enough from it to offset the extra moving parts. Count files, not only terabytes, because metadata load in the database grows with object count. Ask Nextcloud how it expects per-instance file counts to affect database sizing, and test restore time against a realistic copy of your data before deciding.

Growth expectations

Object storage pays off when you expect data to grow steadily and you want to add capacity without resizing local volumes or re-mounting NFS exports. If growth is flat and predictable, a well-sized local or NFS volume may stay simpler for years. Model growth over the retention period you need, not only the current footprint. Remember that changing the multibucket count affects only newly created users, so plan bucket layout before growth begins.

Existing object storage skills

Teams that already operate S3, Swift or Azure Blob storage, including S3-compatible systems such as MinIO or Ceph Object Gateway, can absorb the operational load more easily. Teams without that experience should price in learning time, monitoring and credential management for the bucket layer. Ask whether your provider's S3-compatible behavior has been tested with Nextcloud, since compatibility varies between products.

Backup tooling maturity

With primary object storage, the database holds all filenames and folder structure, while the bucket holds only content by identifier. Backups must capture both sides consistently, and a file-level copy of the bucket alone cannot restore a usable instance. If your backup platform cannot snapshot the database and bucket together, local or NFS storage keeps recovery simpler. Rehearse a full restore before you move production data.

Compliance and encryption requirements

Object storage suits teams that need separate buckets, per-tenant layouts or S3 server-side encryption with customer-provided keys (SSE-C) on a compatible provider. Those controls need key custody, rotation and audit procedures that you own. If your auditors expect files on a locally controlled volume with simple disk encryption, local or NFS storage may be easier to evidence. Confirm SSE-C support with your provider and document where keys live before go-live.

Questions buyers ask before choosing object or local storage

Can we switch Nextcloud from local storage to object storage on a live instance?

No, not without a migration plan. Nextcloud's admin manual warns that enabling a primary object store on an existing instance makes all existing files inaccessible and that the backup strategy must change. Treat primary storage as a decision made at installation, before users upload data. If you already run a populated instance, confirm with your integrator whether the path is a fresh instance with a data migration, and ask how that migration is tested, rolled back and timed in your own environment. The Nextcloud primary object storage documentation is the starting point for that conversation.

What skills does an object storage Nextcloud need from our team?

Object storage shifts work from the filesystem to three areas. Your storage team must run and monitor an S3, Swift or Azure Blob endpoint, or an S3-compatible store such as MinIO or Ceph Object Gateway. Your database team must keep the metadata database healthy, because filenames and directory structure live there and not in the object store. Your Nextcloud administrators must understand how the two pieces stay consistent during backup and restore. Local or NFS storage asks less of the storage layer but still needs a database and backup discipline. Ask any integrator to name the person who will own each of these three areas after handover.

What drives the cost of object storage up or down?

Cost has one-time and recurring parts. One-time work includes design, the object store build or its onboarding, migration testing and backup redesign. Recurring costs include object store capacity, the database and its replicas, the backup target, and the staff time to operate both layers. Costs rise with the number of buckets you configure, how often you restore, and how much data must be copied for each backup set. Costs fall when the object store is one you already operate, when backups are scoped clearly, and when the scale is large enough to justify the extra layer. No price figure is supplied here, so request each cost line separately in any written scope.

What should we ask a storage vendor or integrator in a quote?

Ask for a written scope that separates the storage platform, the Nextcloud configuration and the backup design. Request these items explicitly:

How backups capture the database and object store together, and how a restore is tested.
How multibucket is configured, and confirmation that the bucket count applies only to newly created users.
Whether SSE-C is in scope, and which key management process your team will own.
Which Nextcloud version and database versions are targeted, checked against the Nextcloud 35 system requirements.
The migration path, rollback plan and acceptance tests.

Fixed scopes with written deliverables make comparisons across bids practical.

Can our own team run an object storage Nextcloud without outside help?

A capable team can run either model, but the object storage path asks for more concurrent skills. Ask whether you have people who already operate S3-compatible storage, a supported database and Nextcloud upgrades. Nextcloud requires upgrading one major version at a time with a backup before each upgrade, and third-party apps must be checked for compatibility. If one of those skills is missing, plan for either training or a retainer covering support and upgrades. DeployOpen plans, implements, backs up, upgrades, documents and supports self-hosted platforms in your infrastructure, under fixed-scope engagements or retainers, so an assessment of your team gap can be scoped in writing.

When does object storage start to pay off compared with local disks?

Object storage tends to pay off when capacity growth, storage replacement and independent scaling of the storage layer matter more than simplicity. Nextcloud's multibucket option, which defaults to 64 buckets, spreads users across buckets, but that benefit only appears when your data volume and operating model justify another layer. For a small or mid-sized instance on a stable disk array, local or NFS storage is usually simpler to back up and recover. Define your break-even point with your own growth forecast, your backup window and your recovery time target, then ask your vendor to model those numbers rather than accepting a generic threshold.

How do backup and recovery differ between object and local storage?

With primary object storage, the database holds all metadata and the object store holds only file content by unique identifier, so a backup must capture both at the same point in time. Files can no longer be reached by bypassing Nextcloud, which limits direct recovery of individual objects from the store. Local storage keeps files and metadata side by side on one filesystem, which is easier to reason about but still needs the database backed up alongside the data directory. In either case, test restores end to end, because a backup that cannot be restored to a working instance does not protect you.

Does SSE-C encryption change who holds the keys for our data?

Yes. Nextcloud supports S3 server-side encryption with customer-provided keys (SSE-C) on compatible providers, which means the key you supply is used by the object store to encrypt content. Confirm with your storage provider that its S3 implementation supports SSE-C, and decide who stores, rotates and recovers those keys. Losing a customer-provided key can make the encrypted content unreadable, so key custody belongs in the written scope and in your backup plan. Ask your security team to review the key process before any production data is written.

Skills and ownership each option needs

Primary object storage does not remove work from a Nextcloud team. It moves work between a storage team, a database team and the application owners, and each of these duties must have a named owner before the first file lands. The cards below cover the parallel responsibilities that differ most between object storage and local or NFS disks.

Object store administration

Someone must own the S3, Swift or Azure Blob service itself: bucket lifecycle, access keys, replication, capacity and provider upgrades. With a self-hosted MinIO or Ceph Object Gateway, this team is also the one that patches the store. Confirm who holds the keys Nextcloud uses, how rotation works, and whether the storage team can answer a restore request without Nextcloud involvement. Object store access keys are a single point of failure for the whole instance.

Database backup and restore

Under primary object storage, filenames, directory structure and sharing metadata live in the Nextcloud database, while the object store holds only file content by unique identifier. A backup of one without the other cannot restore a working instance. Assign one owner to take matched database and bucket snapshots on the same schedule, and test a full restore in a separate environment. Local disks keep metadata and content together in one data directory, so this pairing is new work for most teams.

Disk and NFS capacity

Local and NFS deployments put capacity planning on the team that owns the hypervisor, SAN or NAS. Growth, snapshot space, NFS mount health and permissions on the data directory all fall to that group. Object storage shifts most of that to the object store owner, but the Nextcloud team still tracks database size and cache growth. Ask who is paged when a mount goes stale, and whether the NFS export and the Nextcloud data directory share one owner.

Nextcloud upgrade discipline

Nextcloud does not allow skipping major releases, so each upgrade moves one major version at a time, with a backup before every step and third-party apps disabled until confirmed compatible. The upgrade owner must also account for the object store and database versions the new release supports. Budget this as recurring work tied to the release schedule, not as a one-time install task. Confirm who signs off each upgrade and who can roll back.

Monitoring across both layers

Object storage adds a second failure surface: request latency, throttling, error rates and multibucket distribution all need watching alongside PHP, database and cron health. A local deployment watches disk I/O and filesystem health instead. Assign one owner for end-to-end alerts so a slow bucket is not mistaken for an application fault. Ask the object store team which metrics they export and how long they retain them.

How DeployOpen scopes storage decisions

The storage backend is a design decision that DeployOpen scopes before any user data exists, because the choice between primary object storage and local or NFS disks shapes backups, recovery, encryption and future growth all at once. DeployOpen plans and implements self-hosted platforms inside the client's own infrastructure, whether that is the client's cloud account, data center or air-gapped network, so the storage target, its access model and its network path are decided in the client's environment rather than on a vendor's hosted service.

Engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and for storage that written scope should name the backend (S3, Swift, Azure Blob, local disk or NFS), the bucket layout, the number of buckets for multibucket, whether SSE-C is in use, the backup method for both the database and the object store, and the recovery test that proves the design works. A quote follows from that written scope. DeployOpen does not publish a price list, so the cost of the storage work depends on what the agreed scope includes. Ask for the cost components broken out by design, build, migration (if any), backup validation and ongoing support, and confirm which items are one-time and which recur.

Before the scope is signed, confirm with the platform owner and the storage team that the primary storage decision is final. The Nextcloud admin manual, linked from this page's sources, warns that enabling a primary object store on an existing instance makes all existing files inaccessible and that the backup strategy must change. Treat that warning as a gate: write the decision, the rollback position and the owner of the backup change into the agreed scope so that nobody discovers it after users have uploaded files.

How DeployOpen delivers and supports Nextcloud storage

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the storage design decision for Nextcloud. The work starts with a written scope so the storage choice, backup approach and recovery targets are agreed before any production data is written.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope records the storage backend, whether it is primary or secondary, and the bucket layout.
Scoping covers how backups and restores will run against the object store and the database together.
We confirm which encryption model, including any SSE-C key handling, your provider supports before committing.

How we build

Installation runs in your own cloud accounts, data centers or air-gapped networks, not in a DeployOpen environment.
Object storage is configured with the chosen bucket strategy, including multibucket settings agreed during scoping.
Testing covers restore of database and object data together, so recovery is proven rather than assumed.
Integration work connects identity sources such as LDAP or Active Directory and the office and antivirus components in scope.

How we hand over

Deliverables include documentation of the storage layout, backup jobs and the restore procedure your team will run.
Compliance evidence and controls produced during the build are packaged for your assessors, who issue any attestations.
Handover covers the administrator steps for upgrades, including one major version at a time and pre-upgrade backups.
Your staff are walked through monitoring of the object store and the database that must stay in step.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Retainers can cover upgrade planning across Nextcloud's maintained major releases and third-party app compatibility checks.
Restore tests can be repeated on a schedule agreed in the retainer, so recovery stays verified after changes.
Ask any provider, including DeployOpen, to confirm the support hours, response targets and scope in writing before signing.

Nextcloud object storage vs local storage