OpenBao vs HashiCorp Vault
OpenBao and HashiCorp Vault compared for 2026: MPL-2.0 vs Business Source License, namespaces, HSM and auto-unseal, storage backends, replication, plugins, post-quantum crypto, support lifecycle and the real cost of migrating from Vault, with a clear pick per situation.
Quick Answer
HashiCorp Vault is IBM's secrets manager. Since version 1.15.0 it has shipped under the Business Source License 1.1, which allows internal production use but not offering Vault as a competing hosted or embedded paid product, and each version converts to MPL 2.0 four years after release. Vault Community Edition is free to self-host. Namespaces, HSM support, Sentinel policies and cross-cluster replication require Vault Enterprise or HCP Vault Dedicated, HashiCorp's hosted Vault Enterprise on AWS or Azure. The current release is Vault 2.2.1 (22 October 2026). OpenBao is the open-source fork of Vault's last MPL-2.0 code, run under the Linux Foundation's OpenSSF. Its CLI is bao and its API stays compatible with Vault's, and it ships features that Vault reserves for Enterprise: namespaces (now sealable per tenant), a PKCS#11 HSM auto-unseal, and control groups. OpenBao 2.7 (September 2026) added external keys for PKI and Transit, ML-DSA post-quantum signatures, PostgreSQL read scaling and a PebbleDB backend. The current release is v2.7.2 (26 October 2026). Pick OpenBao if you want a truly open-source Vault with multi-tenancy and HSM support at no licence cost. Pick Vault if you need vendor support, HCP's managed service, Sentinel, cross-cluster replication or the newest Vault 2.x features.
Last updated November 10, 2026. Covers OpenBao v2.7.2 (26 Oct 2026) and HashiCorp Vault 2.2.1 (22 Oct 2026), with licence terms from each LICENSE file and features from openbao.org and developer.hashicorp.com, read in November 2026.
| Feature | OpenBao | HashiCorp Vault |
|---|---|---|
| License | MPL-2.0 (OSI-approved open source) | Business Source License 1.1 for 1.15.0+ (converts to MPL 2.0 four years after each version); licensor IBM |
| Governance / Owner | Linux Foundation OpenSSF project with a community charter and technical steering committee | Single vendor (IBM / HashiCorp) |
| Editions & Pricing | Single free edition; no paid tier | Community Edition (free), Enterprise and HCP Vault Dedicated (commercial) |
| CLI & API | bao CLI; HTTP API compatible with Vault's (X-Vault-* headers kept) | vault CLI and HTTP API |
| Storage Backends | Integrated Storage (Raft), PostgreSQL, PebbleDB (non-HA, v2.7), in-memory | Integrated Storage (Raft) recommended; external backends such as Consul |
| HA & Read Scaling | Active/standby HA; read scaling with Raft non-voters and PostgreSQL standbys (v2.7); consistency-control headers | Active/standby HA with Integrated Storage; cross-cluster scale-out via Enterprise replication |
| Cross-Cluster Replication | Not part of the docs read; scale-out is within one cluster | Performance and disaster-recovery replication (Enterprise / HCP Vault Dedicated) |
| Namespaces (Multi-Tenancy) | Included; sealable namespaces with separate key material (v2.6+) | Enterprise / HCP Vault Dedicated only |
| Auto-Unseal & HSM | Shamir by default; PKCS#11, KMIP, Transit and static-key seals; cloud KMS seals as external KMS plugins | Shamir, AWS KMS, Azure Key Vault, GCP Cloud KMS and Transit seals; PKCS#11 HSM seal and seal wrapping in Enterprise |
| Policy Extras | Path-based ACL policies, control groups (v2.7), workflows (v2.6), CEL support | ACL policies; Sentinel RGPs and EGPs in Enterprise |
| Built-in Secrets Engines | KV, Databases, PKI, Transit, SSH, Kubernetes, LDAP, RabbitMQ, TOTP, Identity, Cubbyhole | KV, Databases, PKI, Transit, SSH, AWS, Azure, Google Cloud, KMIP, key management and more (some Enterprise-only) |
| Built-in Auth Methods | AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens, userpass, login MFA | AppRole, JWT/OIDC, Kubernetes, LDAP, cloud IAM methods (AWS, Azure, GCP) and more |
| Plugins | External plugins incl. OCI-distributed plugins pinned by digest; openbao-plugins repo for cloud engines and seals | Built-in plugins plus external plugin catalogue |
| PKI & Crypto Highlights | ML-DSA in PKI and Transit, pure post-quantum TLS, external KMS/HSM keys for PKI and Transit | PKI, Transit encryption as a service, managed keys; Enterprise adds KMIP and key management |
| Web UI | Built-in web UI, off by default (enable with ui = true) | Built-in web UI with a guided dashboard in 2.x |
| Install & Packages | Packages for Debian, Ubuntu, RHEL, Fedora, Amazon Linux; EPEL and Arch repos; Alpine and distroless container images | HashiCorp apt/yum repos and binaries; separate Enterprise install |
| Managed Offering | No first-party managed service | HCP Vault Dedicated on AWS and Azure |
| Support & Lifecycle | Community (GitHub Discussions, Zulip); two minor lines patched in parallel (2.6.x and 2.7.x) | Enterprise: IBM Support Cycle-2 (2 + 1 + 3 years per major); Community: forum |
| Latest Version (Nov 2026) | v2.7.2 (26 Oct 2026) | 2.2.1 (22 Oct 2026) |
OpenBao
Community-driven, MPL-2.0 secrets manager forked from HashiCorp Vault's last open-source code and managed under the Linux Foundation's OpenSSF. It keeps Vault's identity-based model of tokens, path-based policies, leases, dynamic secrets and encryption as a service, and adds multi-tenancy, HSM auto-unseal and post-quantum features in the open-source build.
Pros
- OSI-approved MPL-2.0 licence with open governance, so you can embed it or offer it as a service without licence questions
- Namespaces for secure multi-tenancy in the free build, with per-namespace Shamir sealing since v2.6.0
- PKCS#11 HSM auto-unseal, cloud KMS seals as plugins, and external keys so PKI and Transit can sign with HSM or KMS-held keys (v2.7.0)
- PostgreSQL storage backend that the docs recommend to newcomers over Raft, now with read scaling on standbys
- Early post-quantum support: ML-DSA in PKI and Transit and pure ML-KEM TLS key exchange on listeners
- API compatible with Vault, so most existing clients, tools and Vault Agent-style workflows keep working
Cons
- Fewer built-in plugins: cloud secrets engines and several provider seals live in the separate openbao-plugins repository
- In-place migration is only tested from Vault Community 1.14.1; newer Vault versions carry no storage-compatibility guarantee and Vault Enterprise was not tested
- No commercial vendor behind it; support is community channels or third parties
- Has diverged from Vault since late 2023, so Vault 2.x features such as the agent registry and secrets sync are not mirrored, and docs and tutorials are thinner
Best For
Teams that self-host secrets management and want namespaces, HSM-backed unseal and an OSI licence without an enterprise contract, and new deployments that would otherwise start on Vault Community Edition.
HashiCorp Vault
IBM's identity-based secrets and encryption management system, offered as source-available Community Edition under the Business Source License, as Vault Enterprise, and as HCP Vault Dedicated, a hosted Vault Enterprise on AWS or Azure. It is the original project OpenBao forked from and remains the most widely documented secrets manager of its kind.
Pros
- Largest ecosystem: built-in AWS, Azure and Google Cloud secrets engines, KMIP and key management, and broad third-party integration
- Enterprise adds performance and disaster-recovery replication across clusters, namespaces, Sentinel role and endpoint policies, HSM support and seal wrapping
- HCP Vault Dedicated runs the same Enterprise binary as a managed service on AWS or Azure
- Active 2.x line with features such as AI agent identity support, SCIM provisioning and secrets sync to cloud secret managers
- Defined Enterprise lifecycle: IBM Support Cycle-2 with 2 years of base support, 1 year of critical extended support and 3 years of sustained support per major release
Cons
- Business Source License since 1.15.0, so not OSI open source; offering it in a competing paid hosted or embedded product is not allowed
- Namespaces, HSM support, Sentinel and replication need an Enterprise licence or HCP Vault Dedicated
- HSM support is linux/amd64 only and requires an Enterprise licence
- Under IBM ownership, product direction and licence terms are set by one vendor
Best For
Organisations that want a commercially supported secrets platform, need cross-cluster replication, Sentinel or a managed service, or depend on Vault's cloud secrets engines and newest 2.x features.
The licence split and what it means for you
Vault's LICENSE file names IBM as licensor and applies the Business Source License 1.1 to Vault 1.15.0 and later. The additional use grant lets you run Vault in production as long as you don't offer it to third parties on a hosted or embedded basis to compete with IBM's paid versions, and it defines a competitive offering as a paid product that significantly overlaps with those versions. Each version converts to MPL 2.0 four years after it is published. For most companies running Vault Community Edition to store their own secrets, nothing changes. It matters if you sell a platform, managed service or appliance that includes a secrets manager, or if your company only allows OSI-approved licences. OpenBao exists for that case. It forked the last MPL-2.0 code (the 1.14 line its migration guide targets), is governed under the Linux Foundation's OpenSSF, and says it will keep an OSI-approved licence under open governance. That also changes who decides the roadmap: OpenBao's working groups on namespaces, PKCS#11, scalability and UI are public, while Vault's direction is IBM's. Neither project charges for the base server. The real choice is between a vendor with paid tiers and a community project with no paid tier.
Enterprise features OpenBao ships for free
Vault's own install page for Community Edition points users to Enterprise for HSM support, namespaces and Sentinel policies, and the namespace, replication and Sentinel docs all state that a Vault Enterprise licence or HCP Vault Dedicated cluster is required. OpenBao has taken several of these into its single free build. Namespaces provide multi-tenancy with isolated policies, secrets and identities per tenant, and since v2.6.0 each namespace can have its own Shamir seal, so a tenant can seal its partition without affecting others. The PKCS#11 seal lets an HSM protect the root key for auto-unseal. Version 2.7.0 added external keys, so PKI can sign certificates and Transit can sign or encrypt with keys that never leave a PKCS#11 HSM or another KMS. It also added control groups, which require a second party to approve requests to sensitive paths. What OpenBao does not replicate is Sentinel, HashiCorp's policy-as-code language. Its docs also don't describe Vault Enterprise's performance and disaster-recovery replication between clusters. If your design depends on a secondary cluster in another region serving reads, Vault Enterprise is the product that documents it. OpenBao scales reads within one cluster instead.
Storage, HA and scaling
Both use an active/standby model. One node holds a lock and serves writes, and standbys forward or redirect requests. OpenBao's HA page states plainly that HA alone does not add scalability, because the data store is usually the bottleneck. The storage choices have diverged. Vault recommends Integrated Storage (Raft), and Consul and other external stores remain options. OpenBao supports Raft and PostgreSQL and, unusually, recommends PostgreSQL to operators new to OpenBao as easier to run safely than Raft, since joining, managing and failing over nodes needs nothing beyond a connection URL. In v2.7.0 PostgreSQL gained horizontal read scaling similar to Raft's: standbys serve reads when ha_enabled is set and they can reach the primary, but only with PostgreSQL physical replication. New consistency headers let clients choose whether a stale standby should fail, forward to the active node or wait to catch up. OpenBao 2.7 also added a non-HA PebbleDB backend and deprecated the file backend for migrations, with removal planned for 2.8.0. Teams that already run a managed PostgreSQL cluster will find OpenBao easier to operate than a Raft quorum. Teams standardised on Raft snapshots can stay on Raft with either product.
Migrating from Vault to OpenBao
OpenBao's in-place migration guide is honest about its limits. It replaces the Vault process on every node and keeps configuration, endpoints and URLs. The API is meant to be compatible enough that clients don't notice, though some services may need a restart. But it was tested with OpenBao 2.2.0 and Vault Community Edition 1.14.1 using a Shamir seal. Vault versions older than 1.14.1 should be upgraded to 1.14.1 first. Newer Vault versions are untested and unsupported, and OpenBao makes no guarantee of storage compatibility with them. Vault Enterprise was never tested. Vault stores bootstrapped before 1.3 may need a rekey. Plugins are the other trap. OpenBao ships fewer built-in plugins, and any mount whose plugin it doesn't include, such as an AWS secrets engine, is skipped at startup and left as a stub that returns nothing. Inventory with vault secrets list and vault auth list before you start, and install the matching plugins from openbao-plugins where they exist. Vault 2.0 and later also create an agent-registry mount by default, which OpenBao will skip. For anything newer than 1.14, the safer path is a parallel OpenBao cluster, recreating auth methods and policies as code, copying KV data and cutting clients over by address.
Release cadence, support and where each is heading
Vault moved to a 2.x line in April 2026: 2.0.0 shipped on 14 April, 2.1.0 on 1 September and 2.2.0 on 15 October, with 2.2.1 on 22 October. For Enterprise and HCP Vault Dedicated 2.x, HashiCorp now follows IBM's Support Cycle-2: two years of base support, one year of critical extended support and three years of sustained support, counted from each major release. Recent 2.x notes focus on AI agent identity and access, SCIM provisioning, secrets sync with target-side encryption for AWS Secrets Manager and Google Cloud Secret Manager, a standalone Vault client binary in beta and a more guided UI. OpenBao released 2.6 in July and 2.7 in September 2026 and backports fixes to the previous minor line. On 26 October 2026 it released 2.7.2 and 2.6.5 together with the same security fixes. Its recent direction is infrastructure and cryptography rather than AI: KMS and seal plugins, post-quantum ML-DSA and ML-KEM, external keys, PostgreSQL read scaling and workflows. If a vendor-backed support contract or Vault's integrations are requirements, choose Vault. If licence certainty and multi-tenancy without an Enterprise contract matter more, OpenBao is now a mature option.
Verdict
Pick OpenBao for a new self-hosted secrets manager when you would otherwise start on Vault Community Edition. You get the same core model (tokens, path policies, leases, dynamic database credentials, PKI, Transit) under an OSI licence, plus namespaces, PKCS#11 HSM auto-unseal and control groups that Vault only offers in Enterprise. It is also the clear choice if you build a product or managed service on top of the secrets manager, because Vault's Business Source License forbids competing hosted or embedded offerings. Pick Vault if you are paying for Enterprise or HCP Vault Dedicated today, need performance or disaster-recovery replication across clusters, rely on Sentinel or Vault's built-in AWS, Azure and Google Cloud engines, or want a vendor with a published support lifecycle. If you already run Vault Community Edition internally, the BSL most likely doesn't restrict you, so migrate only for a concrete reason such as namespaces or licence policy. OpenBao has only tested in-place migration from Vault 1.14.1 and makes no storage-compatibility promise for newer Vault releases. For anything past 1.14, plan a fresh OpenBao cluster and copy secrets across rather than swapping binaries.