HashiCorp Vault vs OpenBao: a thorough comparison for platform teams

If you are picking a secrets manager today and your shortlist starts with HashiCorp Vault, you owe yourself an honest look at OpenBao. It is no longer a curiosity. It runs in production at GitLab. It is the default secret store in EdgeX Foundry 4.0. It sits under the Open Source Security Foundation with a published roadmap, a working governance model, and a release cadence that has been remarkably steady since GA. And it is licensed under MPL 2.0, which matters more than most evaluations admit.

This is not a hot take and it is not a hit piece on either project. I have shipped Vault clusters into regulated environments and followed both projects closely since the fork. The right answer is rarely obvious, and it almost never matches the loudest opinion on a given week. So this is the long, careful version: licenses, feature parity, the Enterprise features that actually matter, the gaps OpenBao still has, the migration path, and a decision framework you can use without guessing.

TL;DR

• HashiCorp Vault is now under BUSL 1.1 and owned by IBM. OpenBao is an MPL 2.0 fork from Vault 1.14 that lives under the OpenSSF.
• For 80% of basic use cases (KV, PKI, dynamic database credentials, Kubernetes auth, Raft HA) the two are functionally interchangeable.
• OpenBao has closed major Enterprise gaps: open-source namespaces, HSM/PKCS#11 unsealing, the Transform secrets engine, and standby-node read scalability are all in mainline now.
• Vault Enterprise still wins on Performance and DR replication, Sentinel policies, FIPS 140-3 builds, and a managed offering (HCP Vault Dedicated).
• If you build a product on top of a secrets manager, contribute upstream, or want to avoid future IBM licensing decisions, OpenBao is the safer foundation.

Table of contents

• Why this comparison exists at all
• The license question, in plain terms
• Where the two projects came from
• Feature parity, the honest version
• The Enterprise features that still matter
• Operational concerns: HA, replication, scale
• Kubernetes integration today
• Migrating from Vault to OpenBao
• Performance and footprint
• Community health and governance
• When Vault is the right answer
• When OpenBao is the right answer
• When it is genuinely a wash
• Risk: where could each one go wrong?
• Key takeaways

Why this comparison exists at all

For nine years there was no Vault comparison to make. HashiCorp's secrets manager was the one most teams reached for, the documentation was deep, the community was healthy, and the license was MPL 2.0. Building on top of it carried no special risk.

That changed on August 10, 2023, when HashiCorp moved every product in its portfolio from MPL 2.0 to the Business Source License 1.1. Vault 1.14 was the last MPL release. Vault 1.15 onwards ships under BUSL. The license carves out a four-year delay before each release reverts to MPL, and adds an Additional Use Grant that prevents anyone from offering a "competitive offering" against HashiCorp's paid products.

OpenBao was announced four months later at the Open Source Summit Tokyo, in coverage that hit on December 8, 2023. The first GA release shipped on July 16, 2024 as v2.0.0. IBM closed its $6.4 billion acquisition of HashiCorp on February 27, 2025, and Vault is now an IBM Software product. As of April 2026 the BUSL has not been reversed, and there is no public signal that it will be.

So the comparison exists because the underlying product split into two. They share the same DNA, but the projects have started to diverge in real ways, and the choice in front of you is no longer just "use Vault."

The license question, in plain terms

License debates get philosophical quickly. The practical version is simpler.

Vault is BUSL 1.1. The exact Additional Use Grant in the Vault LICENSE file reads: "You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with IBM Corp's paid version(s)." Each release reverts to MPL 2.0 four years after publication. Internal use, modification, redistribution, professional services around it, and contribution back are all permitted. What is not permitted is building a managed secrets-management SaaS on top of Vault and competing with HCP Vault Dedicated.

OpenBao is MPL 2.0. No Additional Use Grant, no competitive offering clause, no four-year delay. You can embed it in a product, ship it as a managed service, and charge for it. You contribute back without a CLA equivalent that locks contributions into a BUSL product.

For a single company running secrets management for its own engineers, BUSL has zero practical impact. You are not competing with HCP Vault. You can install Vault, scale it, modify it, and run it for a decade without ever bumping into the license. This is the case for most readers, and it is worth saying clearly so the conversation does not become hysterical.

For a vendor building a product, the calculus inverts. If your product includes a secrets manager and you are not sure whether your offering counts as "competitive" with HCP Vault, you are now in legal territory you did not have to be in. GitLab is the cleanest public example: they need to embed a secrets manager in their CI/CD pipelines and contribute fixes back, and they could not do that under BUSL without legal exposure. They picked OpenBao. That is a reasonable answer to a real problem.

For organizations that simply prefer OSI-approved licenses (governments, certain procurement processes, open-source-first policies), MPL 2.0 is the only option of the two.

Where the two projects came from

OpenBao did not appear out of nowhere. The first working group meeting was in November 2023 with engineers from IBM's Open Horizon edge-computing team, before the IBM-HashiCorp acquisition was even announced. Sebastian Stadil (CEO of Scalr, also one of the OpenTofu organizers) helped bring the project public. The fork point was Vault 1.14.0 (the last MPL 2.0 release), the binary was renamed bao, and the project joined LF Edge in April 2024.

In June 2025 OpenBao moved to a more appropriate home and joined the OpenSSF as a Sandbox project. Worth being precise here: OpenBao is not a CNCF project. The OpenSSF is a separate Linux Foundation sub-foundation focused on open-source security, and that is where OpenBao now lives.

The active backers as of April 2026:

• GitLab. Officially joined July 2024, achieved voting status October 2024. Alex Scheel is both a GitLab Staff Backend Engineer and the OpenBao Technical Steering Committee Chair. GitLab is using OpenBao as the native secrets manager for its CI/CD pipelines.
• IBM (via the Open Horizon project, before the HashiCorp acquisition).
• Orange. The French telecom endorsed OpenBao's joining LF Edge for fitting their Sylva 100% open-source policy.
• EdgeX Foundry. Replaced Vault with OpenBao as the default secret store in EdgeX 4.0 "Odesa" on April 1, 2025.
• Percona. Uses OpenBao as the KMIP key provider for PostgreSQL transparent data encryption.
• ControlPlane. Launched a commercial enterprise support offering for OpenBao on March 12, 2026.

Vault, for its part, now sits under IBM Software (not Red Hat). That organizational placement matters. IBM Software is a commercial software division. Red Hat is the open-source platform division. Where a product gets shelved internally tells you something about how IBM intends to operate it.

Feature parity, the honest version

Most of what you actually use day to day works the same on both. Some things are now identical only on OpenBao. A few things still belong to Vault Enterprise alone. Treat the matrix below as a working checklist, not gospel: features ship every quarter on OpenBao and the gap closes on a monthly basis.

Secrets engines

The headline here is the Transform secrets engine. In Vault, this is part of the Advanced Data Protection module and you pay an Enterprise license for it. In OpenBao it is mainline and free. If you are using format-preserving encryption or tokenization for PCI-adjacent data, that is a real cost difference.

The MongoDB removal is interesting. OpenBao removed the MongoDB database plugin on principle: MongoDB switched to SSPL, which is not OSI-approved, and the project chose not to ship integrations for non-OSI software. If you depend on dynamic MongoDB credentials, that is a friction point you need to plan around.

Auth methods

Most teams will not notice a difference. If you depend on SAML auth at the Vault layer rather than fronting Vault with an OIDC proxy, that is Enterprise-only territory.

Storage backends

OpenBao made a deliberate choice to simplify. Production storage on OpenBao is Integrated Storage (Raft) or PostgreSQL. The legacy backends (Consul, DynamoDB, S3, etcd, ZooKeeper, MySQL, Cassandra) are gone. Vault Community still supports them as community-maintained options, though HashiCorp itself has been pushing everyone to Raft for several releases.

This is the kind of pruning that hurts during migration if you happen to be on Consul backend, but it pays off in fewer code paths to audit, fewer surprises in release notes, and a smaller blast radius for storage-layer bugs. A reasonable trade-off, in my view.

Seal/unseal

This is where OpenBao quietly leapfrogged: PKCS#11 auto-unseal used to be one of the most cited reasons to buy Vault Enterprise. Now it is in OpenBao. There is one operational difference worth knowing: OpenBao's PKCS#11 implementation requires the key material to be created externally before initialization, whereas Vault Enterprise creates its own keys. If your security policy mandates externally provisioned HSM keys, that is actually a feature. If you wanted Vault to do it for you, that workflow does not exist in OpenBao.

The static seal is OpenBao's own. It reads an AES-256-GCM key from a file or environment variable, which sounds like a foot-gun and in untrusted environments it is. In Kubernetes deployments where the platform itself is the trust boundary (sealed Pod, controlled Secret, etc.) it removes the cloud-KMS dependency cleanly.

Namespaces

This is the single biggest Enterprise-parity story OpenBao has shipped. Namespaces were Vault Enterprise's flagship multi-tenancy feature: a single cluster serving multiple isolated tenants with separate auth, policies, secrets engines, and tokens. They are now open source in OpenBao, GA in v2.3.1 (June 25, 2025).

OpenBao's implementation is API-compatible with Vault Enterprise namespaces by design, including hierarchical namespaces, namespace locking, the -ns CLI flag, and self-service admin delegation. There are still gaps: per-namespace storage backends, namespace sealing, and non-hierarchical namespaces are on the roadmap but not GA. For most multi-team Vault deployments that picked Enterprise primarily for namespaces, OpenBao is now sufficient.

Policies

Vault has Sentinel (Enterprise-only) for policy-as-code: EGPs (Endpoint Governing Policies) attach to API paths and can enforce rules even on unauthenticated paths like login; RGPs (Role Governing Policies) attach to tokens and apply globally. Sentinel can do things ACLs cannot, like time-of-day restrictions or IP-range enforcement.

OpenBao has CEL policies, embedded specifically in PKI and JWT auth. CEL is Google's Common Expression Language. It is narrower than Sentinel: it does not provide cross-cutting path enforcement or token-level governance, only validation logic inside specific plugins. The OpenBao maintainers themselves acknowledge it is weaker than Sentinel or OPA today. The roadmap is to expand CEL across more plugins, but parity is not close.

If your governance model depends on Sentinel, that is a real Vault Enterprise lock-in.

Audit devices

Both projects support the file, syslog, and socket audit devices. OpenBao adds an HTTP audit device for low-volume webhook-based audit reporting, and lets you configure audit devices in the configuration file (not just via API). The latter is genuinely useful: it means you have audit logging from the very first request, before the API is reachable.

CLI and API

The CLIs are syntactically identical. vault kv put secret/foo bar=baz becomes bao kv put secret/foo bar=baz. OpenBao reads both BAO_ADDR and VAULT_ADDR, and most scripts run with a sed replacement of one binary name. The API is the same /v1/... surface. The token format differs (Vault uses hvs./hvb./hvr. prefixes; OpenBao uses shorter s./b./r.). Old Vault tokens stay valid until TTL expiry after migration.

A caveat: OpenBao explicitly does not promise full v1 API backward compatibility forever. The current divergence is small but it will grow as OpenBao adds features without Vault equivalents.

The Enterprise features that still matter

After all the parity wins, what does Vault Enterprise still have that OpenBao does not?

Performance Replication and Disaster Recovery Replication. This is the big one. Vault Enterprise lets you run multiple clusters across regions with synchronous performance replication for read-heavy workloads, plus a separate DR replication channel for failover. OpenBao has no equivalent. The OpenBao-shaped answer is non-voter Raft nodes in a secondary data center that you can promote on failure, which works but is a different operational model. If you currently run a multi-cluster Vault Enterprise topology spanning regions, switching off Vault Enterprise is non-trivial.

FIPS 140-3 builds. Vault Enterprise added FIPS 140-3 Level 1 compliant builds in v1.21 (October 2025). OpenBao has an open issue to ship FIPS builds via Go 1.24's GOFIPS140 support, but no official build exists as of April 2026. ControlPlane offers FIPS 140-3 compliance as part of their commercial support, which I have not personally verified. If FIPS is a hard regulatory requirement, Vault Enterprise is currently the safer answer.

KMIP server. Vault Enterprise can act as a KMIP server for external clients (used by databases, storage systems, and enterprise key management). OpenBao supports KMIP unsealing as a client but does not yet ship a KMIP server. It is on the roadmap, scoped to the Transform engine, but not shipped.

Sentinel. Already covered above.

Secrets Sync. Vault Enterprise can push secrets out to AWS Secrets Manager, Azure Key Vault, GitHub, and similar systems. OpenBao does not have this.

HCP Vault Dedicated. A vendor-managed Vault hosted by HashiCorp/IBM. Available on AWS, Azure, GCP. There is no equivalent managed OpenBao service from any vendor as of April 2026. ControlPlane offers enterprise support and migration services, but not hosted operations.

That list is shorter than it would have been a year ago. The interesting question is whether it shrinks further, stays static, or expands as OpenBao matures.

Operational concerns: HA, replication, scale

Both Vault and OpenBao do active+standby HA via Raft consensus. Three or five nodes per cluster, leader serves all writes, standbys hold read-only replicas of the data.

The new development that matters: OpenBao v2.5.0 (February 2026) added the ability for HA standby nodes to serve read requests locally. This is the feature Vault Enterprise sells as Performance Standby Nodes. Writes still forward to the leader. Reads are eventually consistent and can be disabled per request. The release notes and the announcement post describe the implementation. This used to be a per-node Enterprise license cost. Now it is in mainline OpenBao.

Vault Enterprise still wins on cross-cluster replication. Performance Replication keeps multiple clusters in sync for global read scaling. DR Replication maintains a continuously updated standby cluster for failover. OpenBao's roadmap includes non-voter Raft nodes (already shipped in v2.2) and there is ongoing work on multi-cluster topologies, but synchronous cross-cluster replication is not on the immediate horizon.

Snapshots: Vault Enterprise has built-in automated Raft snapshots. OpenBao ships a separate, officially maintained openbao-snapshot-agent. External tool, same outcome. I would not weigh this heavily.

Kubernetes integration today

This is a place where OpenBao has visible work in progress and a couple of real gaps.

The archived Secrets Operator is the gap that matters. If you sync secrets from your secrets manager into native Kubernetes Secret objects (so Pods can mount them as env vars or files), Vault has a maintained operator for this. OpenBao's first-party operator is dead. The maintainers point users at External Secrets Operator (ESO) with an OpenBao backend, which is well-maintained and used in production by lots of teams. But it is a redirect, and worth being honest about.

For most other Kubernetes patterns (Vault Agent sidecar injection via mutating webhook, init containers, direct Vault Agent integration) OpenBao matches Vault feature for feature.

Migrating from Vault to OpenBao

The official OpenBao migration guide is specific: only Vault 1.14.1 (Community Edition) is the tested baseline. The guide explicitly warns: "This guide will not work on Vault versions 1.15.0 and newer; use at your own risk."

Vault Enterprise migration is not supported. The Raft data format in Vault Enterprise is incompatible with both Vault Community and OpenBao. You cannot snapshot Vault Enterprise and restore into OpenBao.

The supported in-place process is roughly:

1. Stop a follower node, replace the binary with bao, join the cluster via bao operator raft join, unseal, verify voter status.
2. Roll through the followers, then trigger leader step-down, then migrate the former leader.
3. Adjust audit log file permissions if needed.
4. Remove disable_mlock from your config (mlock was removed in OpenBao 2.0).
5. Pull cloud-provider plugins from openbao-plugins (the core OpenBao binary does not bundle them).

Tokens issued by Vault keep working until TTL expiry, so you do not have to rotate every client at the moment of cutover.

There is a known issue (GitHub #1154) where snapshots taken on Vault 1.14.8 cannot be restored on OpenBao 2.2.0 in some scenarios. Test snapshot restore in staging before you trust it in production.

In practice: if you are on Vault Community 1.14, the migration is real but not scary. If you are on Vault 1.15+ or Vault Enterprise, plan for a clean export/import using your own tooling rather than a snapshot transplant. The API compatibility is what makes that workable. You can read every secret out of Vault using the existing API, write it into OpenBao using the same API, verify, and cut over.

Performance and footprint

There has been a noisy GitHub Discussion about OpenBao being thousands of times slower than Vault. The short version: it was a benchmarking error using OpenBao in dev mode (which uses an inmem backend that copies state on every transaction) against Vault on Raft. When the OpenBao maintainers re-ran the test with Raft on both sides, the actual gap was around 21%, attributable to OpenBao's stronger transactional storage guarantees.

That is a single user's anecdotal benchmark, not a published independent benchmark. But it is a reasonable indication that OpenBao is in the same performance ballpark as Vault under realistic conditions. If you are running a single Vault cluster doing a few hundred operations per second (which covers most deployments I see), the difference is operationally invisible. If you are pushing Vault to its scaling limits, you should benchmark your specific workload before switching.

Community health and governance

A two-year-old fork is a fragile thing. Here is what I see when I check the indicators:

OpenBao. Around 5,900 GitHub stars and 408 contributors as of late April 2026. Roughly quarterly minor releases since 2.0 (2.0 July 2024, 2.1 November 2024, 2.2 March 2025, 2.3 June 2025, 2.4 August 2025, 2.5 February 2026, 2.5.3 in April 2026). The October 2025 roadmap retrospective reported 741 commits and 287 active contributors over the prior year, with 10 new committers added. OpenSSF Best Practices badge, five CVEs disclosed and patched in 2025. Working groups for Horizontal Scalability, UI, and PKCS#11/KMS. Single-release support model: no LTS, you are expected to upgrade.

Vault. Around 33,400 GitHub stars. Release cadence under IBM is shifting to "IBM Support Cycle-2" with major releases roughly annual and 2+ years of standard support per major. v2.0 (yes, the same number as OpenBao 2.0, completely independent) shipped April 13, 2026, jumping from v1.21 to align with IBM's support lifecycle. Backed by IBM's engineering organisation with formal support SLAs.

A couple of risk indicators to watch on each side. On the OpenBao side: heavy reliance on Alex Scheel as both the most active committer and the TSC Chair, single-release-only support, the archived Secrets Operator showing that not every component will be maintained forever. On the Vault side: IBM's organisational placement under IBM Software (not Red Hat), the sunset of HCP Vault Secrets in 2026, and zero public signal that BUSL will be reversed.

Both are healthy enough to bet on for the next two to three years. Beyond that is genuine forecasting and you should weigh the licensing implications heavier than the GitHub stars when you do.

When Vault is the right answer

Pick Vault if any of the following apply:

• You need cross-region Performance or DR replication today, and your topology depends on it.
• FIPS 140-3 compliance is a hard regulatory requirement and you are not willing to rely on a third-party support vendor for that compliance.
• Sentinel policies are part of your governance model. CEL in OpenBao is not equivalent yet.
• You need a managed service from the vendor (HCP Vault Dedicated). No managed OpenBao exists.
• You need Vault Enterprise's KMIP server, Key Management secrets engine, or Secrets Sync.
• You are deep in the IBM/Red Hat stack and tighter native integration with OpenShift, Ansible Automation Platform, or watsonx is part of your architecture.
• You are running Vault Community internally with no Enterprise features and no plans to build a product on top of it. The BUSL practically does not affect you, and the larger ecosystem is a real upside.

When OpenBao is the right answer

Pick OpenBao if any of the following apply:

• You are building a product that includes secrets management. BUSL's Additional Use Grant adds real legal risk that MPL 2.0 does not.
• Your procurement, government, or open-source-first policy requires an OSI-approved license.
• You need namespaces (multi-tenant Vault) without paying for Vault Enterprise.
• You use the Transform secrets engine for FPE, masking, or tokenization, and you do not want to pay for Vault Enterprise ADP.
• You want PKCS#11/HSM auto-unsealing without an Enterprise license.
• You are deploying to edge environments (the static seal is a cleaner model for Kubernetes-trusted boundaries).
• You want to contribute upstream without a CLA that puts your contributions in BUSL territory.
• You believe IBM ownership of Vault is a long-term licensing risk and you would rather hedge by building on MPL 2.0.

When it is genuinely a wash

For these workloads, either tool works:

• Plain KV secrets storage with team-based ACL policies.
• PKI for internal services, with auto-renewal via cert-manager or Vault Agent.
• Dynamic database credentials for Postgres, MySQL, or any of the other supported engines.
• Kubernetes auth method, Agent Injector for sidecar secret retrieval.
• Single-region HA via Raft, including read scalability via standby nodes (now both Vault Enterprise and OpenBao 2.5+).
• Terraform/OpenTofu state-encryption keys via the Transit engine.

For these, the API compatibility means your existing code and IaC continues to work. The honest answer is: pick the one whose licensing posture you are more comfortable with and move on.

Risk: where could each one go wrong?

I want to be specific about this rather than hand-wave.

The realistic Vault risk is not that IBM will rip the rug out and go fully proprietary. That would destroy the ecosystem effect that makes Vault valuable. The realistic risk is that BUSL stays, the next license tightening (if any) is incremental rather than dramatic, and the slow drift of Vault toward IBM-internal priorities (alignment with watsonx, Guardium, IBM lifecycle versioning) makes it less attractive for organizations outside the IBM stack. If you read Ned Bellavance's analysis from March 2025, the most likely outcome under IBM is "Vault keeps shipping, BUSL stays, the community ecosystem matters less to IBM than enterprise customers do."

The realistic OpenBao risk is governance fragility. GitLab employs the TSC Chair and is the largest user. ControlPlane provides commercial support but is not large. There is no equivalent of the OpenTofu launch where five companies funded full-time engineers from day one. If GitLab pivots away or Alex Scheel leaves the project, the velocity stutters. The single-release support model means that if you fall behind on upgrades, you have no patch stream to fall back on. The archived Secrets Operator shows that not every component gets the love forever.

Neither risk is so severe that it should drive your decision today. They are real enough that you should account for them in a five-year decision.

Key takeaways

• The license is the foundational difference. Vault is BUSL 1.1, owned by IBM, with a competitive offering clause. OpenBao is MPL 2.0 under the OpenSSF. For internal-only use the practical difference is small. For product builders, vendors, and open-source-first orgs, MPL 2.0 is the safer foundation.
• OpenBao has closed the most painful Vault Enterprise gaps. Open-source namespaces, PKCS#11/HSM auto-unsealing, the Transform secrets engine, and standby-node read scalability are all in mainline. That is a meaningful shift from where the project stood at v2.0.
• Vault Enterprise still wins on Performance/DR replication, Sentinel policies, FIPS 140-3 builds, and a managed offering. If any of those four are non-negotiable, you are picking Vault.
• Migration from Vault Community 1.14 to OpenBao is real but bounded. From Vault 1.15+ or Vault Enterprise, you are looking at an API-driven re-import, not a snapshot transplant. Plan accordingly.
• API compatibility means most code, libraries, and the hashicorp/vault Terraform provider keep working with OpenBao. That is not a permanent guarantee, but for the next couple of years it is.
• The right choice depends on what you are building, not on which project has more stars. Decide on license posture and Enterprise feature dependencies first. The rest follows from there.