In August 2023, HashiCorp changed Vault's license from MPL 2.0 (Mozilla Public License 2.0, an open source license) to BSL 1.1 (Business Source License 1.1, a source-available license: the code is readable but it is not open source). In response, the community created OpenBao, a fork (a copy of the code that evolves on its own) maintained by the Linux Foundation under the MPL 2.0 license (100% open source in the OSI sense, that is, recognized by the Open Source Initiative).
This page helps you choose between Vault and OpenBao according to your technical, legal and organizational constraints. It details neither the license (BSL license), nor the Vault editions (CE vs Enterprise), nor the installation of OpenBao (the OpenBao guide (in French) covers it): it compares them in order to decide. It assumes you know what a secrets vault is; otherwise, start with the introduction to HashiCorp Vault (in French). CE stands for Community Edition, the free edition of Vault.
What you will learn
- Retrace the history of the fork and the reasons for the split
- Tell the governance and license differences apart
- Identify the features specific to each solution
- Apply the decision criteria to your context
- Measure what the OpenBao project actually tests regarding migration
Why are there two projects?
What is the history of the fork?
The story fits in four dates. Reading it helps you see that OpenBao is not a rewrite but a continuation of the last open source Vault, which explains why both products are so close today.
Before August 2023: Vault was under the MPL 2.0 license, an open source license recognized by the OSI. Companies and the community could use it, modify it and redistribute it freely.
August 2023: HashiCorp announces the switch to BSL 1.1 (Business Source License) for Vault, Terraform and other products. This license restricts some commercial uses, notably the creation of competing offers.
December 2023: The Linux Foundation announces OpenBao, a fork of Vault 1.14 (the last MPL 2.0 version) maintained by the open source community.
2024-2026: OpenBao evolves independently, adds features (namespaces,
control_group, auto-unseal improvements), and builds its own ecosystem.
What does it change for you?
The license change does not have the same consequences depending on how you distribute the software. Find your profile in the first column: internal user or consultant, the BSL does not concern you. It only becomes binding if you resell a paid service built around Vault, or if your organization forbids by principle any license not validated by the OSI.
| If you are... | Impact |
|---|---|
| Internal user | No direct impact, both solutions work |
| Consultant | No impact, you can advise on and deploy both |
| SaaS vendor | To assess depending on your model (see BSL license) |
| Committed to OSI open source | OpenBao is the only option |
How do Vault and OpenBao compare, criterion by criterion?
Read this table by looking for the rows that diverge, not by counting crosses. On the building blocks you will use every day (secrets engines, authentication methods, built-in Raft storage), the two products are equivalent: it is the direct consequence of the fork. The rows that really tip a choice are the license, the availability of namespaces and the depth of the plugin ecosystem.
| Criterion | Vault CE | OpenBao |
|---|---|---|
| License | BSL 1.1 (source-available, not open source) | MPL 2.0 (OSI open source) |
| Governance | HashiCorp (IBM since February 2025) | Linux Foundation / OpenSSF |
| Code base | Continuous development | Fork of Vault 1.14 + own evolutions |
| API compatibility | Reference | Derived from Vault 1.14, the two APIs have diverged since |
| Maturity | 10+ years, very stable | Nearly 3 years since the fork announcement (Dec. 2023), growing fast |
| Secrets engines | Complete (KV, Transit, PKI, Database, SSH, cloud) | Identical + evolutions |
| Auth methods | Complete (userpass, AppRole, K8s, OIDC, LDAP, cloud) | Identical |
| Namespaces | No, Enterprise only | Yes, included since 2.3.1 |
control_group policy | No, Enterprise only | Yes, added in 2.7.0 |
| Auto-unseal | KMS, Transit, HSM | KMS, Transit, HSM + improvements |
| Integrated Storage (Raft) | Yes | Yes |
| Replication | No, Enterprise only | No, not documented; high availability is |
| Login MFA | Yes, included since Vault 1.10 (step-up MFA: Enterprise only) | Yes, documented by OpenBao |
| Sentinel | No, Enterprise only | No, proprietary HashiCorp technology |
| Plugins | Large ecosystem | Compatibility maintained, smaller ecosystem |
| Cloud integrations | Very complete | Catching up, community focus |
| Commercial support | HashiCorp / IBM | Community + vendors (Adfinis, etc.) |
| Documentation | Very complete | Under construction, good quality |
A few terms from the table. OpenSSF is the Open Source Security Foundation, a Linux Foundation project. Raft is the consensus protocol behind the built-in storage, and HSM a hardware security module (a tamper-resistant device that holds keys). Auto-unseal lets Vault open itself at startup with a key held outside, instead of asking humans to enter key shares. Sentinel is HashiCorp's policy-as-code language, and Step-up MFA asks for a second factor when a sensitive path is reached rather than at login.
What are the key differences in depth?
License and governance
License and governance are two distinct questions that are often confused. The license says what you are allowed to do with the code; the governance says who decides what goes into the product. Vault is permissive in use but steered by a single vendor, now a subsidiary of IBM. OpenBao has no usage restriction and is steered by a foundation, with the usual corollary: decisions are public but slower.
Vault (BSL 1.1):
- Source code visible and modifiable
- Internal use allowed without restriction
- Restriction: no paid offer competing with IBM's paid versions
- Governance: HashiCorp (IBM) alone decides on the evolutions
OpenBao (MPL 2.0):
- Full OSI open source license
- No usage restriction
- Governance: Linux Foundation, community contributions
- Public roadmap, collective decisions
Namespaces and control groups: the functional gaps
Namespaces let you fully isolate environments inside a single cluster. Each namespace has its own secrets, policies and auth methods. It is the most visible functional gap between the two products: Vault reserves them for its Enterprise edition, OpenBao includes them.
| Solution | Namespaces |
|---|---|
| Vault CE | No, not available |
| Vault Enterprise | Yes, included |
| OpenBao | Yes, included since 2.3.1 |
If you manage several teams or customers on the same infrastructure, namespaces considerably simplify management: full isolation between tenants, administration delegated per namespace, no need to deploy several clusters.
OpenBao added namespaces with version 2.3.1, published on June 25, 2025 (2.3.0 was never published as a stable version). This feature was reserved for Vault Enterprise: it is a strong argument for organizations that need multi-tenancy without paying for the Enterprise license.
Namespaces are no longer the only gap. OpenBao's 2.7.0 version added a control_group policy stanza, a feature that Vault also reserves for Enterprise. Remember the trend rather than the list: the gaps change with every version, and the comparison in this table must be rechecked before any decision.
Maturity and stability
OpenBao's maturity is not measured by its apparent age. The project starts from the Vault 1.14 code, proven for years in production, and what is really young are the features added since the fork and the new team's release process. In other words, the risk does not lie in the secrets engine, but in the new building blocks and in the number of public incidents the project has been able to learn from.
Vault:
- 10+ years of development
- Very widely deployed in production
- Security process proven by these years of use
- Exhaustive documentation
OpenBao:
- Nearly 3 years since the fork announcement (December 2023)
- Active and growing community
- Code base inherited from Vault, hence solid
- Less feedback from massive production use
Ecosystem and integrations
This is the criterion that costs the most when discovered too late. A secrets manager is never alone: it is consumed by Terraform, by a Kubernetes operator, by an Ansible provider, by your application SDKs. Each of these elements authenticates against an API and talks to a secrets engine; the inventory below tells you where to look for friction points before committing.
Vault:
- Official plugins for all clouds (AWS, Azure, GCP, Alibaba...)
- Native integrations with Terraform, Kubernetes, Nomad
- Ansible, Puppet, Chef providers
- Official SDKs (Go, Python, Ruby, Java, .NET)
OpenBao:
- API derived from Vault 1.14, which the two products have evolved each on their own
- Most tools work (with adaptation sometimes), for example the Ansible lookup (in French) that targets both
- Community contributions for integrations
- Focus on the most common use cases
In practice: if you use an exotic plugin or integration, check its OpenBao compatibility before committing. A plugin missing from OpenBao leaves its mount unserved after a migration (see below).
Support and community
On a component that holds all your secrets, the real question is not "who answers questions" but "who can I call at three in the morning when the cluster refuses to unseal". Vault offers a support contract with commitments, OpenBao relies on the community and on third-party providers. If you have neither a contract nor in-house skills, the documentation gap between the two projects becomes your safety net.
Vault:
- Commercial support from HashiCorp / IBM (paid)
- Community forums
- Complete official documentation
- Training and certifications
OpenBao:
- Active community (Slack, GitHub)
- Commercial support via third-party vendors (Adfinis, etc.)
- Documentation under continuous improvement
- No official certification
What are the decision criteria?
The three tables that follow are not lists of arguments to weigh against each other: a single criterion can be enough to settle. If one of the rows describes a constraint you cannot escape (license policy, multi-tenancy need, contractual support obligation), the decision is probably already made and the rest is only comfort.
Choose Vault CE if...
These five criteria have one thing in common: they all concern the environment around the product, not its technical capabilities. Vault CE wins when the exit cost from the HashiCorp ecosystem exceeds the benefit of changing license.
| Criterion | Why Vault |
|---|---|
| Mature ecosystem required | Plugins, integrations, exhaustive documentation |
| Established company | HashiCorp purchasing process already in place |
| Move to Enterprise planned | Natural migration path |
| Advanced cloud integrations | Maintained official plugins |
| Certification training | HashiCorp certification program |
Choose OpenBao if...
The most decisive rows of this table are those about namespaces and, since 2.7.0, the control_group stanza: these are the cases where OpenBao offers for free features that Vault reserves for its Enterprise edition. The other criteria are questions of principle or budget, these ones are clear functional differences.
| Criterion | Why OpenBao |
|---|---|
| OSI license required | Company policy, ethical choice |
| Namespaces without Enterprise | Multi-tenancy included for free |
| Control groups without Enterprise | control_group stanza included since 2.7.0 |
| Vendor independence | Linux Foundation governance |
| Wish to contribute | Open community project |
| Limited budget | No license cost, community support |
Choose Vault Enterprise if...
These criteria are neither comfort nor optimization: they are needs that neither free edition fully covers. Replication is the most frequent, because it conditions resuming activity on a second site; the others stem from compliance obligations or from a hardware security module already in place.
| Criterion | Why Enterprise |
|---|---|
| Multi-region | DR and Performance replication |
| Strict compliance | Step-up MFA, Control Groups, Sentinel |
| Commercial support | SLA, hotline, consulting |
| HSM seal wrap | Hardware protection of the data |
| Advanced Autopilot | Auto-upgrade, redundancy zones |
Which choice for your situation? The quick decision grid
If you were to read only one section of this page, this would be the one. Look for the row that looks most like your current situation. Beware: changing product later is not a short operation, because the only migration path tested by OpenBao starts from an old version of Vault (see below). Make your decision knowingly rather than counting on an easy exit.
| Your situation | Recommendation |
|---|---|
| Small team, simple internal use | Vault CE or OpenBao (equivalent) |
| Multi-team, namespaces needed, limited budget | OpenBao |
| Strict OSI open source policy | OpenBao |
| Existing HashiCorp ecosystem (Terraform, Nomad) | Vault CE |
| Enterprise evolution planned | Vault CE |
| Multi-region, DR, compliance | Vault Enterprise |
| Exotic cloud integrations | Vault CE (check OpenBao compatibility) |
Can you migrate from Vault to OpenBao?
Yes, but only one precise path is tested by the OpenBao project, and it is narrower than people think. OpenBao's official migration guide tests the move from Vault 1.14.1 Community Edition to OpenBao 2.2.0, with Raft storage and Shamir sealing (the unseal key split into shares held by several people). Any other combination is outside that scope: OpenBao declares it untested and unsupported.
From Vault CE to OpenBao: what is tested
The official guide describes an in-place binary replacement, not the restoration of a snapshot onto a new cluster. Newer Vault versions (hence the current 2.1.x) are not covered. A plugin present in Vault and absent from OpenBao leaves its mount unserved: the secrets it carried become inaccessible.
| Starting point | Status according to OpenBao's official guide |
|---|---|
| Vault 1.14.1 CE, Raft + Shamir, to OpenBao 2.2.0 | Tested |
| Newer Vault CE (1.15 and later, including 2.x) | Untested, unsupported |
| Other storage or other sealing mode | Untested, unsupported |
| Vault Enterprise | Untested, unsupported |
Concretely, migrating from a Vault 2.1.x in production is not a supported path. Before any attempt, take a Raft snapshot (a point-in-time copy of the cluster's data) and rehearse the operation on a copy: it is elementary caution, not the official procedure. After the attempt, check the secrets, the policies, the auth methods and the list of served mounts.
From Vault Enterprise to OpenBao
The official guide has not tested this migration. The Enterprise-specific features (replication, Enterprise namespaces, Sentinel, step-up MFA) have no guaranteed equivalent, and the data structure differs. Vendors such as Adfinis offer migration services: it is the reasonable route, rather than improvising.
From OpenBao to Vault
No path is documented or tested in OpenBao's official guide. Do not count on it as an exit door: plan instead to recreate the configuration from a code repository (configuration as code) and to reinject the secrets through the API.
Can Vault and OpenBao coexist?
Some organizations choose to make the two coexist:
- Vault Enterprise for critical environments (production, compliance)
- OpenBao for development and test environments
- Progressive evaluation of OpenBao before a possible full switch
This approach makes it possible to:
- Reduce license costs
- Test OpenBao without risk for production
- Keep flexibility
Keep in mind that different environments do not exercise the same features: what works in development on OpenBao may not exist on Vault Enterprise, and vice versa.
Where are the two projects heading?
The two trajectories below are not predictions but my reading, as the author, of the decision mechanisms already in place. They mostly tell you where to look for information: the Vault roadmap is read in HashiCorp's product announcements, OpenBao's in the public discussions of the repository.
Vault
Steering is that of a commercial product: new things arrive first in the paid edition, then sometimes come down to the Community edition. My opinion, which is not a measurement: the CE/Enterprise gap is more likely to widen than to narrow.
- Continuous development by HashiCorp/IBM
- Roadmap defined by HashiCorp
- New features in Enterprise first
- Strengthened cloud integrations
OpenBao
With no paid edition to protect, the project has no reason to reserve a feature: the arrival of namespaces (2.3.1) then of the control_group stanza (2.7.0) illustrates it. The downside is that proprietary integrations, notably on the cloud providers' side, depend on volunteer contributors.
- Linux Foundation / OpenSSF governance
- Community roadmap (GitHub Discussions)
- Focus on "core" features available to everyone
- Namespaces,
control_group, improved auto-unseal, robustness
Key points
- Functionally close: both solutions cover the same fundamental use cases, on a shared code base (Vault 1.14)
- License: Vault BSL (internal use OK, free but not open source), OpenBao MPL 2.0 (pure open source)
- Functional gaps: namespaces (OpenBao since 2.3.1) and the
control_groupstanza (OpenBao 2.7.0) are reserved for Vault Enterprise; Login MFA is available on both sides - Maturity: Vault 10+ years, OpenBao nearly 3 years but a solid base
- Migration: only Vault 1.14.1 CE to OpenBao 2.2.0 (Raft + Shamir) is tested; everything else, Enterprise and Vault 2.x included, is unsupported
- Decision: technical AND political/legal depending on your context, made without counting on an easy exit
Knowledge check
Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Vault CE vs Enterprise: which edition to choose?
A new full quiz with random questions
Work again only on the questions you missed