Topic starter
08/07/2026 7:08 pm
TL;DR: Resilient password management depends on shared database state, database-backed sessions, replicated configuration, and consistent certificate handling across three nodes, according to PassBolt. For identity teams, availability is not just infrastructure hardening; it is lifecycle discipline for the secrets and session state that keep credential access usable.
Editorial analysis by NHI Mgmt Group, based on content published by PassBolt: “How to Set-Up a Highly-Available Passbolt Environment”.
Key questions
Q: What breaks when Passbolt sessions stay on a single node in a high-availability setup?
A: Session continuity breaks first.
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.
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.
Practitioner guidance
- 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.
Bottom line: Passbolt's high-availability pattern depends on making identity state portable across nodes, not just keeping servers online.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/07/2026 7:32 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Highly available Passbolt means database and session state must move