Highly available Passbolt means database and session state must move

At a glance

What this is: This is a practical guide to building a highly available Passbolt deployment, with the key finding that database replication, shared sessions, and synchronized configuration are all required for stable operation.

Why it matters: It matters because password vault availability is part of identity resilience, and IAM teams need to treat session state, certificate consistency, and failover design as governance issues, not just infrastructure tasks.

👉 Read Passbolt's guide to building a highly available password vault

Context

Highly available password management depends on more than extra servers. If authentication state, session storage, and configuration drift are not handled consistently, users may lose access to the system that stores critical credentials even while the underlying application is technically running.

For IAM and NHI programmes, this is a governance problem as much as an operations problem. A password vault sits on the boundary between human identity, privileged access, and machine-to-machine credential handling, so resilience has to cover state, replication, and controlled change across all of those layers.

Key questions

Q: How should teams scale a password vault without breaking user sessions?

A: Teams should move session state into a shared backend before adding nodes behind a load balancer. If sessions stay on local disk, authenticated users may be routed to a server that does not know their state, which causes login instability, interrupted workflows, and inconsistent access behaviour across the cluster.

Q: When does high availability turn into a configuration governance issue?

A: It becomes a governance issue the moment every node must present the same trust material and application behaviour. Certificates, JWT files, GPG material, and Passbolt configuration must be synchronized, or failover can produce different results depending on which node receives the request.

Q: How do security teams know a Galera cluster is actually healthy?

A: Security and platform teams should verify cluster membership, replication consistency, and node parity rather than assuming that a service restart succeeded. A healthy-looking host can still be out of sync, so operational checks must confirm that all nodes report the expected cluster size and share the same replicated state.

Q: What should teams coordinate before upgrading a clustered identity service?

A: Teams should coordinate application version changes, database migrations, and configuration replication as one change set. If a node upgrades early, it can apply schema changes or configuration differences that other nodes cannot yet handle, which creates intermittent failures and complicates recovery.

Technical breakdown

Why Passbolt sessions must move from disk to database

In a multi-node deployment, local session storage breaks continuity because each server only knows about the requests it handled. Passbolt’s default file-based session model works for a single host, but high availability requires a shared session table so that any node can authenticate the same user flow. This is a classic state-management problem: the application can be stateless at the HTTP layer only if session state is centralized somewhere durable. If it is not, load balancing produces random logouts, inconsistent responses, and broken user experience.

Practical implication: move sessions into a shared database before putting Passbolt behind multiple active nodes.

How Galera changes database availability and failover

Galera turns MariaDB into a multi-primary cluster, meaning writes are replicated across nodes rather than pinned to a single master. That design increases availability, but it also raises the bar for consistency: cluster membership, firewall rules, and node startup order all matter. The cluster address defines who participates in replication, and a mismatched configuration can make one node appear healthy while silently diverging from the rest. In practice, high availability is not only about surviving a node failure, but about making sure the remaining nodes agree on state after failover or recovery.

Practical implication: validate cluster size and replication health on every node before treating the environment as production-ready.

Why certificate and configuration replication is part of identity resilience

When requests can land on any server, each node has to present the same trust posture. Passbolt’s guidance to copy the application configuration, GPG material, JWT assets, and certificates ensures that users do not see different behaviours depending on which node answers. This matters because identity systems fail badly when trust material is inconsistent across replicas. A load balancer can distribute traffic, but it cannot reconcile mismatched secrets, keys, or application settings. That is why availability work in identity platforms always includes configuration synchronization, not just service redundancy.

Practical implication: treat certificates, GPG material, JWT files, and application config as replicated identity assets.

NHI Mgmt Group analysis

Availability is part of identity governance, not a separate ops concern. A password vault is a control plane for credentials, so its uptime directly affects authentication, privilege use, and incident response. When the system is down, the organisation has not only lost a tool, it has lost the operational path to secrets needed for access recovery and emergency administration. The practical conclusion is that identity resilience must be measured in service continuity, not just backup existence.

Shared session state is the hidden dependency in multi-node identity services. This article shows that a high-availability design fails if session handling remains local to each node. That is a reminder that identity platforms often look stateless from the outside while still depending on stateful trust artifacts underneath. Practitioners should treat session architecture as part of the availability boundary, especially when load balancing credential or approval workflows.

Configuration drift becomes a security problem the moment nodes are interchangeable. The article’s need to copy passbolt.php, GPG, JWT, and certificate material across all servers illustrates that failover only works when identity-relevant configuration is synchronized. If one node diverges, the result is not just an outage risk but inconsistent trust behaviour. The practical conclusion is that replication for identity platforms must include security material, not only data tables.

Identity infrastructure needs blast-radius thinking, even when the topic is availability. Three-node clustering reduces single-server dependency, but it also increases the importance of consistent change management during upgrades and certificate handling. A disciplined HA design does not merely keep systems online, it prevents partial failure modes where some nodes are usable and others are not. The practical conclusion is to govern identity platforms as clustered trust systems with tightly controlled change windows.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree that governing AI agents is critical to enterprise security.
• For a broader governance lens, NHI Lifecycle Management Guide shows why provisioning, rotation, and offboarding must stay synchronized across the identity stack.

What this signals

Identity teams should read this as a reminder that availability engineering and governance engineering are now inseparable. The more a password vault or credential platform becomes a shared trust service, the more configuration drift, state replication, and change coordination need to be managed like access controls rather than just infrastructure tasks.

Session-state dependency: once authentication continuity depends on shared state, the failure of a single replica can cascade into user-visible access loss even when the front end still responds. That is why HA planning for identity systems has to include replicated session storage, synchronized trust assets, and tested recovery paths.

With 69% of security leaders saying identity management must fundamentally shift to address agentic AI systems, the broader lesson is that identity controls are being asked to support more dynamic runtime behaviour than they were built for. That pressure will only increase the value of architectures that keep trust state portable across nodes and recoverable during failure.

For practitioners

• Centralize session storage before scaling out Move application sessions into a shared database so any Passbolt node can continue an authenticated workflow without relying on local disk state.
• Validate cluster health on every node Check wsrep_cluster_size and replication status after bootstrap, restart, and node replacement so silent split-brain or partial membership does not go unnoticed.
• Replicate identity material alongside data Synchronize passbolt.php, GPG files, JWT assets, and certificates across all nodes with preserved permissions, because requests may land on any server.
• Govern upgrades as coordinated changes Apply application and database migrations across the cluster in a tightly controlled sequence so one node does not move ahead of the others and create inconsistent behaviour.

Key takeaways

• High availability for a password vault is an identity governance problem because users depend on it for access continuity, not just convenience.
• Shared sessions, synchronized trust material, and replicated database state are the controls that make multi-node credential services usable under failover.
• If upgrades, certificates, or configuration drift are not coordinated across nodes, a clustered identity service can fail in ways that look intermittent but have real access impact.

Key terms

• High Availability: A deployment pattern that keeps a service usable when a node or component fails. In identity systems, availability is inseparable from access continuity because users, secrets, and approvals may depend on the service at any moment, including during incident response or emergency administration.
• Session State: The information a system keeps to remember an authenticated user or workflow between requests. In clustered identity platforms, session state must be shared or replicated, otherwise different nodes will behave differently and users may be forced to reauthenticate or lose workflow continuity.
• Database Replication: The process of copying database changes across multiple nodes so they remain aligned. For credential and identity services, replication is what makes failover possible, but it only works when schema changes, node membership, and data consistency are governed as one operational system.
• Configuration Drift: Any divergence between nodes that should behave the same way. In a high-availability identity service, drift in certificates, keys, application settings, or database parameters can create inconsistent trust decisions, broken authentication flows, or partial outages that are hard to diagnose.

What's in the full article

Passbolt's full article covers the operational detail this post intentionally leaves for the source:

• Exact MariaDB and Galera configuration snippets for building the cluster topology
• Step-by-step commands for bootstrapping the first node and adding the remaining nodes
• Healthcheck output and troubleshooting guidance for GPG-related errors
• Load balancer and DNS failover options for routing traffic across the three servers

👉 Passbolt's full article includes the cluster bootstrap steps, replication checks, and recovery considerations.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.