Build a Resilient Nextcloud Cluster with Galera

Build the database cluster first, then place multiple identical Nextcloud application nodes behind a health-checked load balancer. For a stable setup, all app nodes must use the same durable file storage, configuration, Redis or Valkey locking service, and a database endpoint that routes writes only to a healthy Galera member. Nextcloud’s current Administration Manual lists MariaDB as a supported database, but it does not publish a Galera-specific deployment recipe; verify your exact Nextcloud, MariaDB, Galera, and proxy versions with the vendors before production.

As of October 9, 2026, the Nextcloud 35 system requirements page lists MariaDB 10.11, 11.4, 11.8, and 12.3, with 12.3 marked recommended. That is a Nextcloud database-version list, not a promise that every Galera or proxy combination is certified. Start with the Nextcloud 35 system requirements and your MariaDB distribution’s Galera support matrix.

1. Define the failure boundaries

A high-availability cluster has more than a replicated database. Galera protects the database tier; it does not replicate Nextcloud’s user files, PHP sessions, Redis locks, or application code. A single shared database also cannot compensate for a failed storage mount or a load balancer that continues sending traffic to a broken app node.

Plan these components before installing:

• At least two app servers running the same Nextcloud release, PHP version, enabled apps, and web configuration.
• A load balancer or reverse proxy with a stable public hostname, HTTPS, and health checks for the app servers.
• Shared, durable Nextcloud data storage visible at the same path and with correct permissions on every app server. The Nextcloud data directory should be set during installation; its installation guidance cautions that moving it later is difficult.
• A Galera cluster with an odd number of voting database nodes, typically three, placed so that one host failure does not remove the majority.
• A shared Redis or Valkey service for distributed caching and transactional file locks.

Choose storage and network designs that have their own redundancy and tested recovery. A shared path is not automatically highly available just because several web servers can mount it.

2. Install and validate MariaDB Galera first

Choose a MariaDB release that meets Nextcloud’s current requirements and a matching Galera package supported by your MariaDB vendor. Follow the MariaDB Galera deployment documentation for node configuration, network ports, state snapshot transfer, TLS, and initial bootstrap. Do not start every empty node as a new cluster; bootstrap one node, then join the others to that cluster.

Nextcloud requires InnoDB and the READ-COMMITTED transaction isolation level for MySQL or MariaDB. The current Nextcloud database page also recommends row-based binary logging. Confirm the values on every database node, not only the node that currently receives traffic. See Nextcloud’s MariaDB configuration requirements.

Before connecting Nextcloud, check cluster state on each node. For example, run SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status'; and SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';. The cluster should report a Primary component, the expected cluster size, and nodes in the Synced state. MariaDB explains that quorum requires more than half of the cluster’s last known membership; a three-node cluster can therefore tolerate one node loss, not two. Review its quorum and recovery guidance.

3. Give Nextcloud a health-aware database endpoint

Configure Nextcloud to connect to a stable database proxy address, not to a round-robin list of Galera IP addresses. Although Galera replicates writes across the cluster, applications still need predictable transaction handling. A proxy that monitors Galera membership can stop routing to nodes that are unavailable or not synchronized and select a write node. MariaDB MaxScale’s Galera Monitor is one documented option; its exact behavior and supported routing modes depend on the MaxScale version and configuration.

Use the proxy’s documented connection endpoint as Nextcloud’s dbhost. Create separate, least-privilege accounts for monitoring and application access, protect credentials, and encrypt database traffic when it crosses an untrusted network. Avoid enabling read/write splitting as an assumed performance shortcut: Nextcloud’s own replication feature sends reads to replicas while keeping writes and causal reads on the default connection, but Galera is not an ordinary asynchronous replica arrangement. Use a routing design tested specifically for your stack.

4. Make every app node see the same Nextcloud instance

Install the same Nextcloud code and app set on each app server. Keep each node’s config.php consistent for the shared instance, including its database endpoint, secret values, trusted domains, and data-directory path. Do not run an upgrade independently on multiple nodes. Back up first, place the instance in maintenance mode, upgrade through one controlled path, and bring traffic back only after all nodes run the same version.

Configure all app nodes to use the same Redis or Valkey service for distributed cache and locking. A local cache such as APCu can remain node-local, but memcache.distributed and memcache.locking must point to a common service, not each server’s localhost. For example, Nextcloud’s Redis configuration can use 'memcache.locking' => '\OC\Memcache\Redis' and a shared Redis host in the redis configuration. Follow the current cache configuration guide and transactional file-locking guide. Memcached is not suitable for Nextcloud transactional file locks.

If you also centralize PHP sessions in Redis, treat that as a separate PHP configuration task. Nextcloud’s manual warns that session locking is not enabled by default for the Redis session handler; apply its locking settings and test session behavior before relying on it. Do not confuse database replication or file locking with session continuity.

5. Test failover before calling it highly available

First confirm normal use through the public hostname: sign in, upload and download a test file, and check that it is visible after a request reaches another app node. Then drain one web node and confirm requests continue through the other. Restore it and confirm it rejoins without serving an outdated code or configuration version.

Next, use a maintenance window to simulate one database-node failure according to your vendor’s runbook. Confirm the proxy removes the failed or unsynchronized member, Nextcloud can still read and write, and the returning node reaches Synced before accepting traffic. Monitor the Galera primary status, cluster size, node synchronization, proxy health, app errors, and storage mount health.

A quorum loss is a safety stop, not proof that the data is gone. Do not force-bootstrap multiple nodes or choose one at random. MariaDB’s recovery guide says to identify the most advanced node and bootstrap only that node, then rejoin the others. Confirm you have tested database and file-storage backups as well; Galera replication mirrors database changes and does not replace point-in-time backups.

Verify the outcome

The setup is ready for production only when one app node and one database node can be taken out without breaking normal file operations, all surviving Galera nodes remain in a Primary component, and the shared file store and Redis or Valkey service stay reachable. If a test fails, identify which tier stopped serving the request before changing timeouts or retry settings. The Nextcloud manual documents its supported database and application settings, while the vendor compatibility matrix and your failover tests determine whether this particular Galera deployment is supported.