OpenBao

Last reviewed Sep 13, 2026 · 779 words

OpenBao exists because HashiCorp moved Vault to the Business Source License in August 2023, and a group of contributors forked the last MPL-2.0 release rather than accept it. It is now a Linux Foundation project with 7,267 stars, the same API surface as Vault, and the same operational weight: a sealed server that will not answer requests after a reboot until someone, or something, unseals it. That one property is the reason I tell most self-hosters to admire it and run something else.

It is a secrets engine for machines, not a password manager for people

The category label puts OpenBao next to Vaultwarden, and the two share nothing but the word "secret". Vaultwarden stores your streaming password and fills it in a browser. OpenBao issues a database credential that expires in 1 hour to a service that authenticated with a Kubernetes service account token, signs an SSH certificate for a deploy job, or encrypts a payload through its transit engine so an application never touches the key. If you have no automated consumers of secrets, you have no use for it, and the password managers category has what you want.

The licensing is the whole point

Vault remains free to download under BSL, and for a homelab that license changes nothing in practice. What changed is the guarantee. A BSL project can restrict future use, and its community edition ships whatever the vendor decides to ship. HashiCorp is now part of IBM, which does not make Vault worse, but it does make "what will the free tier look like in 3 years" an open question. OpenBao's MPL-2.0 answer is that the code stays open, governance is public, and the roadmap is argued in the open. It keeps the Vault API paths and works with most existing Vault tooling, so switching costs are low in either direction; that compatibility is the escape hatch.

Running it: dev mode lies to you

bao server -dev

That command starts an unsealed, in-memory server with a root token printed to the console, and it is the last time OpenBao will be that friendly. A real deployment needs a storage backend (integrated Raft storage is the sane default and keeps everything under one data directory), TLS, and an unseal strategy. Initialise with bao operator init, which produces 5 key shares of which 3 are needed by default, and after every restart run bao operator unseal 3 times with 3 different shares. Automate that with a cloud KMS or accept that a power cut means secrets are unavailable until a human types keys. The official container image is published at quay.io/openbao/openbao. Budget 256 MB of RAM at rest and considerably more attention.

What a homelab actually gets from it

Three uses justify the effort at small scale. First, dynamic database credentials: a PostgreSQL role that OpenBao creates per application with a TTL, so a leaked connection string dies on its own. Second, a private PKI: an internal CA that issues short-lived certificates for services behind your proxy, which pairs well with the way Authentik and similar identity tools want everything on TLS. Third, transit encryption for an app you wrote yourself. If none of those are on your list, a .env file with 600 permissions and a good backup is not embarrassing; it is proportionate.

The honest cost

"Young fork still stabilizing" is the one listed con, and it is accurate. Some Vault plugins and storage backends were dropped in the fork, documentation lags Vault's, and the community is a fraction of the size, which matters at 2 a.m. when a Raft peer refuses to rejoin. Backups are bao operator raft snapshot save, and restoring one into a fresh cluster is a procedure you must rehearse, because the alternative is discovering that every certificate and database credential in your stack was minted by a server you can no longer start. Infisical is the friendlier option in the same space if you want a web UI and secrets sync without the unseal ritual.

What I'd do

Run OpenBao only if something in your stack authenticates and asks for secrets by API. Then: single node with Raft storage, TLS from your own proxy, init with 5 shares and a threshold of 3 stored in 3 physical places, a nightly Raft snapshot copied off the box, and a written unseal runbook taped inside the rack. For everyone else, Vaultwarden for human passwords and environment files for services, and revisit OpenBao when you write your first service that should never see a static credential.