Nextcloud high availability guide

Why Nextcloud high availability starts with the database and storage

A clustered Nextcloud is several stateless application servers behind a load balancer, all sharing one database, one cache and file locking service, and one file store. The hard part of high availability is not adding application servers. It is making the shared state survive a failure, because every app server has to read and write the same user accounts, file metadata, share records, sessions and locks. If the database, the Redis service used for locking and sessions, or the storage behind the data directory is a single point of failure, losing that one component stops file sync and sharing for every user, no matter how many app servers are still running.

This is the main difference from a single-node install. On one server, the web process, the database, the cache and the data directory all sit on the same host, so a reboot or disk fault is a single outage with a simple recovery path. In a cluster, each component has its own failure modes, its own replication or backup approach, and its own owner. The database needs replication or a managed high availability setup, Redis needs a design that keeps locks and sessions available across the cluster, and the file store must be reachable from every app server with consistent permissions. Decisions about these three layers should be made before any app server is provisioned, because they determine what the load balancer can safely route to.

Planned maintenance is also a shared-state problem. Nextcloud releases new major versions every four months and supports each one for a year, with monthly maintenance releases in between (per the Nextcloud maintenance and release schedule). Major upgrades must be applied one version at a time, after a backup, with third-party apps disabled until they are confirmed compatible (per the Nextcloud upgrade manual). In a cluster, that upgrade touches the database schema and the shared code base on every node, so it needs a planned maintenance window even when the architecture is highly available. Redundancy keeps the service up through unplanned faults; it does not remove the need to schedule upgrades.

Before committing to a design, confirm with your team how each shared component will fail over, who owns it, and how you will test a failover. Ask the database team whether replication is synchronous or asynchronous and what happens to in-flight writes during a switch. Ask the infrastructure team whether the file store is shared filesystem storage or object storage, and whether every app server can read the same data directory or bucket at the same time. Ask the security team how sessions and locks are handled if Redis is unavailable. The answers determine the build sequence and the effort involved, and they are the first items a partner should scope in writing.

Which components a clustered Nextcloud depends on

A clustered Nextcloud is only as available as its weakest shared layer. Every app server must read the same database, lock and cache state, and the same files, so the load balancer, database, Redis, storage and background job runner each need a redundancy decision before the app tier is multiplied.

App servers with Apache or nginx

Each app server runs Apache 2.4 or nginx with php-fpm to serve the Nextcloud web interface, WebDAV and API traffic. Nextcloud 35 lists Apache 2.4 or nginx with php-fpm, and PHP 8.5 with 8.3 and 8.4 also supported. Nodes must run identical PHP versions, extensions and Nextcloud code, or sessions and apps will behave differently by server. Losing one node should only reduce capacity. The single point of failure appears when all app servers share one host, one virtual machine or one availability zone.

Load balancer and session handling

The load balancer distributes client connections across app servers and handles TLS termination if you choose to terminate it there. Session affinity is a design choice to confirm with your configuration, because Nextcloud sessions must be readable by every node that may receive a request. Health checks should remove a failed app server automatically. Built without redundancy, a single load balancer becomes the entry point that takes the whole service offline, so plan a pair with a floating address or a managed equivalent.

Database with MariaDB, PostgreSQL or MySQL

The database stores users, shares, metadata and configuration that every app server reads and writes. The Nextcloud 35 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 also supported. Confirm the chosen engine's replication and failover model against the supported version list before design. Every app server must reach the database endpoint, usually through a virtual address or proxy. A single database instance without replication is the most common single point of failure in a cluster.

Redis for file locking and caching

Redis handles transactional file locking and memory caching so concurrent requests from different app servers do not corrupt the same file. Without it, a clustered Nextcloud cannot safely coordinate edits across nodes. Redis and the database must be reachable from every app server, so network paths, firewall rules and DNS names should be tested from each node. Redis run as a single instance without a replica or sentinel setup creates a single point of failure that stops file operations under load.

Shared or object primary storage

Primary file storage must be visible to every app server, either as a shared network file system or as S3-compatible object storage. Each node must see the same data directory or bucket, with identical configuration. Storage choice affects performance, backup method and any later migration, so confirm it during design. A single NFS export or single bucket without redundancy stops all file access when it fails, even though every app server remains healthy.

Background job runner

Nextcloud background jobs handle tasks such as previews, notifications, trash cleanup and scheduled processing. For a clustered setup, use system cron rather than AJAX or webcron, and run it from one designated node or a controlled scheduler so jobs do not run twice. If the runner stops, the web tier still responds but maintenance tasks silently pile up. Monitor job queues and confirm which node owns cron before go-live.

Which high availability design choices to make before building

This table compares the main design decisions for a clustered Nextcloud: database, Redis, primary storage, session handling and platform. Read each row for when an option fits and what it costs your team to run, then confirm the vendor support details named in the last rows before you commit.

Decision	Option	When it fits and operational cost
Database redundancy	Replicated database with planned failover	Fits teams with strong database operations skills who can run and rehearse failover. Recurring cost is staff time for replication monitoring and failover testing, plus careful handling of Nextcloud maintenance mode during switchovers.
Database redundancy	Managed or externally operated database service	Fits teams that prefer the provider to run patching, backups and failover. Cost is the service fee and a dependency on the provider's recovery model, so confirm supported engine versions and how Nextcloud connections are handled during failover.
Redis topology	Single Redis instance	Fits small or non-critical deployments where a Redis outage can be tolerated. Locking and cache failure can disrupt file operations, so the operational risk sits with whoever is on call for restarts.
Redis topology	Highly available Redis setup	Fits clusters where file locking must survive a node failure. Cost is added configuration, monitoring and failover testing, and the team must confirm how its Redis edition and topology are handled by Nextcloud's documentation.
Primary storage	Shared network file system	Fits teams already running an enterprise NAS or SAN with strong latency and locking behavior. Cost is storage performance tuning, mount and permission management on every app server, and careful testing of file locking under concurrent use.
Primary storage	S3-compatible object storage	Fits teams that want storage decoupled from app servers and have an object store with proven durability. Cost is the object store's own operations, latency testing for many small files, and backup planning that covers both the bucket and the database.
Load balancer session handling	Sticky sessions	Fits simple deployments with few app servers and short failover needs. Cost is uneven load distribution and users being pinned to a node that may fail, which can force re-login.
Load balancer session handling	Shared session storage in Redis	Fits clusters where any app server should serve any request. Cost is a hard dependency on Redis availability, so it pairs with the highly available Redis option and needs failover testing.
Platform	Virtual machines	Fits organizations with mature virtualization and configuration management. Cost is OS patching, PHP and web server updates on each node, and manual scaling of app servers.
Platform	Containers or Kubernetes	Fits teams with container platform skills and a need for repeatable scaling. Cost is platform operations, persistent storage integration and handling major-version upgrades as a controlled rollout. Confirm the supported container images and Helm chart status with the vendor.
Supported versions	Database and PHP versions for the chosen major	Nextcloud 35 documents MariaDB 11.8 or PostgreSQL 18 as recommended, with MariaDB 10.11 to 12.3, PostgreSQL 14 to 18 and MySQL 8.4 or 9.7 supported, and PHP 8.5 with 8.3 and 8.4 supported. Confirm the exact combination against the system requirements for your target major before buying hardware or managed services.

How to build a clustered Nextcloud in the right order

This sequence takes a clustered Nextcloud from a version check to a tested failover, building each shared dependency before the application that relies on it. Each step closes with a named check, so the team knows the layer works before the next one depends on it.

Confirm the supported version matrix
The platform engineering lead and the database administrator confirm the versions to deploy against the Nextcloud 35 system requirements. The matrix covers the database (MariaDB 11.8 or PostgreSQL 18 are recommended, with other listed versions supported), PHP 8.5 (8.3 and 8.4 are supported), and either Apache 2.4 or nginx with php-fpm. Confirm each choice with the vendor's own support statements for your database and operating system. The step is done when the signed matrix lists one version per component and the team has checked it against the requirements page on the day of the build.
Build and test the shared database and Redis
The database administrator builds the shared database and the Redis service before any application server exists. Decide the database topology here, including whether replication is used and how failover is handled, and confirm the vendor supports that topology. Redis serves file locking and session data, so it must sit on a network path every app server can reach. The check is a connection test from each planned app server subnet to the database and Redis, plus a lock acquired on one host and seen as held from a second host.
Provision and mount shared primary storage
The infrastructure team provisions the shared data directory on storage that every app server mounts at the same path. Set the owner and permissions for the web server user identically on each node, because mismatched ownership is a common source of failures that appear only on some nodes. Test this layer before installing Nextcloud on it. The check is a file written from one node and read, modified and deleted from another, with the same ownership and permissions reported on both sides.
Install the first app server and complete setup
The Nextcloud engineer installs the application on the first app server and completes the initial setup against the shared database, Redis and data directory. Point the configuration at the shared services, not at local files, and keep the background job mode at its default until the runner is set in a later step. Record the configuration file as the baseline for every other node. The check is a successful administrator login, a test upload, and a status command that reports the instance as installed and connected to all three shared services.
Add the remaining app servers from one configuration
The engineer builds each additional app server from the same image or configuration management code as the first node, then changes only node-specific values such as the hostname. Keeping the Nextcloud version and the app set identical across nodes avoids behavior that differs by server. Compare the configuration file on each node against the baseline. The check is a file uploaded through one node that appears on another node, and a Redis lock acquired from one app server being reported as held by a request routed to a different app server.
Configure the load balancer and proxy trust
The network engineer places the load balancer in front of the app servers and sets a health check that reflects whether each node can serve requests. The Nextcloud configuration then lists the load balancer as a trusted proxy and sets the overwrite settings so generated links and client IP addresses are correct. Decide whether sessions need sticky routing and document that choice. The check is a health check marking a deliberately stopped node as down, plus access logs and login records showing real client addresses rather than the load balancer address.
Move background jobs to one scheduled runner
The engineer switches background jobs to system cron and schedules them on exactly one node, or on a dedicated runner that is not serving user traffic. Running the job schedule on every node causes duplicate and competing work against the shared database. Confirm that the schedule on the other nodes is disabled. The check is the background job status showing the last run recently and only from the designated runner, with no job executing twice in one interval in the logs of two nodes.
Run the failover tests and record results
The engineer and the operations team run a scripted set of failure scenarios, such as stopping one app server during an upload, restarting the Redis service, and failing over the database if a replica exists. Record for each scenario what the user sees, what the logs show, and how long recovery takes in your environment. Repeat the tests after any change to the cluster. The step is done when every scenario has a recorded result, a named owner, and a documented recovery procedure that the operations team has rehearsed.

What drives the effort and cost of a clustered Nextcloud

This table lists the factors that most change how much design, build and run work a clustered Nextcloud needs, with the reason each one matters and the practical way to keep it manageable. Read each row as a question to answer before requesting a quote, since the answers set the size of the build and the upkeep afterward. Most of the effort sits in the choices made early, so settling them in the scope document saves rework later.

Driver	Why it raises effort	How to keep it down
User count and concurrent use	More concurrent sessions raise load on app servers, PHP-FPM workers and the database, and push Redis locking and session handling harder. Each added app server also adds configuration, monitoring and patching.	Size the cluster from measured peak concurrency rather than total accounts. Start with fewer, well-monitored app servers and add capacity when metrics show it is needed.
Data volume and file change rate	Large data sets and frequent edits increase storage throughput needs, background scanning, preview generation and the time required for backups and restore tests.	Separate file data from the database, decide early between shared and object storage, and limit preview generation to the file types people actually use.
Number of environments (production, staging, recovery site)	Each environment needs its own database, Redis, storage, configuration and deployment steps. A recovery site also needs replicated data and a tested failover procedure, which is often the largest share of the work.	Build production with infrastructure as code so staging and recovery run the same configuration. Agree in writing which environments are in scope and how often the recovery site is tested.
Existing identity and directory integration	Connecting to LDAP, Active Directory, OpenID Connect or SAML requires attribute mapping, group rules for shares and quotas, and decisions about provisioning and deprovisioning. Each identity source adds test cases.	Confirm the directory owner, the authoritative group structure and the login method before design starts. Limit the first release to one identity source.
Third-party apps that must be checked on every major upgrade	Nextcloud requires third-party apps to be disabled until they are confirmed compatible with the new major version. Every app in use adds a compatibility check, a test cycle and a possible fix or replacement on each upgrade.	Keep the app list short and justified. Record the owner and business need for each app, and remove apps that are unused before the cluster goes live.
Compliance evidence requirements	Assessors often ask for documented configuration, access reviews, change records, backup and restore test results and logs retained for a defined period. Producing and keeping this evidence is ongoing work, and it is not issued by the implementer. Independent auditors and certification bodies make the assessment decision.	Ask which framework and control set applies and which evidence the assessor expects. Plan evidence collection into the build so logs, configuration baselines and test records are created as the system is built.
Whether the database and storage already exist in the organization	Using an existing, supported database platform and storage service with known backup and monitoring usually reduces build work. Introducing a new database engine, replication method or object storage service adds design, testing and operating skills the team must maintain.	Reuse platforms the organization already runs and supports. Confirm the supported database versions for the target Nextcloud major and check that replication and backup tooling is already approved by the operations team.

What Nextcloud Enterprise clustering support covers and what it does not

Clustering support is a vendor support entitlement, not a design service. According to Nextcloud's pricing page, the Standard tier includes 1-year maintenance. Premium adds a maintenance lifecycle of 5 or more years, extended support hours and clustered instance support. The highest tier adds support up to 24/7 with response times down to 1 hour. Clustered instance support appears in the Premium tier, so an organization planning multiple app servers behind a load balancer should confirm which tier it is buying before it assumes the entitlement applies. The contract should name the tier, not just the product.

Enterprise is sold with a 100-user minimum. Per the pricing page, list prices start at 71.29 euros per user per year for Standard, 104.99 euros for Premium and 204.75 euros for the highest tier, for 100 or more users. Lower rates apply from 200 users, so headcounts near that threshold should ask for the rate at the exact seat count in writing. The subscription recurs every year for as long as the cluster runs. The build, which covers database replication, Redis, shared or object storage, load balancer configuration and testing, is a one-time project cost. Compare the annual subscription against the one-time build when you model total cost.

Support does not design the cluster, and it does not replace your own failover testing. A support engineer can help diagnose a fault in a supported configuration. The engineer will not prove that your database failover promotes cleanly, that user sessions survive the loss of a Redis node, or that file locking holds when two app servers write to the same folder. Those tests belong to your team or to your implementation partner. Schedule them before go-live, and repeat them after each major upgrade, since each major release moves to a new set of supported components.

Before you sign, get the vendor to confirm in writing which clustered configurations it will support. Cover the database engine and version (Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18), the Redis topology, whether object storage serves as primary storage, the reverse proxy and load balancer product, and whether a Kubernetes deployment is included. Ask whether support extends to a cluster built by a third party. Record the answers as an appendix to the order form so the scope can be checked when a ticket is opened.

Securing shared services in a Nextcloud cluster

In a clustered Nextcloud, several app servers share one database, one Redis instance and one storage mount, so a weakness in any shared service affects every node. The cards below cover the controls that exist because of that sharing: network reach, credential handling, proxy trust, storage permissions, traffic protection and config consistency. General hardening such as TLS headers, brute-force protection and app vetting is covered in the security hardening topic.

Restrict Redis and database access

Redis holds file locks and session data, and the database holds every account and share. Both should accept connections only from the app server network, on the ports they actually use, and both should require authentication. Confirm with your network team that no other subnet, including the load balancer subnet, can reach them directly, and test the rule from outside the app tier before go-live.

Keep credentials out of version control

Database passwords, the Redis password and object storage keys often end up in config files that are copied to every node and sometimes committed to a repository. Store these values in a secrets manager or in environment-injected files with restricted read access, and reference them from the configuration instead of writing them inline. Check your repository history for credentials already committed, and rotate any that were exposed.

Set trusted domains and proxies

Each app server must list the hostnames users actually reach, and the trusted proxy list must contain only the load balancer addresses. If the proxy list is wrong, client IP addresses in logs and brute-force decisions become unreliable, and forwarded headers can be spoofed by any client that can reach a node directly. Test by requesting the service through every public hostname and by sending a forged forwarding header from an untrusted address.

Protect the shared storage mount

Every node writes to the same data directory, so ownership and permissions must match the web server user on each node, and the mount should not be writable by anything else. Confirm that the mount options, UID and GID mapping are identical across nodes, and that the directory is not exposed by the web server outside the Nextcloud application path. Verify with a file written from one node and read from another.

Encrypt traffic between nodes and the database

Where your policy or the network path requires it, encrypt connections from app servers to the database, to Redis and to object storage, and verify certificates rather than accepting any certificate. Traffic on a private network may still be in scope for encryption under your own controls. Ask your database and storage teams which connections support TLS in your versions, and document the decision for each service so reviewers can trace it.

Keep the config file identical on every node

The main configuration file defines the database, cache, trusted domains and storage settings, and a difference between nodes causes intermittent failures that are hard to trace. Treat it as a secret that is deployed from one source, with restricted permissions, and compare checksums across nodes after each change. Record every configuration change in version control or change records so a node that drifts can be identified and corrected.

How to prove a clustered Nextcloud fails over safely

A clustered Nextcloud is only highly available if you have tested each failure it is meant to survive, and the test plan should be written before anyone touches the production cluster. The core rule is simple: a test passes only when the expected behavior has been written down in advance, with the observed result recorded next to it. Without a written expectation, a team tends to read whatever happened as acceptable. Write one line per test that states what the client should see, what the database and Redis should show, and what must be true of the files afterwards. A failed test should stop the production cutover until its cause is found and the test passes on a rerun.

Order the tests so the least disruptive ones run first and the ones that touch state run last, with a rollback path open for each. Start with a single app server stopped during active sync. Run desktop and mobile clients that are uploading and editing, then take one app node out of the load balancer pool. The expected result is that clients reconnect through the remaining nodes without losing committed files, and that any in-flight upload either completes or is retried cleanly. Confirm this by checking the file versions and the sync client activity log on both sides, not only by watching the sync icon turn green.

Next, fail the database primary and confirm that the application reconnects to the promoted primary within the window your design documents. Your database replication setup, failover tooling and Nextcloud database configuration all have to agree on which host is the write target, so verify that the config.php database entries and any connection proxy point where you expect after promotion. Then restart Redis. Check that file locks held before the restart are released or re-acquired correctly, that existing browser and client sessions either survive or fail with a clean re-login, and that a file being edited during the restart does not end up locked for other users. Confirm the Redis role and the locking backend in the admin overview before and after the test rather than assuming them.

Two checks need to run during every failure, not only at the end. First, confirm that only one background job runner executes at a time. Nextcloud's cron-driven background jobs must run on a single designated node or a dedicated runner, so inspect the running processes and the background job status page on each app server while failover happens. Second, upload and edit a file during each failure, then compare the stored result with the local copy. After the full sequence, check the integrity of the shared storage: run occ files:scan where the data layout requires it, look for orphaned or partially written files, and compare checksums for a sample of test files against the values recorded before testing. Name the person who signs off on this evidence and keep the logs with the test record.

Run the entire plan first in a staging cluster built the same way as production, with the same load balancer, database replication topology, Redis configuration, storage backend and Nextcloud major version. Staging results only carry weight if the topology matches, so record every difference that remains and decide whether each one could change the outcome. Ask your implementation partner or internal team to confirm which tests they will run in staging, what evidence they will capture, and who holds the authority to stop a production cutover. Once staging passes and the production window is approved, repeat the subset of tests that touch state, because a clean staging run does not prove that production data, network paths and certificates behave the same way.

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

Once the cluster is live, its health depends on a short list of recurring checks, a backup set that matches the database and storage, and upgrades that keep every node on the same supported release. The six cards below cover what to watch, what to protect, what to change and what to record.

App servers and load balancer checks

Watch each app server as its own target, because a node that fails quietly can stay hidden behind healthy peers. Track PHP-FPM worker saturation, web server error rates and response times per node. On the load balancer, confirm that the health check requests a real Nextcloud endpoint and that a node returns to rotation only after it passes checks again. Ask your partner to document the exact check path and thresholds.

Database replication lag and Redis availability

Replication lag shows how far a replica trails the primary, and a lagging replica can serve data that is out of date, so alert on lag and on replica connectivity. Confirm which database endpoint handles writes and how failover is triggered. Redis holds file locks and session state for the cluster, so monitor its availability and memory use, and confirm the failover behavior your Redis design provides.

Shared storage capacity and latency

Every app server reads and writes the same primary storage, so a full volume or slow mount affects all nodes at once. Track free capacity against growth, and measure latency on the shared path from each app server. Watch for inode exhaustion on file-based storage, and confirm that alert thresholds leave enough time to add capacity. If you use object storage, track the equivalent request latency and error rates from the app tier.

Background job health

Nextcloud runs recurring tasks such as file scans and cleanup as background jobs, and in a cluster these should run from system cron on a fixed schedule. Check that the job queue drains on time, that jobs run on the node or schedule you designated, and that an alert fires when the queue backs up. A stalled queue often appears first as slow sync or missing notifications, so track it directly.

One consistent backup set

Back up the database, primary storage and configuration as one consistent set, captured at the same point in time, because a database that no longer matches the file store makes restores unreliable. Include the config directory and any secrets it references. Use maintenance mode during capture where your procedure requires it. The step-by-step procedure lives in the backup and disaster recovery topic, and restores should be tested on a set schedule.

Upgrade one major version at a time

Nextcloud does not allow skipping major releases, so each upgrade moves the cluster forward by one major version. Take a fresh backup before every upgrade, and keep third-party apps disabled until their compatibility with the target release is confirmed. Plan a maintenance window for every node, because each app server must be upgraded and returned to rotation in turn. Release timing and support lifecycles are covered in the upgrades and support topic.

Questions buyers ask about Nextcloud high availability

How much does a clustered Nextcloud cost to build and run?

The cost comes from several components, and only some of them recur. One-time costs include build labor for design, deployment, load balancer and Redis setup, and failover testing. Database and storage infrastructure, Redis, and the load balancer add capacity costs that you may already carry for other systems. Ongoing costs include administration by your staff and, if you choose it, an Enterprise subscription. Nextcloud's pricing page lists Enterprise Standard at 71.29 euros, Premium at 104.99 euros and Ultimate at 204.75 euros per user per year, with a 100-user minimum and lower rates from 200 users. Clustered instance support is listed under Premium. Ask any quote to show build labor, infrastructure, subscription and administration as separate lines, so you can see which costs change if your user count or redundancy design changes.

How long does a Nextcloud high availability project take?

Duration depends on the decisions made before build starts and on how much testing the scope includes. The main decisions are the database engine, whether files live on shared storage or object storage, how identity integrates, and how many failure scenarios must be proven. Each open decision adds design and review time, and a thorough failover test set takes longer than a basic load test. Your change window and the availability of a staging environment also set the pace. No standard duration applies across environments, so ask for a timeline in the written scope, with each phase, the decisions it depends on, and the test cases it covers. A fixed-scope agreement makes these dependencies visible before work starts.

What does our organization need to provide for a Nextcloud cluster?

Expect to provide people, access and environments. You need database administrators for the chosen engine, since Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18 according to its system requirements, and storage administrators for shared file systems or object storage. Identity access is needed if you connect LDAP, Active Directory, OpenID Connect or SAML. Network teams must allow traffic between the load balancer, application nodes, database, Redis and storage. You also need a staging environment that matches production closely enough to rehearse upgrades and failover, and a change window agreed in advance. Confirm these owners and dates early, because most delays come from waiting on access rather than from the build itself.

Can our internal platform team build Nextcloud high availability without a partner?

A skilled internal team can build it, provided it has experience across the layers involved. The work spans PHP-FPM and web server tuning, database replication, Redis for file locking and sessions, shared or object storage, load balancing, and background job scheduling. Engineers also need a tested upgrade routine, because Nextcloud does not allow skipping major releases and requires one major version at a time, with a backup before each upgrade and third-party apps disabled until confirmed compatible. Ask whether your team has run each layer in production, who will own failover testing, and who will be on call after go-live. If the answer to any of these is unclear, a partner can cover the gap through a fixed-scope engagement, or your team can take a bounded role.

Does Nextcloud Enterprise clustering support replace our own failover testing?

No. Vendor support helps you respond to problems, but it does not prove that your load balancer, database failover, Redis behavior and storage paths work together in your network. Nextcloud's pricing page lists clustered instance support as part of Premium, and higher tiers add longer maintenance and support hours. Those terms describe what the vendor will help with, not how your environment behaves when a node is lost during a write or an upgrade. Plan your own failover tests against documented failure scenarios, record the results, and repeat them after major changes. Before you buy a tier for clustering, confirm the exact support scope in writing with Nextcloud.

What should engineers verify before a clustered Nextcloud goes live?

Verify each failure path, not only the happy path. Confirm that each application node serves the same data directory or object store, that file locking through Redis behaves correctly under concurrent edits, and that sessions survive the loss of a node according to your load balancer design. Check that background jobs run on a single schedule rather than on every node, that the database fails over with the replication settings you documented, and that config is identical across nodes. Test a restore from backup as well, and rehearse a major upgrade in staging. Record the expected behavior for each test so that operations staff can judge a live incident against it.

How does a clustered Nextcloud change upgrades and maintenance work?

Each upgrade touches every node, so plan it as a controlled change rather than a routine patch. Nextcloud publishes a new major version every four months and supports each for one year through monthly maintenance releases, so the upgrade cadence is frequent. Apply each major version in sequence, take a backup before every upgrade, and disable third-party apps until their compatibility is confirmed. Rehearse the full sequence in staging with the same node count and database engine as production. Build the change window around the slowest step, and assign owners for database, storage and application nodes. Ask any implementation partner to include upgrade rehearsal and handover of this runbook in the written scope.

How DeployOpen scopes, builds and hands over a clustered Nextcloud

DeployOpen plans, implements, hardens, documents and supports self-hosted Nextcloud inside your own infrastructure, including the multi-server design behind high availability. Engagements start with a written, fixed scope, so the cluster design, components and acceptance tests are agreed before any build work begins.

How we scope

Confirm the number of app servers, load balancer type and where each node runs in your environment
Agree the database engine and replication approach, with the Nextcloud 35 requirements checked against your chosen versions
Define Redis use for file locking and sessions, and the shared or object storage design for user data
List identity integration, backup responsibilities and any Nextcloud Enterprise support tier the cluster needs

How we build

Deploy the app servers, reverse proxy and load balancer configuration in your cloud accounts or data centers
Configure database replication, Redis, background jobs and sticky session behavior, then test failover of each component
Run a documented failure test plan that covers node loss, database failover and storage unavailability
Keep third-party apps disabled until their compatibility with your target major version is confirmed

How we hand over

Provide architecture diagrams, configuration records and runbooks for routine tasks and incident response
Document the upgrade procedure, which moves one major version at a time with a backup before each step
Walk your operations team through failover tests and the evidence each test produces
Deliver the written scope results and an agreed list of open items for your own team to close

How we support

Offer ongoing support, upgrades and continuous testing as retainers that follow the agreed scope
Review each monthly maintenance release for the supported major version and plan its rollout with you
Confirm with Nextcloud which Enterprise tier includes clustered instance support before you commit to it
Keep configuration and runbooks current after each change so the cluster stays documented