Here is the most important thing to understand about HashiCorp Vault in 2026: there are now two Vault-shaped secrets managers, they share the same wire protocol and API surface, and they have different licenses, different governance, and a widening feature gap. If you are standing up secrets management today, the question is no longer only "should I use Vault?" but increasingly "should I use Vault, or should I use OpenBao?" That question did not exist before August 2023, and it is the entire reason this article exists.
For most of its life Vault was the boring, trusted, permissively licensed secrets manager that enterprises reached for. It shipped under Mozilla Public License 2.0, an OSI-approved weak copyleft license that let anyone run it, embed it, and offer it as a service without a commercial agreement. Then the same license change that hit Terraform — the move from MPL 2.0 to the Business Source License 1.1 — landed on Vault, and a community fork called OpenBao emerged from the last open version. This is the story of that fork, what it means for you, and how to make the call.
This review covers what Vault is, the MPL years, the August 2023 relicensing, the cloud economics that caused it, the OpenBao fork that IBM engineers seeded, how the two projects have diverged, the near-drop-in migration, the Nvidia and GitLab adoptions that gave the fork credibility, real self-hosting and enterprise costs, where your secrets actually live, and an honest verdict for an operator who cares about data sovereignty.
1. What Vault Actually Is
Vault is a secrets management and encryption platform. "Secrets" here means the sensitive material your infrastructure needs to function: API keys, database credentials, SSH keys, TLS certificates, cloud access tokens, and encryption keys themselves. Vault's job is to store these securely, hand them out on demand, rotate them automatically, and revoke them when they are no longer needed. It is the lockbox that everything else in your stack calls when it needs a password it should never have hardcoded.
Vault is not a single feature but a set of engines. The KV secrets engine stores static key-value pairs. The dynamic secrets engines generate short-lived credentials on demand — for example, a fresh PostgreSQL user with a one-hour TTL that is created when an app asks and destroyed when it expires. The Transit engine provides encryption as a service, letting an application encrypt data without ever holding the key. The PKI engine issues and rotates X.509 certificates, including short-lived certs for mutual TLS. Authentication methods — AppRole, Kubernetes, OIDC, LDAP, GitHub — map external identities onto Vault policies. That breadth is why Vault became the default secrets layer for cloud-native infrastructure rather than a niche password vault.
2. The MPL Years (2015–2023)
For most of its existence Vault shipped under Mozilla Public License 2.0. MPL 2.0 is an OSI-approved weak copyleft: you can use, modify, and distribute it commercially, and you can even offer it as a managed service, as long as you share the source of the MPL-licensed files you modify. It is file-level copyleft, not project-level, which made it friendly to vendors and enterprises alike. Under MPL, Vault became the de facto standard for secrets management, bundled into countless CI/CD pipelines, Kubernetes clusters, and compliance programs.
This permissive period is the quiet setup to the conflict. MPL let Vault become ubiquitous; ubiquity made it the default secrets layer; being the default made it the thing cloud providers and platform teams resold and embedded everywhere; and once it was foundational, HashiCorp — the company employing the core maintainers — watched the broader value of "Vault everywhere" accrue to the ecosystem rather than to the vendor's bottom line. Nothing about MPL changed; the company's appetite for that arrangement did, and it changed on a single day for the entire product portfolio.
3. August 10, 2023: The Relicensing
On August 10, 2023, HashiCorp announced that Vault, Terraform, Consul, Nomad, and Vault would move from MPL 2.0 to the Business Source License 1.1. For Vault, the specific change took effect at version 1.15.0: every release from 1.15.0 onward is BSL, while 1.14.0 and earlier remain MPL 2.0 forever. That version boundary — Vault 1.14.0 — became the precise branch point for everything that followed, because it is the last open release anyone could legally fork.
What does the BSL actually forbid? BSL 1.1 permits use, modification, and distribution, but adds a single restrictive clause: you may not offer the software to third parties as a hosted or embedded competing service without a commercial license from HashiCorp. For an ordinary enterprise using Vault to manage its own secrets, internal use is fully allowed. The restriction bites only cloud providers and anyone building a competing managed secrets offering. Each BSL release is also time-bounded: it converts to MPL 2.0 four years after its publication date, so the license tightening is a delay on openness, not a permanent revocation for the codebase as a whole.
4. Why HashiCorp Did It (The Value-Capture Problem)
The motivation was the same as Elastic, MongoDB, Redis, and CockroachDB before and after it: the value-capture problem. When a hyperscaler or a platform competitor offers "Vault, managed, on our cloud" or embeds it as a competitive service, they capture recurring revenue while the open-source vendor carries the engineering cost of the core. HashiCorp had been trying to monetize through Vault Enterprise — HSM auto-unseal, namespaces, replication, Sentinel policy enforcement — but the free core remained what everyone actually deployed. By tightening the core license, the company aimed to force competitors to either pay for a license or stop reselling the unmodified software.
The strategy is defensible from a business standpoint and unsettling from a community standpoint, and both are true. A company that pays the core engineers deserves a path to revenue. But a community that built its security posture around an MPL promise reasonably feels the rug moved. This tension is the recurring plot of the 2021–2024 license wave, and Vault was one of its highest-stakes installments because secrets management is mission-critical infrastructure: you cannot casually swap your lockbox.
5. OpenBao: The Fork From the Last Open Version
The response was immediate, though quieter than the OpenTofu saga. In December 2023, IBM engineers Nathan Phelps and Joe Pearson forked the last MPL-licensed Vault — specifically Vault 1.14.0 — and brought it under the Linux Foundation as OpenBao. The fork kept MPL 2.0, the OSI-approved license HashiCorp had just abandoned. The name is a play on "bao," a Chinese word for a small treasure or packet, fitting for a secrets manager. OpenBao reached its first production-ready General Availability with version 2.0.0 in July 2024, and the project joined LF Edge in April 2024 before graduating to the OpenSSF Sandbox in June 2025.
The fork's design goal was explicit compatibility: the binary is
bao rather than vault, but the API surface and CLI remain compatible with Vault 1.14-era clients, and the on-disk formats — Shamir seal shares, integrated-storage Raft snapshots — are interoperable within the fork-compatible feature set. In practice, for most engines, bao works as a drop-in replacement for vault. That compatibility is the entire value proposition: you get the secrets manager you already know, under a license you can trust, governed by a neutral foundation rather than a venture-backed-and-then-acquired company.
6. The OpenTofu Contrast
It is impossible to discuss OpenBao without comparing it to its louder sibling, OpenTofu, the fork of Terraform. Both were born from the same August 2023 BSL switch, but their trajectories diverged sharply. OpenTofu launched with corporate firepower: more than 140 companies and 600 individuals pledged support in its first month, and it now lists 163 companies, 12 open-source projects, and 791 individuals among its backers. OpenBao had no such army. It emerged as a more grassroots, organic effort, primarily initiated by IBM engineers, with IBM maintaining a curious arm's-length relationship — hosting a forwarding link but never officially endorsing it in the way several vendors endorsed OpenTofu.
That asymmetry is the central narrative of the Vault fork. OpenTofu proved a fork can win with corporate sponsorship. OpenBao is testing whether a fork can survive and grow on steady community development plus a couple of strategic enterprise allies. The slower pace is both its challenge and its strength: it lacks the marketing muscle of OpenTofu, but it demonstrates that meaningful open alternatives can emerge from genuine community need rather than corporate strategy. For an operator choosing between them, the lesson is that the Terraform fork is further along, while the Vault fork is earlier but real.
7. Governance and the Linux Foundation Umbrella
OpenBao's governance is what gives it durability. By placing the project under the Linux Foundation — first LF Edge, then the OpenSSF Sandbox — the fork removed itself from any single company's control. It built a Technical Steering Committee, published governing documents, and established a transparent release and security process. As an OpenSSF Sandbox project, OpenBao gains a separately maintained CVE disclosure mailing list, community security audits, transparency requirements, and integrations with supply-chain security tooling such as Sigstore. Those are exactly the trust signals an enterprise evaluates before adopting a secrets manager, and they are harder for a single vendor to quietly walk back than a corporate promise.
HashiCorp's own governance, by contrast, is now IBM governance. IBM completed its acquisition of HashiCorp on February 27, 2025, after announcing the $6.5 billion deal in April 2024. The Vault LICENSE file now names IBM as the licensor. One IBM engineer remains listed as a core OpenBao maintainer, a reminder that the fork and the original are not fully separate worlds. But the strategic direction of Vault now answers to IBM's revenue mandates, while OpenBao answers to its foundation steering committee.
8. Technical Architecture: Secrets Engines
To evaluate the fork you have to understand what you are actually running. Vault and OpenBao share the engine model. The KV v2 engine is the workhorse for static secrets, with versioning, check-and-set, and soft delete. The database secrets engine dynamically generates credentials for PostgreSQL, MySQL, MongoDB, and dozens of others, wiring them to Vault-managed TTLs and automatic revocation. The AWS, GCP, and Azure secrets engines mint short-lived cloud credentials instead of long-lived static keys. The SSH engine signs client keys for certificate-based auth. All of these are present in OpenBao 2.x because they were part of the forked Vault 1.14 code.
The practical implication is that most application integrations — a Spring Boot app pulling database credentials, a Kubernetes pod mounting a secret via the CSI driver, a CI pipeline requesting a temporary token — work identically against
bao and vault within the shared feature set. The migration story is therefore dramatically better than a typical rewrite: it is largely a binary swap plus a re-pointing of endpoints, not a re-architecture of your secret-consumption patterns.
9. Transit and PKI: Encryption as a Service
Two engines deserve special attention because they are where Vault earns its keep. The Transit engine lets an application encrypt and decrypt data by calling Vault, without the app ever holding the master key. This is "encryption as a service," and it means a compromise of the application server yields ciphertext, not keys. Transit supports key rotation, key versioning, convergent encryption for deterministic lookups, and envelope encryption for large payloads. OpenBao inherited all of this from Vault 1.14 and has since extended it — version 2.5 added an
associated_data parameter, and 2.7 introduced external keys for Transit, including ML-DSA post-quantum signature support.
The PKI engine issues X.509 certificates, including short-lived certificates for mutual TLS, which is the backbone of zero-trust networking. OpenBao 2.7 also added external keys for PKI, letting operators integrate with external certificate authorities. For teams building mTLS service meshes or internal certificate authorities, these engines are the reason Vault is worth the operational weight, and the fact that OpenBao carries them under MPL is the fork's sharpest argument.
10. Authentication Methods
Vault and OpenBao authenticate workloads through methods that map external identities to internal policies. Kubernetes auth lets pods authenticate using a service account token signed by the cluster. AppRole provides a role-id and secret-id pair for machines. OIDC ties human logins to an identity provider. LDAP and GitHub auth cover traditional and developer workflows. OpenBao 2.5 added an OIDC Client Credentials flow, keeping pace with modern machine-to-machine auth patterns. The shared auth surface means your existing login flows — the part of a secrets deployment that is hardest to rewire — carry over to the fork with minimal change.
11. Storage Backends and High Availability
Vault and OpenBao both default to Integrated Storage, a Raft-based consensus backend that lets a cluster of nodes agree on secret state without an external database. This is the recommended HA path: you run three or five nodes, they elect a leader, and the others serve standbys. OpenBao 2.5 added horizontal read scalability, letting standby nodes serve reads, which improves read throughput under load. Alternative backends include Consul, PostgreSQL, and cloud object storage, though Integrated Storage is the path most teams take. For disaster recovery you configure auto-unseal with a cloud KMS so you are not rebuilding Shamir key shares at 3 a.m. after a total cluster loss.
12. The Divergence: What OpenBao Does Not Have
Honesty matters here. OpenBao is a fork of Vault 1.14, not of Vault Enterprise. It does not implement Vault Enterprise replication — the multi-datacenter, active-active replication that global enterprises rely on — nor does it implement Sentinel, HashiCorp's policy-as-code framework. Those are paid, proprietary features, and OpenBao has deliberately avoided them. It also lacks some of the newest Vault 2.x breaking-change features and IBM-specific lifecycle tooling. For a team whose requirements include cross-region replication or Sentinel policies, Vault Enterprise remains the only option, and that is a real limitation of the fork, not a footnote.
Conversely, OpenBao has added its own capabilities that Vault 1.14 did not have: namespaces (re-added in 2.3.1, API-compatible with Vault Enterprise), declarative self-initialization, KMS plugins for auto-unseal across AWS, Azure, GCP, AliCloud, and OCI, a PebbleDB backend, and control groups. The two projects are no longer identical; they are convergent cousins that started from the same 1.14 root and have grown in different directions.
13. The Migration Story
Migrating from Vault Community to OpenBao is, for most teams, a binary swap. Because OpenBao preserves the Vault 1.14 API and on-disk formats within the shared feature set, the typical path is: stand up an OpenBao cluster, snapshot your Vault Integrated Storage Raft data, restore it into OpenBao, repoint your clients from
vault to bao, and rotate. The catch is version: migration is simplest from pre-1.15 Vault, because later Vault releases introduced storage format changes and Enterprise-only features that may not carry over. If you are already on Vault 1.15 or later, you cannot simply lift the data forward; you are effectively re-platforming onto the 1.14-compatible fork and re-importing secrets.
This is the subtle trap of the BSL timeline. The longer you stay on BSL Vault, the further you drift from the fork-compatible root, and the harder the eventual move becomes. The four-year conversion clock helps only if you are willing to wait for a specific release to age into MPL — but by then the surrounding ecosystem has moved on. The strategic recommendation for a sovereignty-minded operator is to evaluate the fork before you are locked into Enterprise-only features.
14. Nvidia Adopts OpenBao
In May 2026 Nvidia was added to the public list of OpenBao adopters, a signal of growing enterprise confidence in the fork. Nvidia uses OpenBao to inject secrets into Kubernetes pods managed by its Nvidia Cloud Functions (NVCF), an auto-scaling, serverless GPU control plane that Nvidia open-sourced under Apache 2.0 in April of that year. For a project that began as a grassroots IBM-led effort, landing a company of Nvidia's scale as a documented adopter is a credibility inflection point. It tells platform teams that OpenBao is not a hobby fork but production infrastructure used by compute-heavy, security-sensitive workloads.
15. GitLab and the Enterprise Validation
GitLab became a crucial ally, joining the OpenBao project officially in July 2024 and achieving voting status in its governance by October 2024. GitLab architected a native OpenBao integration for CI/CD pipelines, providing practical enterprise validation that the fork could serve as a real Vault replacement, and showcased the work at FOSDEM 2025. For an open-source project, one strategic enterprise partner with deep CI/CD reach can matter more than a hundred stars. GitLab's involvement means that the "how do I use this in my pipeline?" question now has a first-class answer, lowering the adoption barrier for teams already living in GitLab.
16. The Digital Sovereignty Angle
A recurring theme in 2025 and 2026 is digital sovereignty, particularly in the European Union. Consultancies report that roughly 75% of their strong OpenBao leads are outside the United States, driven by concerns about vendor lock-in and proprietary control planes in regulated environments. The OpenSSF backing and foundation governance make OpenBao attractive where clients are reassessing whether their secrets should live behind a single US-acquired vendor's license. This is not a technical argument so much as a geopolitical one, but for regulated industries it is often decisive. The fork's stronger angle, as one industry executive put it, is open governance, portability, and control of secrets in sovereign environments.
17. Where Your Secrets Actually Live
Data sovereignty for a secrets manager is a sharper question than for a cache or a database, because the secret is the crown jewel. With Vault or OpenBao self-hosted, your secrets live in your own Raft storage, encrypted with your own seal, unsealed by your own KMS or Shamir shares. No third party holds your keys. With HashiCorp Vault Enterprise or a managed offering, the secret data still lives in your infrastructure if you self-host, but the license and roadmap answer to IBM. With OpenBao, the license and roadmap answer to a foundation you can participate in.
The honest caveat is operational: secrets management is only as safe as your unseal and recovery process. If you lose your Shamir key shares and have no auto-unseal KMS, your secrets are unrecoverable. If you misconfigure a policy, you can expose everything. The fork does not change this responsibility; it changes who controls the software that enforces it. For a sovereignty-minded operator, that distinction is the whole point.
18. Real Self-Hosting Costs
Self-hosting either Vault or OpenBao is cheap on compute but expensive on attention. A small three-node cluster runs comfortably on 2–4 vCPU and 4–8 GB RAM per node, which on a typical cloud works out to roughly $60–$150 per month for the nodes, plus the usual egress and storage costs. The real cost is the operational discipline: you must back up Raft snapshots, configure auto-unseal, manage TLS, rotate keys, and rehearse disaster recovery. Many teams underestimate this and treat Vault as "set and forget," which it is not.
HashiCorp Vault Enterprise, by contrast, is priced per node or per workload under a commercial agreement, and the published list prices run into the thousands of dollars per node per year once you include HSM auto-unseal, namespaces, and replication. For a team that genuinely needs those features, the cost is justified; for a team that does not, the free OpenBao path is materially cheaper and license-clean. The fork's economic argument is not "free is better" but "you should not pay for features you do not use, and you should not need a commercial agreement to run an open secret store."
19. Managed Alternatives and the Cloud Native Path
It is worth noting the path of least resistance for many teams: cloud-native secrets managers. AWS Secrets Manager, Google Secret Manager, and Azure Key Vault are fully managed, require no cluster to operate, and integrate tightly with their respective clouds. The trade-off is lock-in and, often, per-secret per-month pricing that scales with usage. Pattern B from practitioners is "use the cloud-native manager when you are all-in on one cloud; use Vault or OpenBao when you are multi-cloud, on-prem, or need features the cloud managers lack," such as dynamic database credentials or Transit encryption as a service. OpenBao sits squarely in that second bucket and is the license-clean choice within it.
20. The Support and EoL Policy
A less-discussed but important detail: OpenBao's published support policy backports nothing. Fixes go into the next release only, so an older line such as 2.5.x is effectively end-of-life and carries every unpatched issue from 2.5.4 onward. This is a different model from vendors who maintain long-lived support branches. For an operator, it means you must stay reasonably current on OpenBao releases to receive security fixes — a discipline that is fine for teams with good update hygiene but a risk for those who prefer to freeze versions. HashiCorp, by contrast, maintains versioned support for Vault, including its IBM Support Cycle-2 lifecycle for Vault 2.x. The fork trades long-term backport support for license freedom.
21. Community Size and Momentum
OpenBao reached 100+ contributors and a few thousand GitHub stars by 2025, and while it is smaller than OpenTofu's movement, it is growing. The project shipped eight releases including two major versions in its first stretch, and the 2.6 and 2.7 lines added substantive features. Nvidia's adoption and GitLab's integration are the kind of enterprise validation that converts a fork from "interesting" to "safe to bet on." The honest read is that OpenBao is earlier in its journey than OpenTofu, but it has cleared the threshold of "real alternative" and now sits in the "credible, growing" category.
22. Security Posture and CVE Handling
Because OpenBao lives under the OpenSSF Sandbox, it gains a maintained CVE disclosure process, community audits, and supply-chain tooling integration. Recent OpenBao releases closed multiple advisories — for example, the 2.5.4 and 2.5.5 patches addressed eight further advisories, and the line moved through 2.6.0, 2.6.1, and 2.6.2 by August 2026, with 2.7.0 following in September 2026 adding post-quantum ML-DSA signatures. Security responsiveness is a leading indicator of project health, and OpenBao's cadence suggests a maintained, attentive project rather than a stale snapshot.
23. The "Is It Really Open?" Question
A fair criticism: is OpenBao really the open version, or just a frozen copy of old Vault? The answer is nuanced. OpenBao began as a fork of Vault 1.14, but it has since diverged with its own features — namespaces, horizontal read scaling, declarative init, KMS plugins, PebbleDB, control groups, post-quantum signatures. It is not a static mirror; it is an actively developed project under a foundation. That said, it does not have the engineering headcount of IBM-backed Vault, and it will likely trail on cutting-edge enterprise features indefinitely. The right framing is: OpenBao is the open, foundation-governed continuation of the Vault that existed before August 2023, and it is evolving on its own terms.
24. Honest Limitations
Let me be direct about where the fork is weak. First, it lacks Vault Enterprise replication and Sentinel — if you need those, the fork is not a drop-in. Second, its support model backports nothing, so you must stay current. Third, it is younger and smaller than OpenTofu, so ecosystem tooling and third-party docs are thinner. Fourth, the migration is clean only from pre-1.15 Vault; the longer you wait on BSL Vault, the harder the move. Fifth, and most importantly, OpenBao's future depends on sustained community and foundation commitment — it is not guaranteed. None of these are fatal, but they are real, and a sovereignty-minded operator should weigh them against the license freedom the fork provides.
25. When to Choose Vault (BSL) Anyway
There are legitimate reasons to stay on HashiCorp Vault. If you need multi-datacenter replication, Sentinel policy-as-code, HSM auto-unseal, or vendor-backed support with an SLA, Vault Enterprise is the answer, and IBM's acquisition means it is unlikely to disappear. If you are already deep in the HashiCorp stack — Consul, Nomad, Terraform Cloud — the integrated experience may outweigh the license concern. And if your usage is purely internal, the BSL's restriction on offering competing services does not touch you. The fork is not a moral mandate; it is an option, and for some teams the paid path is rationally correct.
26. When to Choose OpenBao
Choose OpenBao when you want the Vault experience without the BSL or the IBM dependency, when you are building new infrastructure and can start from the 1.14-compatible root, when digital sovereignty or open governance is a procurement requirement, or when you want to avoid a commercial agreement for a core secret store. It is also the right call if you are already on pre-1.15 Vault and want to escape the BSL clock before drifting further. For most new self-hosted secrets deployments by teams that do not need Enterprise replication, OpenBao is the recommendation this article lands on — license-clean, foundation-governed, and compatible enough to be a true alternative.
27. Getting Started With OpenBao
Standing up OpenBao is similar to standing up Vault. You download the
bao binary or run the container, initialize a cluster with bao operator init to generate Shamir shares and a root token, unseal it, and enable engines such as KV v2 and a database secrets engine. Point your applications at the bao address instead of vault, and your existing Vault SDKs and CLIs work against the compatible API. For production, run three or five nodes with Integrated Storage, configure auto-unseal via a cloud KMS, and rehearse a Raft snapshot restore before you need it. The learning curve is the Vault learning curve, which is well-documented; the only new step is recognizing that bao is your binary.
28. Reading the License File, Not the Blog Post
The single most important habit this entire license-wave saga teaches is to verify the current license against the project's LICENSE file, not against a blog post written before 2023. Vault 1.15.0 and later are BSL; 1.14.0 and earlier are MPL. OpenBao is MPL 2.0. Specific BSL releases convert to MPL four years after publication. These facts are checkable in the repositories, and they change the cost and risk calculus of every deployment. Treat the license as a feature that changed everything — because for secrets management, it did.
29. The Broader Pattern
Vault is one chapter in a larger story. Redis became source-available and spawned Valkey. Terraform became BSL and spawned OpenTofu. Elasticsearch became SSPL and spawned OpenSearch. MongoDB became SSPL and pushed teams toward FerretDB. CockroachDB became BSL and then moved to private source. Each case tests a different outcome of the same corporate decision: tighten the license, and either the community forks you, an alternative emerges, or you simply close. Vault's outcome — a foundation-governed fork that is gaining enterprise adoption — is among the more hopeful, and OpenBao's survival is a data point that forks can work even without a corporate army.
30. The Feature Matrix: Vault vs OpenBao vs Cloud Native
To make the choice concrete, it helps to line the options up. HashiCorp Vault (BSL, latest) offers the full engine set, Enterprise replication, Sentinel, HSM auto-unseal, and IBM-backed support, at commercial cost. OpenBao (MPL 2.0) offers the community engine set, namespaces, horizontal read scaling, KMS auto-unseal plugins, and foundation governance, free, but lacks Enterprise replication and Sentinel and backports no fixes. Cloud-native managers (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) offer zero operational burden and tight cloud integration, but per-secret pricing, lock-in, and no dynamic database credentials or Transit encryption-as-a-service. The matrix is not about which is "best" but which matches your constraints: if you need global replication and SLAs, Vault Enterprise; if you need open governance and no commercial agreement, OpenBao; if you are single-cloud and want zero ops, the cloud manager. Most self-hosted, multi-cloud, sovereignty-minded teams land on OpenBao.
31. Operational Hardening: What Breaks in Production
The part of a Vault or OpenBao deployment that actually fails is rarely the software — it is the operational discipline around it. The classic outages are: an unseal ceremony gone wrong after a total cluster loss because nobody practiced Shamir recovery; a TLS certificate expiry that locks out every client because the PKI engine was not automated; a policy typo that either exposes a secret to the wrong workload or denies a critical service; and a Raft snapshot that was never tested for restore, discovered broken only during a real recovery. The fork does not change any of this. The mitigation is rehearsal: regularly practice unseal and restore from backup in a staging cluster, automate certificate renewal through the PKI engine with short TTLs, and treat policy changes as code with review. The license you choose affects who controls the software; the runbook you write determines whether your secrets are available at 3 a.m.
32. The Root Token Discipline
One operational truth deserves emphasis because it applies identically to Vault and OpenBao: the root token is radioactive. The root token can do anything — read every secret, rewrite every policy, delete the cluster — and best practice is to generate it only during initialization, use it to create scoped admin policies, and then revoke it, never to be used in daily operations. Daily access flows through least-privilege policies bound to auth methods, not the root. This discipline is the real security boundary of any secrets manager, and the license you choose does nothing to enforce it. Whether you run IBM-backed Vault or foundation-governed OpenBao, the difference between a secure deployment and a breach is almost always whether someone treated the root token like a password instead of a one-time ceremony key. The fork changes who controls the software; this habit determines whether the software protects you.
33. Bottom Line
HashiCorp Vault did not die in 2023; it bifurcated. The company moved it to the Business Source License, IBM acquired HashiCorp, and IBM Vault Enterprise is now the paid, feature-rich, support-backed path. But the last open version lives on as OpenBao — MPL 2.0, Linux Foundation governed, Nvidia-adopted, GitLab-integrated, and actively developed. For a new deployment that does not need Enterprise replication or Sentinel, OpenBao is the license-clean choice and a genuine drop-in for most engines. For a team that needs global replication and vendor SLAs, Vault Enterprise remains correct. The takeaway is that the BSL switch did not remove your options; it clarified them. Verify the license of whatever you deploy against the LICENSE file, start new work on OpenBao if sovereignty matters to you, and you have made the architectural choice this entire article argues for.
Related:
Comments (0)
No comments yet. Be the first to comment!