secure k8 s

High availability

Summary: OpenBao runs N nodes; one wins a storage-backed lock and becomes active, the rest stand by. HA protects against outages, not against single-node throughput limits.

Sources: raw/docs/concepts/ha.md, raw/docs/internals/high-availability.md, raw/blog/2026-03-25-improved-horizontal-scalabilty.md.

Last updated: 2026-05-19

Leader election

One server grabs a lock in the storage backend → active node. The rest are standbys. If a standby receives a request it either forwards it to the active node (transparent to the client) or redirects the client (HTTP 307) depending on cluster state and config (source: raw/docs/concepts/ha.md).

HA does not give horizontal scalability — until recently

Historical limit: the data store, not OpenBao core, is the bottleneck. Adding standbys did not increase throughput because standbys did not serve requests.

This is changing. OpenBao v2.5.0 introduces standby read serving — standbys can answer read requests directly, a first step toward real horizontal scalability (source: raw/blog/2026-03-25-improved-horizontal-scalabilty.md).

The longer-term roadmap (source: raw/blog/2025-02-26-vision-for-namespaces.md, raw/blog/2025-10-20-roadmap-2.0.md) is to ship per-namespace data sharding.

Storage that supports HA

When you start a server you’ll see (HA available) next to the storage line if the backend supports an HA lock (source: raw/docs/concepts/ha.md). raft does; postgresql does; filesystem does not.

You can split data from lock — storage = ... for the blobs plus ha_storage = ... for the lock — when the data backend lacks locking (source: raw/docs/configuration/index.md).

Upgrading an HA cluster

Has its own playbook: step-by-step node replacement, leader handoff order (source: raw/docs/upgrading/ha-upgrade.md). See upgrading.