OpenBao vs HashiCorp Vault: the Open-Source Fork, Compared (2026)

Same vault, two licences

OpenBao and HashiCorp Vault are, at the level of secrets engines and API calls, the same software. OpenBao is a fork of Vault, created after HashiCorp moved Vault to the Business Source Licence in 2023. It speaks the same API, exposes the same command surface, and carries the same secrets engines and auth methods it inherited at the fork. If you have run Vault, OpenBao will feel identical day to day.

The reason to choose between them is almost entirely about licence and governance, not features. Vault is BUSL-1.1 and, since the acquisition completed in early 2025, an IBM product. OpenBao is MPL-2.0 and governed under the Linux Foundation. One is source-available under a single vendor; the other is OSI open source under neutral governance. That is the decision in one sentence.

The licence question, in plain terms

BUSL-1.1 is not an open-source licence in the OSI sense. It lets you read and use the source for most purposes, but it restricts using Vault to build a competing hosted service, and it is not free in the way MPL-2.0 is. For a great many teams that distinction is academic: they run Vault Community Edition in production and never hit the restriction. For others, especially those whose own compliance or procurement rules require OSI-approved licensing, or who are wary of single-vendor control after the relicensing precedent, it is the whole story.

OpenBao exists precisely because that precedent unsettled enough of the ecosystem to fund an alternative. MPL-2.0 carries no usage restriction and no competing-product clause, and the Linux Foundation governance means no single company can repeat the relicensing move unilaterally. You are trading a vendor's roadmap for a community's.

Feature comparison

Where the capabilities diverge

Day-to-day capabilities are close to identical, because OpenBao started as Vault and tracks the open feature set. The same dynamic secrets, leasing, KV engines, database engines, and common auth methods are present on both sides. For the large majority of self-hosted secrets workloads, you would struggle to tell them apart in normal operation.

The divergence is at the top of the range. HashiCorp reserves its most advanced capabilities, including performance and disaster-recovery replication, hardware security module integrations, and namespaces for multi-tenancy, for the commercial Vault Enterprise tier. OpenBao's community has been building toward parity on several of these, but you should not assume an exact match. If your architecture depends on a specific Enterprise feature, verify OpenBao's current support for it directly rather than treating the fork as feature-complete.

Operations, support, and managed options

Both run as self-hosted services. The practical difference is what sits around them. Vault has the largest ecosystem in the category and first-party commercial support from HashiCorp and IBM. HashiCorp also offers HCP managed options, though the hosted roadmap has been in flux post-acquisition, so confirm current availability before you assume a managed path.

OpenBao has no first-party managed SaaS. You operate it yourself, and support comes from the community or from third-party vendors offering OpenBao services. The ecosystem is younger but benefits from API compatibility: much of the tooling built for Vault, including Terraform providers and Kubernetes integrations, works against OpenBao with little or no change.

Migration between the two

Because OpenBao keeps Vault's API and storage concepts, moving between them is more tractable than a typical platform migration. Existing clients and integrations generally point at the new endpoint and keep working. That said, this is a production secrets system holding live credentials, so treat any migration as a careful, tested operation: confirm your exact secrets engines, auth methods, and high-availability configuration behave identically, and rehearse the cutover before you run it for real.

Which to choose

Choose OpenBao if an OSI-approved licence is a requirement, if vendor-neutral governance reduces a risk you actually care about, or if you want Vault's open feature set without HashiCorp's Enterprise pricing and you are comfortable operating it and sourcing support from the community or third parties.

Choose HashiCorp Vault if you depend on Enterprise-tier features such as advanced replication or HSM integration, if you want first-party commercial support and the largest ecosystem, or if BUSL is simply not a constraint for how you use it. For many existing Vault shops, staying put is the rational default.

If you are choosing a secrets backend for AI agents specifically, the licence answer points to OpenBao, but the more important point is architectural: put whichever vault you choose behind a credential proxy so your agents never hold the secret. We cover that pattern, and the open-source proxies that implement it, in the credential vaults for AI agents radar shortlist. For the broader field, including the cloud secrets managers, see HashiCorp Vault alternatives.

Is HashiCorp Vault still open source?

No. HashiCorp relicensed Vault under the Business Source Licence (BUSL-1.1) in August 2023. BUSL makes the source readable and usable for most purposes, but it is not an OSI-approved open-source licence, and it restricts using Vault to build a competing hosted offering. HashiCorp was acquired by IBM, with the deal completing in early 2025. If you need an OSI-approved licence specifically, OpenBao is the fork created in response to that change.

Is OpenBao a drop-in replacement for Vault?

For most deployments, close to it. OpenBao forked from Vault and keeps the same API and command surface, so existing Vault clients, Terraform providers, and integrations generally work against OpenBao with minimal change. The gap is at the high end: HashiCorp's commercial Enterprise features such as advanced replication, HSM integrations, and namespaces are not all at parity in OpenBao. Test your specific secrets engines, auth methods, and HA configuration before committing, rather than assuming exact equivalence.

Who maintains OpenBao?

OpenBao is a community project governed under the Linux Foundation, with contributors from multiple organisations, including IBM engineers. That vendor-neutral governance is the structural difference from Vault, which is controlled by a single company. The trade-off is that there is no first-party commercial vendor to call for support; that comes from the community and from third-party companies offering OpenBao services.

Should I migrate from Vault to OpenBao?

Migrate if the BUSL licence is a genuine constraint for you, if vendor-neutral governance matters for your risk posture, or if you want to avoid HashiCorp's Enterprise pricing for features you can run on the open feature set. Stay on Vault if you depend on its Enterprise-tier capabilities, want first-party support, or are already invested in HCP. Because the API is compatible, the migration is more tractable than a typical platform switch, but it is still a production secrets system, so plan and test it carefully.

Which is better for AI agents?

Neither, on its own, solves the agent credential problem. Both are vaults that hand the secret to whatever authenticates, which is exactly the exposure you want to avoid with an LLM agent. The pattern that works is a vault behind a credential proxy that injects secrets outside the agent's reach. If you need an OSI-licensed store for that role, OpenBao is the better fit; pair it with a proxy such as Infisical Agent Vault or OneCLI. Our radar shortlist covers the proxy layer in detail.