cloudparts

OpenBao

The open-source fork of HashiCorp Vault, kept under the MPL after Vault’s 2023 licence change: the same API, bao instead of vault, and namespaces without an enterprise licence.

OpenSSF · Sandbox
What it is
Secrets management
Part of
Fork of HashiCorp Vault
Type
Open source
Made by
Open Source Security Foundation
Foundation
Open Source Security Foundation, sandbox. Part of the Linux Foundation
License
MPL 2.0
Facts checked
28 October 2026
Website Source code

What it is

OpenBao works the way Vault does, because it started as a copy of Vault’s last MPL-licensed code. It is a server that keeps secrets encrypted in storage, starts sealed until enough Shamir key shares or a KMS unseal it, logs clients in through auth methods such as Kubernetes or OIDC, and hands out leased secrets: key-value data, short-lived database users, certificates from its PKI engine and encryption as a service from Transit. The project says its API should be compatible enough that existing Vault clients don’t notice the difference. Its migration guide moves a Vault 1.14.1 Community cluster on Raft storage; newer Vault versions and Vault Enterprise are untested, tokens take a shorter format, and fewer plugins are built in.

Since the fork, OpenBao has added features Vault keeps for its Enterprise edition or doesn’t have. Namespaces for multi-tenancy arrived in 2.3 in 2025, and 2.6 lets each namespace have its own seal. Since 2.5, standby nodes can serve reads, first on Raft storage and since 2.7 on PostgreSQL too, and 2.7, released on October 5, 2026, added ML-DSA and ML-KEM post-quantum algorithms. IBM engineers started the fork at LF Edge in December 2023; 2.0, the first GA release, followed in July 2024, and in June 2025 the project moved to the OpenSSF, where it is a sandbox project. GitLab is building its native CI secrets manager on it.

Why teams pick it

  • OSI open source under MPL 2.0 and neutral governance, so it can be embedded in products and offered as a service, which Vault’s Business Source License restricts
  • Close to a drop-in for Vault Community: the same API, auth methods and secrets engines, so most clients and integrations keep working
  • Namespaces and per-namespace seals at no cost, where Vault’s namespaces need Enterprise or HCP Vault Dedicated
  • Read scaling on standby nodes, with Raft or PostgreSQL as storage

Watch out for

  • Migration from Vault is tested only from 1.14.1 Community; later Vault versions and Enterprise clusters are unsupported
  • Fewer plugins ship by default, and mounts whose plugin isn’t built in are skipped at startup until you deal with them
  • The same operational work as Vault: unsealing after restarts, a storage cluster, backups and upgrades
  • Still a sandbox project, the OpenSSF’s earliest stage, and reads from standby nodes can be slightly stale

More of the HashiCorp Vault family

What all secrets management have in common →Compare side by side →
HashiCorp VaultCommercialA secrets server that can mint short-lived database and cloud credentials on demand, not just store passwords.+1 OpenBao

How it fits with other technologies

A namespace per team, addressed with the same API paths as Vault · bash

export BAO_ADDR=https://bao.internal:8200

bao namespace create team-a/                  # no enterprise licence needed
bao write team-a/sys/mounts/kv type=kv        # a KV engine inside the namespace
bao write team-a/kv/stripe api_key="$STRIPE_KEY"
bao read team-a/kv/stripe

See it in a real stack

No architecture uses OpenBao yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2023–2026

In August 2023 HashiCorp moved Vault from the Mozilla Public License to the Business Source License. Engineers at IBM working on Open Horizon, an LF Edge project, started a fork of the last MPL code, and in December 2023 it was announced as OpenBao, incubated at LF Edge with IBM developers leading it, though IBM had not officially endorsed it. EdgeX Foundry, another LF Edge project, later adopted it as its secret store.

OpenBao 2.0, the first GA release, came out in July 2024 and concentrated on stabilising the fork; it also dropped mlock and slimmed the binary. From 2025 the project began adding features Vault keeps for paying customers, starting with namespaces in 2.3. In June 2025 it moved from LF Edge to the OpenSSF, its technical steering committee saying the security foundation better matched its contributors and mission. In 2026 it added read scaling, per-namespace seals and post-quantum algorithms, reaching 2.7 in October.

Why it’s built this way

Fork from the last open-source Vault
Starting from MPL-licensed Vault 1.14 kept the API, clients and integrations people already used, so moving could be a migration of storage rather than a rewrite.
Stay API-compatible with Vault
Existing clients, SDKs and tools that speak the Vault API, including the X-Vault-Namespace header, keep working, and namespaces follow Vault Enterprise’s model to ease migrations.
A smaller core, with integrations as plugins
OpenBao ships fewer plugins in the binary and has moved integrations such as KMS auto-unseal and HSM-backed keys into external plugins, so they can be released on their own schedule, independent of the core.

Timeline

  1. 2023

    HashiCorp relicenses Vault in August; OpenBao announced at LF Edge in December

  2. 2024

    OpenBao 2.0, the first GA release, in July

  3. 2025

    Namespaces in 2.3; moves to the OpenSSF as a sandbox project in June

  4. 2026

    Read scaling in 2.5; per-namespace seals in 2.6 in August; 2.7 on October 5

Sources16 · facts checked 28 October 2026

Improve this page on GitHub