Highly available Passbolt means database and session state must move

At a glance

What this is: This is a how-to guide for building a highly available Passbolt deployment, with the key finding that database-backed sessions, replicated MariaDB state, and aligned configuration across all nodes are required for consistent service behaviour.

Why it matters: IAM and PAM teams need to treat password manager availability as part of operational control, because session state, certificate consistency, and off-node configuration drift can interrupt access to critical credentials.

Context

High availability for a password manager is not just an infrastructure concern. When the service holds the source of truth for privileged access, any mismatch between nodes can turn a routine failover into an access disruption, especially if session state remains local to one server.

Passbolt's setup requires shared database storage, database-backed sessions, and consistent application configuration across all nodes. For identity programmes, that makes the problem closer to lifecycle consistency than simple server redundancy, because the identity system must behave the same way whichever node answers the request.

The article focuses on a three-node self-hosted deployment, which is a typical pattern for teams that want resilience without handing core credential state to a single host.

Key questions

Q: What breaks when Passbolt sessions stay on a single node in a high-availability setup?

A: Session continuity breaks first. A user can authenticate on one node and then hit another node that has no matching session record, which produces inconsistent behaviour even though the service is technically up. In a multi-node deployment, session state has to be shared or the load balancer will expose a split view of the same identity state.

Q: When should IAM teams prioritise shared session storage over load-balancer tuning?

A: They should prioritise shared session storage as soon as the service is expected to answer requests from more than one node. Load balancing only spreads traffic, but it does not solve state divergence. If the authentication state is still local to a server, failover will surface as broken access rather than improved resilience.

Q: What are the main signs that a clustered Passbolt deployment is not truly high available?

A: The clearest signs are inconsistent login behaviour, health checks that pass on one node but not another, cluster size mismatches, and intermittent errors after traffic shifts. Those symptoms usually indicate that database replication, session storage, or configuration parity is incomplete rather than that the application itself is unstable.

Q: How should teams handle certificate and configuration consistency across Passbolt nodes?

A: Treat certificate material, Passbolt configuration, and application trust files as synchronized state, not separate local settings. If they differ across nodes, one request path may succeed while another fails, especially after DNS changes or failover. The safest pattern is to apply the same artefacts everywhere and verify the result with health checks.

Technical breakdown

Why database-backed sessions are required for high availability

Passbolt's default session handling relies on temporary files stored on local disk through CakePHP. That works on a single server, but it breaks once requests can land on different nodes because each node would see a different session list. Moving sessions into a database makes the session store shared state, so authentication and request continuity survive load balancing and failover. The key technical point is that session continuity is now coupled to database availability rather than filesystem locality.

Practical implication: move session storage out of node-local disk before putting the service behind multiple front ends.

How Galera replication changes the database control plane

Galera turns MariaDB into a multi-primary cluster where writes are replicated across all participating nodes. That shifts Passbolt from a single writable database to a distributed control plane, but only if cluster addressing, firewall rules, and network links are correct. The article's emphasis on odd-node count reflects quorum behaviour, where an even split can produce a brain split during outage conditions. In identity terms, the credential store must remain coherent under failover, not merely accessible.

Practical implication: validate cluster membership and quorum behaviour before treating replicated database state as production-ready.

Why configuration, GPG, and JWT assets must stay aligned

High availability only works if every Passbolt node can decrypt, sign, and interpret data the same way. The article therefore copies passbolt.php, the GPG directory, and the JWT directory to the other nodes with permissions preserved. Without that alignment, a request routed to a different node can fail even though the database is healthy, because application-level trust material no longer matches the active server. This is a classic consistency problem in identity systems: backend replication is not enough if application secrets diverge.

Practical implication: replicate application trust material with the same discipline as database state and re-run health checks after every change.

NHI Mgmt Group analysis

High availability for a password manager is a state-consistency problem, not a generic server-redundancy problem. The service only remains usable if sessions, database writes, and application trust material follow the request across nodes. Once those elements diverge, the user experiences an identity outage even when the infrastructure still looks healthy. Practitioners should treat availability as a control over credential-state coherence, not just uptime.

Shared session state is the named concept that most identity teams overlook. Password managers and similar privileged access systems cannot rely on node-local session storage when requests are load balanced. The control failure is not just failover, it is split identity state, where one node believes a session exists and another does not. The practitioner conclusion is simple: session continuity must be designed as a cluster property.

Passbolt's high availability pattern fits OWASP-NHI thinking even though the article is operational, not adversarial. The same lifecycle discipline that governs secrets and tokens also governs the availability of the system that issues and consumes them. If configuration, GPG assets, or JWT material drift across nodes, the credential service becomes non-deterministic under load. Teams should therefore align NHI governance with resilience engineering, not separate them.

Odd-node clustering is a quorum safeguard that identity teams should notice. The article's three-node design reduces the chance that a failure leaves the cluster unable to agree on state. That matters because a password manager without agreement on database state can become unavailable at exactly the moment administrators need it most. The practitioner implication is to design for fault tolerance before service disruption exposes the weakness.

Availability controls for privileged access systems belong in the same governance conversation as offboarding and rotation. When a service depends on copied application state, the operational burden shifts to keeping every node synchronised every time the environment changes. That creates a governance obligation to track version parity, certificate parity, and session-store parity as first-class identity operations. Practitioners should manage those states as part of the credential lifecycle.

What this signals

Session state has to become cluster state. High availability changes the governance model because the access experience now depends on shared session handling, not just server reachability. For identity and PAM teams, that means resilience checks need to include whether a routed request sees the same authenticated state on every node.

Configuration parity is an identity control. In a credential platform, copied application state, identical certificates, and matched secrets are part of service trust, not mere deployment hygiene. If those artefacts diverge, the platform may still be online, but the identity workflow is no longer deterministic for the user.

Shared state is the operational boundary that determines whether credential access survives failover. Teams that run self-hosted password managers should watch for drift between database replication, session handling, and application trust material. If one of those layers is local-only, the service is resilient in name but fragile in practice.

For practitioners

• Move sessions into shared database storage Replace node-local session files with database-backed sessions before introducing load balancing or active-active request routing, so any node can service the same user session.
• Replicate Passbolt application state across nodes Copy passbolt.php, the GPG directory, and the JWT directory to every node with permissions preserved, then verify each node reports the same health status after the transfer.
• Design the database cluster for quorum, not just redundancy Use an odd number of database nodes, confirm the cluster reports the expected wsrep_cluster_size, and treat quorum loss as a service-availability event rather than a background database issue.
• Keep certificates identical across all front ends Use the same SSL certificate material on every node or place a load balancer in front of the cluster so requests do not fail when DNS or load balancing routes a user to a different server.
• Rehearse change coordination for upgrades and configuration drift Upgrade all nodes in a controlled window and reapply configuration changes everywhere, because one node running a different Passbolt version or config can create intermittent failures for routed requests.

Key takeaways

• Passbolt's high-availability pattern depends on making identity state portable across nodes, not just keeping servers online.
• Database replication alone is not enough if sessions, certificates, and application trust files still diverge between servers.
• Teams should verify session continuity, configuration parity, and quorum behaviour together before calling a password manager deployment resilient.

Key terms

• Database-backed sessions: A session storage pattern that keeps authentication state in a database instead of local server files. In high-availability deployments, this allows any node to recognise the same user session, which prevents failover from breaking access continuity when traffic shifts between servers.
• Galera Cluster: Galera Cluster is a multi-primary MariaDB replication architecture where nodes can read and write while synchronising write-sets across the cluster. For security teams, the important point is that node membership and trust become part of the identity model, not just database availability engineering.
• Configuration parity: The practice of keeping application settings, trust material, and operational files identical across every node in a distributed service. In password and credential systems, parity matters because a request routed to a different server must see the same identity behaviour and cryptographic context.
• Quorum: Quorum is the minimum number of distinct, eligible approvers required to authorize a request. In dual-control identity workflows, quorum should be paired with distinct identities, device-bound proof, and terminal denial rules so that approval is both independent and non-replayable.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.