Confluence Data Center: Designing the Smallest Viable Cluster

Why a single node is no longer enough

Confluence Server reached end of support, so a single-node install is no longer a viable production option. The practical takeaway: the smallest self-managed design that supports active/active high availability is a two-node Data Center cluster behind a reverse proxy or load balancer, with a shared home directory and an external database. This note covers the requirements, trust boundaries, operational checks, and failure modes for that baseline, plus the conditions that would justify a larger or different topology.

Requirements for the minimum cluster

• Two application nodes for active/active HA. A single node is a single point of failure and does not qualify as a cluster.
• A reverse proxy or load balancer to distribute traffic and detect node failure.
• A shared home directory on low-latency shared storage accessible by both nodes.
• A supported external database such as PostgreSQL, sized for the combined cluster load.

The smallest suitable design

At minimum, the design looks like this:

Aspect	Single-node Server (unsupported)	Two-node Data Center cluster
Availability	Single point of failure	Active/active; one node can fail
Shared state	Local home	Shared home on low-latency storage
Database	Often embedded or local	External, network-reachable
Traffic entry	Direct HTTP	Load balancer / reverse proxy
Licensing	Server (end of support)	Data Center license covering both nodes

This note assumes a current Confluence Data Center release. Exact supported platform versions, pricing, and tier limits change frequently; verify against Atlassian's supported-platforms documentation before committing.

Concrete example: load balancer health check

Configure the load balancer health check to request a lightweight status endpoint rather than a full page render. For example, poll /status on each node every 10 seconds with a 5-second timeout, and remove a node from the pool after two consecutive failures.

• Where to run: on the load balancer or reverse proxy, not on the Confluence nodes.
• Required permissions: load balancer administrator.
• Expected check: both nodes report healthy; stopping one node causes traffic to reroute within the health-check interval.
• Risk: a health check that renders a full page can exhaust JVM threads and cause false negatives.

Trust and data boundaries

The database and shared home are the highest-trust components. Restrict administrative access to them, separate the HTTP tier from internal services, and terminate TLS at the proxy. Treat attachments and exports as sensitive: an administrative export can include content that some users cannot view through the UI. Page restrictions are workflow controls, not encryption, and they do not prevent an admin or a space export from crossing that boundary.

Operational checks

• Cluster membership: verify node registration and compare the clustered-node list in Confluence administration with the load balancer pool and the licensed node count.
• JVM health: monitor heap usage and garbage collection on both nodes.
• Search index: confirm index consistency across nodes, especially after a node rejoins.
• License: check that the Data Center license node count matches the running cluster.
• Health endpoint: validate that the load balancer health check hits a lightweight status endpoint rather than a full page render.

Diagnostic decision: if search results differ between nodes after a rejoin, first compare the clustered-node list in Confluence administration with the load balancer pool and the licensed node count before assuming index corruption.

Failure modes to plan for

• Split brain: a partitioned or split-brain cluster can occur if discovery is misconfigured.
• Stale search index: a node that rejoins may serve divergent results until the index is reconciled.
• Shared-home contention: lock contention or corruption on shared storage, particularly NFS, can become a single point of failure and a latency bottleneck; validate against the supported storage matrix.
• Database pool exhaustion: connection pools can be exhausted under load if the database is undersized.
• Plugin incompatibility: apps may break after node upgrades if they are not validated against the new version.

Conditions that would change the design

• Identity requirements: SSO/SAML or SCIM needs may push toward Cloud with an identity provider.
• Data residency: strict residency rules may force a specific Cloud region or on-premises Data Center.
• Disaster recovery: explicit RPO/RTO targets may add a cold standby and an external archive.
• Automation: heavy automation may favor the REST API over UI-driven updates.

Practical verification

1. In staging, stop one node and confirm the load balancer reroutes traffic and search still returns current content after failover.
2. Compare the clustered-node list in Confluence administration with the load balancer pool and the licensed node count.
3. As a space admin, export a restricted space and inspect the archive to confirm what data crosses the trust boundary.
4. Run a restore drill from a database backup plus shared-home snapshot, then check page history and attachments.
5. Check Atlassian supported-platforms and end-of-life notices for your exact version before planning an upgrade.

Clustering does not remove the need for tested backups; rehearse restore of the database and shared home together. Remaining on Confluence Server means running an unsupported, unpatched product.