Vault and OpenBao: revisit your secrets manager before you renew or migrate

A platform team runs a three-node Vault Community cluster for about sixty services. In one week, a product group asks for its own isolated tenant, which in Vault means namespaces, an Enterprise feature, and finance asks whether the Enterprise quote is really needed. Someone in the meeting says, “Just move to OpenBao. It is Vault with namespaces, and it is free.” Both halves of that sentence are partly true. That is why the decision needs more than one meeting.

This post covers history, what is still the same, what diverged, versions, Kubernetes tooling, migration, risks and a checklist. Facts come from HashiCorp and IBM documentation, the Vault and OpenBao GitHub repositories, release notes and licence files, OpenBao’s own policies and release notes, and the LF Edge and OpenSSF pages, checked on 7 October 2026. Drill results are from my own run. Nothing here is legal advice. For the Terraform side of the same licence story, see the earlier post on OpenTofu and Terraform; this one stays with secrets.

The short version

• Vault has been under the Business Source License 1.1 since version 1.15 (announced 10 August 2023). It still is. In March 2026 the licence file on Vault’s main branch changed the licensor from HashiCorp to IBM; the terms did not change.
• OpenBao forked from the last MPL 2.0 commit, a few commits after Vault 1.14.8. It is MPL 2.0, governed by its own Technical Steering Committee, and has been an OpenSSF sandbox project since May 2025.
• Current releases: Vault 2.1.1 (16 September 2026) and OpenBao 2.7.1 (1 October 2026). Vault Enterprise 2.x follows IBM’s Support Cycle-2 model; OpenBao offers best-effort community support.
• The everyday API is still shared. In my drill, the vault and bao CLIs worked against both servers for KV v2, policies and tokens, with the same HTTP paths and headers.
• OpenBao now ships namespaces, read-serving standby nodes, PKCS#11 auto-unseal and control groups without a licence key. It has no cross-cluster replication, and far fewer plugins are built in.
• OpenBao documents in-place migration only from Vault Community 1.14.1 with Raft and Shamir. In my drill the swap also worked from Vault 2.1.1 on tiny data, but after OpenBao touched the data, Vault could no longer see its own mounts. Plan the move as one way and keep a snapshot.

Where things stand on 7 October 2026

HashiCorp Vault

OpenBao

Latest release

2.1.1, 16 September 2026

2.7.1, 1 October 2026

Licence

BSL 1.1, each version converts to MPL 2.0 four years after publication

MPL 2.0

Owner or home

IBM (acquired HashiCorp, February 2025)

OpenSSF sandbox project under the Linux Foundation

Editions

Community and Enterprise (licence key)

One edition

Support

Enterprise: IBM Support Cycle-2 from 2.x

Best effort by maintainers and community

Release pace

Three minor releases in 2025, two so far in 2026

Two to three minor releases a year, patches roughly monthly

Helm chart

vault-helm v0.34.1 (13 August 2026), app version 2.0.4

openbao-0.30.2 (1 October 2026), app version 2.7.1

Linux amd64 binary (my download)

538 MB

182 MB

The timeline, from the repositories and official announcements:

Date

Event

24 February 2015

First commit in the Vault repository; v0.1.0 tagged on 28 April 2015

10 August 2023

HashiCorp announces the move from MPL 2.0 to BSL 1.1 for future releases

September 2023

Vault 1.15.0, the first BSL release

4 December 2023

Vault 1.14.8, the last tag in the public repository with an MPL licence file

24 April 2024

IBM announces an agreement to acquire HashiCorp

16 July 2024

OpenBao 2.0.0, the first GA release

27 February 2025

IBM completes the HashiCorp acquisition

May 2025

OpenBao moves from LF Edge to the OpenSSF

25 June 2025

OpenBao 2.3.1 with namespaces (2.3.0 was never released)

14 April 2026

Vault 2.0.0; Enterprise moves to IBM Support Cycle-2

23 September 2026

OpenBao 2.7.0 with control groups, external keys and post-quantum algorithms

How we got here

Vault started in 2015 under MPL 2.0. In August 2023 HashiCorp announced that all future releases would move to BSL 1.1, while APIs, SDKs and most libraries would stay MPL 2.0. The Vault licence file names “Vault Version 1.15.0 or later” as the licensed work. One detail is easy to miss: the 1.14.x line also switched. Tags up to 1.14.8 carry the MPL licence file, while 1.14.9 and 1.14.10 carry the BSL one.

The licence matters in three practical ways:

• Internal use is allowed. Production use is permitted unless you offer Vault to third parties, hosted or embedded, in competition with the licensor’s paid versions. Internal use is stated as not competitive.
• Each version converts on its own clock. Each version becomes MPL 2.0 four years after it was first published. For 1.15.0 (September 2023) that falls in 2027.
• The licensor is now IBM on main. A commit on 26 March 2026 replaced “HashiCorp, Inc.” with “International Business Machines Corporation (IBM)”. The v2.1.1 tag still names HashiCorp; I compared the files and only the names differ.

If you build a product or managed service on Vault, read the licence with your legal team. If you run it for your own applications, the licence is mainly a question of long-term trust and pricing.

OpenBao: who runs it

OpenBao came from inside the Linux Foundation. Open Horizon and EdgeX Foundry, both LF Edge projects, used Vault and wanted an OSI-licensed option after the BSL change, so the fork began in late 2023 as an incubation effort under Open Horizon. The LF Edge proposal, presented in February 2024, lists five founding organisations on the steering committee: IBM, IOTech Systems, Viaccess-Orca, WALLIX and ZEDEDA. The fork point, per the project FAQ, is commit 8993802 on Vault’s 1.14 branch (dated 20 December 2023), the last upstream commit before the BSL reached that branch, a few commits after 1.14.8.

Per the governance document, the TSC formed in June 2024 and the project moved to the OpenSSF sandbox in May 2025. The contributing guide now lists six TSC members: IOTech Systems, Wallix, Adfinis (chair), GitLab, SAP and ControlPlane. EdgeX Foundry made OpenBao its default secret store in EdgeX 4.0.

Two policies explain most of OpenBao’s later choices:

• Migration policy (February 2024): aim for API compatibility, with only limited seal and storage compatibility. It says OpenBao “will inevitably, intentionally or otherwise, deviate from upstream”.
• Plugin policy (February 2024): keep OSI-licensed plugins built in; move cloud vendor and non-OSI plugins to openbao-plugins.

The support policy is short: best effort, fixes go into the next release, and releases come roughly monthly. The project itself offers no support contract.

Versions and release pace

Year

Vault minor releases

OpenBao minor releases

2024

1.16 (March), 1.17 (June), 1.18 (October)

2.0 (July), 2.1 (November)

2025

1.19 (March), 1.20 (June), 1.21 (October)

2.2 (March), 2.3 (June), 2.4 (August)

2026 so far

2.0 (April), 2.1 (September)

2.5 (February), 2.6 (July), 2.7 (September)

Vault 2.0 also changed the support model. From the April 2026 (2.x) release, Vault Enterprise follows IBM Support Cycle-2 instead of selected LTS releases: two years of base support, one year of extended support, then three years of sustained support without new fixes. Fixes are not backported across minor releases within a major, so stay on the latest 2.x fix release. The last LTS, 1.19.x, is in extended maintenance until April 2027.

OpenBao patches its two latest minor lines at the same time. On 1 October 2026 both 2.7.1 and 2.6.4 came out with security fixes.

What is still the same

For application teams, the two products still look alike:

• The same HTTP paths (/v1/secret/data/..., /v1/sys/...), the same X-Vault-Token and X-Vault-Namespace headers, and Authorization: Bearer.
• The same policy language, tokens and leases, and the core engines and auth methods: KV, Transit, PKI, SSH, database, AppRole, userpass, JWT/OIDC, certificates, Kubernetes.
• The same CLI shape. bao kv get is vault kv get with a new name, and the bao CLI also read VAULT_ADDR when BAO_ADDR was not set in my run. The vault CLI did not read BAO_ADDR.
• Integrated Storage (Raft) with the same operator raft commands.

Two things already differ. Tokens: Vault issued hvs. tokens of 95 characters in my run, OpenBao s. tokens of 26 characters, so check format validation and secret scanner rules. And both hardened root and rekey endpoints in 2026, differently. Vault 2.0 requires a token for sys/rekey and sys/generate-root. OpenBao 2.5.3 disabled unauthenticated sys/generate-root and 2.6 added authenticated sys/generate-root-token endpoints. Break-glass runbooks for one will fail on the other.

Where they have diverged

Vault columns are from HashiCorp’s documentation, where these features carry the Enterprise label. OpenBao entries are from its release notes and docs. “My drill” marks what I checked myself.

Capability

Vault Community 2.1

Vault Enterprise 2.1

OpenBao 2.7

Namespaces

No (“enterprise-only feature”, my drill)

Yes

Yes, since 2.3 (my drill); per-namespace sealing since 2.6

Standby nodes serve reads

No

Performance standbys

Yes, Raft since 2.5, PostgreSQL since 2.7

Consistency headers X-Vault-Index, X-Vault-Inconsistent

No

Yes

Yes, since 2.7

Cross-cluster DR and performance replication

No

Yes

No replication API in the docs

PKCS#11 HSM auto-unseal

No

Yes

Yes, since 2.2; external plugin since 2.7

Cloud KMS and Transit auto-unseal

Yes

Yes

Yes; cloud KMS seals are external plugins since 2.7

Control groups (second-person approval)

No

Yes

Yes, since 2.7

HSM or KMS keys used by PKI and Transit

No

Managed keys

External keys since 2.7, not API compatible

Supported storage

Raft or Consul; PostgreSQL and others are “community supported”

Same as Community

Raft or PostgreSQL; PebbleDB for a single node; file backend removed in 2.7

Built-in plugins in the dev server catalog (auth, secret, database)

18, 19, 17 (my drill)

Not checked

6, 7, 9 (my drill)

OpenBao also has additions with no Vault counterpart, such as transactional storage, paginated and SCAN lists, CEL-based roles, declarative self-initialisation, OCI plugin download, workflows, and ML-DSA and ML-KEM in 2.7. Vault 2.x, in turn, adds things OpenBao does not have, such as SCIM provisioning and secrets sync with workload identity federation (both Enterprise), and the agent registry described in its 2.0 and 2.1 release notes.

Plugins are the biggest practical gap

OpenBao 2.7.1’s dev server catalog has approle, cert, jwt, kubernetes, oidc and userpass for auth. AWS, Azure, GCP and GitHub auth live in openbao-plugins as separate binaries and OCI images, and 2.7 moved LDAP, Kerberos and RADIUS there too, along with the vendor-specific seals. Secrets engines and database plugins follow the same pattern: no built-in AWS, Azure, GCP or Active Directory engines and no MongoDB plugin, while a Valkey plugin sits next to Redis.

This does not block a migration, but you now track each plugin’s version and checksum next to the core binary. The plugin stanza with plugin_auto_download (2.5) and OCI digest pinning (2.7) help.

Kubernetes tooling

Piece

Vault

OpenBao

Helm chart

vault-helm v0.34.1, MPL 2.0

openbao-helm openbao-0.30.2, MPL 2.0, needs Kubernetes 1.30 or later

Sidecar injector

vault-k8s v1.7.6, MPL 2.0

Chart default image is hashicorp/vault-k8s:1.7.2

CSI provider

vault-csi-provider v1.7.4, BSL 1.1

openbao-csi-provider v2.0.3 (29 July 2026)

Operator

Vault Secrets Operator v1.6.0, BSL 1.1

openbao-secrets-operator repository has no tags; its docs page is marked draft

External Secrets Operator

Vault provider

Documented through the Vault provider, tested with ESO v0.16.1 and OpenBao 2.2.0

The OpenBao chart still pulls HashiCorp’s injector image, which is MPL 2.0 but outside OpenBao’s release process. If you depend on the Vault Secrets Operator, plan for the injector, the CSI provider or External Secrets Operator instead.

Performance and operations

I found no independent benchmark that compares current Vault and OpenBao on the same hardware, and my drill was not a benchmark. The only numbers below come from the OpenBao project’s own run, published in March 2026: two three-node clusters on Azure, OpenBao 2.4.4 with all traffic sent to the active node against 2.5.1 with traffic spread across all nodes.

OpenBao project’s own run

2.4.4 (active node only)

2.5.1 (standby reads)

KV, 500 requests per second, 90% reads: read mean

7.92 ms

5.75 ms

Same test: write mean

87.21 ms

58.08 ms

PKI RSA 2048 issue, 5 per second target: achieved rate

1.33 per second, 99.27% success

5.00 per second, 100% success

The author notes that write-heavy workloads would not improve, and that some API reads, such as dynamic credentials, still write to storage. Standby reads can be stale; 2.7’s consistency headers address that. In Vault, this pattern needs Enterprise performance standbys.

Operational differences that are easy to miss:

• Storage. OpenBao’s docs suggest PostgreSQL as easier than Raft for new teams to operate safely. Vault keeps PostgreSQL as community supported.
• Fast deprecations. OpenBao 2.7 removed the file backend, the HSM image and the built-in cloud seals one release after deprecating them.
• Shared code, shared bugs. Several OpenBao advisories in 2026 cite HashiCorp HCSEC numbers. Watch both advisory feeds.

Migrating from Vault to OpenBao

OpenBao’s guide, “In-Place Migration from Vault CE”, was tested with Vault 1.14.1 Community, OpenBao 2.2.0, Raft storage and Shamir unseal, without auto-unseal. Newer Vault versions are “untested and unsupported”, and OpenBao “makes no guarantees about storage compatibility with Vault”. Vault Enterprise was not tested. Clusters first initialised before Vault 1.3 may need a rekey.

The steps, in short: take a Raft snapshot, install OpenBao on every node with a new storage path, replace followers one at a time (stop Vault, start OpenBao, bao operator raft join, unseal, wait for voter status), then step down the leader and replace it last. The guide warns about audit file ownership, the token format, and plugins OpenBao does not ship, which stay mounted but serve nothing. Vault 2.0 and later always leave one such mount, agent-registry/.

Before you stop anything, collect an inventory:

# On the Vault side, with an operator token
vault version
vault status                        # seal type, storage, HA mode
vault secrets list -detailed        # every mount and its plugin
vault auth list -detailed
vault plugin list -detailed         # external plugins you registered
vault operator raft snapshot save pre-openbao.snap

# Anything not in OpenBao's built-in catalog needs an openbao-plugins
# build or a replacement plan, before the cutover.

For Enterprise clusters, HSM auto-unseal, replication or Enterprise namespaces, the in-place guide does not apply. The lower-risk path is a new OpenBao cluster, a scripted copy of secrets, policies and auth configuration through the API, and applications moved in batches.

Risks to weigh

Staying on Vault. The licence changed once and could change again for new versions. Support terms now follow IBM’s model. Namespaces, replication and HSM support need a licence.

Moving to OpenBao. Support is best effort unless you buy it from a third party. The project moves quickly and removes features within one or two minor releases. Many integrations are now separate plugins with their own maintainers. There is no replication, so disaster recovery means snapshots, PostgreSQL replication or your own design. Tools that check for hvs. tokens, or that assume Vault Enterprise endpoints, may need changes.

Both. Whatever you choose, practise unseal, snapshots, audit devices and break-glass steps, not just document them.

A practical decision checklist

1. Write down what you use: mounts, auth methods, plugins, seal, storage, namespaces, replication, Kubernetes integration.
2. Read the licence for your case: internal platform, product, or managed service. The last two need legal review.
3. Map each feature to a column above. Count the Enterprise features you need and the OpenBao plugins you would depend on.
4. Decide your support model: IBM contract, third-party support, or your own team with best-effort upstream.
5. Check your Kubernetes path and who maintains each image you will run.
6. Run both on a copy. Restore a recent snapshot in a lab and replay real client calls, including renewals and dynamic credentials.
7. Test your tooling: Terraform or OpenTofu code, pipelines, secret scanners, dashboards.
8. Rehearse rollback with a snapshot, not by restarting Vault on data OpenBao has opened.
9. Plan the cutover follower by follower with the leader last, or as a new cluster with batch moves.
10. Read the change pages (OpenBao deprecations, Vault important changes) before every minor upgrade.

Common mistakes

• Calling OpenBao “Vault Enterprise for free”. Some features are rebuilt; replication is not there.
• Assuming any Vault version can be swapped in place. Only 1.14.1 Community with Raft and Shamir is documented.
• Forgetting plugins. A missing plugin does not stop startup; the mount just returns nothing.
• Planning rollback by restarting Vault on the same data. See the drill below.
• Not checking chart images, including the HashiCorp injector image the OpenBao chart uses.
• Reading old docs. The OpenBao Kubernetes overview still says standalone mode uses the file backend, which 2.7 removed; chart 0.30.2 actually configures PebbleDB.

Drill: two servers, one API, and a swap

I ran this on 7 October 2026 on a shared VM container: 8 vCPUs, 15 GB RAM, Debian 13, Linux 6.12. Binaries: OpenBao 2.7.1 from GitHub, Vault 2.1.1 and 1.14.1 from releases.hashicorp.com. SHA-256 checksums matched the published files; I did not verify GPG or Sigstore signatures. Everything listened on localhost, and all processes were stopped afterwards.

Same steps against both dev servers

Both dev servers used in-memory storage. The same script ran against each server with each CLI:

vault kv put -mount=secret payments/db username=app password=s3cr3t-v1
vault kv put -mount=secret payments/db username=app password=s3cr3t-v2
vault kv get -mount=secret -version=1 -field=password payments/db
vault policy write payments-read policy-app.hcl   # read secret/data/payments/*
T=$(vault token create -policy=payments-read -ttl=10m -field=token)
VAULT_TOKEN=$T vault kv put -mount=secret payments/db password=x   # must be denied

# Raw API, identical on both servers
curl -s -H "X-Vault-Token: $VAULT_TOKEN" -X POST \
  http://127.0.0.1:8210/v1/sys/namespaces/team-a

Check

Vault 2.1.1

OpenBao 2.7.1

KV v2 write, read, read of version 1

Worked

Worked

Policy: read allowed, write denied

Yes

Yes

Other project’s CLI against this server

bao worked

vault worked

Same curl with X-Vault-Token or Bearer

Worked

Worked

Token issued

hvs., 95 characters

s., 26 characters

Default mounts in dev mode

Includes agent-registry/

No extra mount

Create namespace team-a

HTTP 404, “enterprise-only feature”

HTTP 200; reads by header and by path prefix worked

sys/generate-root/attempt without a token

403

405, “unsupported operation”

Same with the root token

200

405; sys/generate-root-token/attempt gave 200

Resident memory of the idle dev server, one reading

167 MB

96 MB

In-place swap on a single Raft node

For each source version I started Vault on Raft with one Shamir key share, enabled KV v2, Transit, userpass and an AWS secrets engine (a plugin OpenBao does not ship), wrote data, created a policy and a 2-hour app token, saved a snapshot and stopped Vault. Then I started OpenBao 2.7.1 on a copy of the Raft directory with the same config and unsealed it with the old key.

Step

From Vault 1.14.1

From Vault 2.1.1

Unseal with the old Shamir key

Worked

Worked

KV read with the old root token

Correct value

Correct value

Transit decrypt of ciphertext made by Vault

Correct plaintext

Correct plaintext

Old hvs. app token with its policy

Still worked

Still worked

userpass login

Worked, new s. token

Worked, new s. token

aws/ mount

Listed; “No value found”; “plugin not found in the catalog” in the log

Same, and the same for agent-registry/

Server log

“migrating legacy mount table to transactional layout”

Same

Vault started again on the copy OpenBao had opened

Only cubbyhole/, identity/, sys/ and token/

Only default mounts; policies still listed; KV read refused

Vault on the untouched original copy

Not run

All mounts and data intact

The last two rows are the lesson. OpenBao converted the mount and auth tables to a new storage layout when it unsealed. A comment in OpenBao’s mount.go says going backwards “is not possible without manual reconstruction”. The secrets were probably still in storage, but Vault no longer knew its mounts existed. Rollback means restoring the snapshot or the untouched data directory.

Honest limits: one node, a handful of keys, no TLS, auto-unseal, Enterprise, namespaces in the source, external plugins or load. The swap from 2.1.1 worked here, but OpenBao calls it unsupported, and a larger store may hold something this one did not. Memory figures are single readings.

What to unlearn and re-learn

• Unlearn “a fork is a copy”. Re-learn that after three years, OpenBao and Vault share an API but differ in features, plugins, storage and support.
• Unlearn “Enterprise features need Enterprise”. Re-learn to check feature by feature, because namespaces and standby reads exist in OpenBao while replication does not.
• Unlearn “rollback is starting the old binary”. Re-learn rollback as restoring a snapshot taken before the new binary opened the data.
• Unlearn “the secrets manager is one binary”. Re-learn it as a core, a set of plugins, a seal and a Kubernetes integration, each with its own owner and release rhythm.

Revisit your secrets manager before you renew or migrate

Vault and OpenBao both still do the job well, and neither choice is wrong in general. Learn what your cluster actually uses, unlearn the idea that the licence alone decides the matter, re-learn the differences that matter on the day of an outage, such as plugins, unseal, replication and support, practise the swap and the rollback on a copy, and apply the decision with a written plan. The renewal date or the next major upgrade is a good time to do this, because then the change is planned and not forced.

Sources

• HashiCorp blog: HashiCorp adopts Business Source License, 10 August 2023
• Vault commit: License changes to BSL, 10 August 2023
• Vault LICENSE on main, Vault LICENSE at v2.1.1 and licensor change commit, 26 March 2026
• Vault releases, including v2.1.1, v2.0.0 and v1.15.0
• Vault docs: release notes and important changes
• Vault docs: Enterprise support and IBM Support Cycle-2
• Vault docs: namespaces, replication, performance standbys, consistency, control groups, managed keys, HSM support
• Vault docs: PKCS#11 seal, AWS KMS seal, Integrated Storage, PostgreSQL storage
• IBM newsroom: IBM to acquire HashiCorp, 24 April 2024 and IBM completes acquisition, 27 February 2025
• LF Edge: OpenBao project proposal
• OpenBao website and FAQ, GOVERNANCE.md, CONTRIBUTING.md (TSC members), fork point commit 8993802
• OpenBao blog: OpenBao joins the OpenSSF, 17 June 2025 and EdgeX Foundry selects OpenBao, 18 March 2025
• OpenBao policies: migration, plugins, support and end of life
• OpenBao releases, including v2.7.1, and release notes for 2.2, 2.3, 2.5, 2.6 and 2.7
• OpenBao blog: v2.6 release and v2.7 release
• OpenBao blog: Improved Horizontal Scalability, 25 March 2026 (project’s own benchmark)
• OpenBao docs: In-Place Migration from Vault CE and deprecation notices
• OpenBao docs: namespaces, high availability, storage, seal, external keys, Kubernetes
• OpenBao source: internal/vault/mount.go
• openbao-plugins repository
• openbao-helm release openbao-0.30.2 and chart values; openbao-csi-provider tags; openbao-secrets-operator
• vault-helm v0.34.1, vault-k8s releases, Vault Secrets Operator releases and licence, vault-csi-provider licence
• External Secrets Operator docs: OpenBao
• HashiCorp releases: Vault binaries