OpenBao

Secrets management, honestly reviewed. No marketing fluff — just what you actually get when you swap Vault’s BSL for something you can legally run forever.

TL;DR

• What it is: OpenBao is a community-driven, MPL-2.0-licensed fork of HashiCorp Vault 1.14.0 — the last version before HashiCorp switched to the Business Source License. The Linux Foundation governs it; IBM engineers started it [1].
• Who it’s for: Platform and security teams already familiar with Vault who want the same API, the same secrets model, and no licensing anxiety — plus smaller teams that need enterprise-grade secrets management without enterprise pricing [2][3].
• Cost savings: HashiCorp Vault Enterprise and HCP pricing are opaque and negotiated; specific SaaS comparison data not available. What is clear: OpenBao is free to self-host under MPL 2.0 with no usage restrictions, no per-secret pricing, and no commercial-use clauses [1][3].
• Key strength: Near-complete API compatibility with Vault means you can migrate existing tooling without rewriting config. It now ships features Vault Enterprise locked away — including namespaces, which became generally available in v2.3.1 [4].
• Key weakness: You own the operational burden entirely. High-availability requires a Raft or Consul quorum you provision yourself, and the project has far fewer commercial support options than Vault. The community is real but smaller [2].

---

What is OpenBao

OpenBao exists because HashiCorp changed Vault’s license in 2023 from MPL 2.0 to the Business Source License 1.1 — the same move that produced OpenTofu from Terraform. The fork was initiated by IBM engineers who grabbed the last MPL-licensed Vault release (1.14.0) before the license switch took effect [1].

The project is now hosted under the Linux Foundation and operates under its own Technical Steering Committee. As of February 2026 it released version 2.5.0 and has accumulated 5,642 GitHub stars. Supporters listed on the project homepage include GitLab, SAP, WALLIX, and EdgeX Foundation — not a scrappy one-person fork [1][homepage].

What OpenBao actually does: it sits between your applications and every sensitive string they need to function. Database passwords, AWS keys, TLS certificates, API tokens — instead of hardcoding these into config files or environment variables, your services request them from OpenBao at runtime. OpenBao issues the credential, sets a time-to-live on it, and automatically revokes it when the lease expires. If someone gets into your database and reads the raw storage, they see ciphertext. If an employee leaves, you revoke their token tree and everything they had access to stops working — without touching individual services [README].

The architecture OpenBao inherited from Vault is well-understood: an initialization step generates a master key split using Shamir’s Secret Sharing, servers must be unsealed before they serve requests, and all data written to storage is encrypted before it touches disk or PostgreSQL [1][README].

---

Why people choose it over HashiCorp Vault

The conversation about OpenBao in 2026 is almost entirely about licensing and governance, not features. The feature set started at parity with Vault 1.14 and has since diverged in OpenBao’s favor in specific areas.

The BSL problem. HashiCorp’s BSL 1.1 allows you to use Vault in production under most circumstances, but prohibits offering Vault “as a service” in a way that competes with HashiCorp’s commercial offerings. For most infrastructure teams, this is theoretically fine — until it isn’t. The concern is drift: licenses get reinterpreted, companies get acquired, enforcement policies change. ControlPlane, a security consulting firm that has now hired OpenBao’s top contributor (Alex Scheel, former TOC chair), frames this plainly: their clients — from startups to Tier 1 banks — wanted to “maintain their open source posture and digital sovereignty, but lacked a clear, supported path” [3]. MPL 2.0 closes that anxiety permanently.

Enterprise features without enterprise pricing. The clearest concrete advantage OpenBao has over open-source Vault today is namespaces. In Vault, multi-tenant isolation — separate policies, separate authentication strategies, separate secret trees per team or application — required the Enterprise tier. OpenBao shipped namespaces as a community feature in v2.3.1, developed in the open through a working group involving contributors from Adfinis, Wavelo, Tucows, and others [4]. A single OpenBao instance can now isolate secrets by app, by team, or by environment without any commercial agreement.

Governance trust. The Linux Foundation structure matters to organizations that have been burned by vendor-controlled open source before. OpenBao’s TSC is public; working groups operate in the open on GitHub Discussions and Zulip. The roadmap is documented, not inferred from product announcements [2][3].

Kindalame.com’s assessment [2] cuts to what “production-ready” actually means for small teams in 2026: OpenBao now ships native PKI, dynamic credential generation, identity-based access that binds secrets to Kubernetes service accounts or OIDC providers, and built-in audit logging to JSON that can feed any SIEM. Teams that have migrated from managed Vault report comparable latency and reliability on the same storage backends [2].

---

Features

Based on the README, website, and independent reporting:

Core secrets engine:

• Arbitrary key/value secret storage, encrypted at rest before hitting persistent storage [README]
• Dynamic secrets — generate AWS keypairs, database credentials, SSH certificates on demand; auto-revoke after TTL expires [README][website]
• Leasing and renewal — every secret has a TTL, clients can renew via API before expiry [README]
• Revocation — single secret, subtree, or everything a specific token has touched [README]

Encryption as a service:

• Encrypt and decrypt data without storing it — security teams define the key, developers call the API [website]
• Centralized key management across cloud and on-prem [website]

Identity and access:

• Unified ACL system for brokering access across services and cloud providers [website]
• Identity merging across providers — OIDC, Kubernetes service accounts, and more [website]
• Bind secrets to workloads rather than static tokens; no long-lived passwords in env vars [2]

Namespaces (new in v2.3.1):

• Multi-tenant isolation on a single instance — separate policies, auth methods, and metadata per namespace [4]
• Manipulable via /sys/namespaces API or the bao namespace CLI
• Scoped via HTTP header, environment variable, or -namespace flag [4]
• This was a Vault Enterprise feature; it’s community-tier in OpenBao [4]

PKI and certificates:

• Full PKI secrets engine — issue, rotate, and revoke TLS certificates [2]
• Automated certificate rotation on the roadmap for 2026 [2]
• PKCS11 working group in progress [README]

Audit:

• Built-in audit log ships JSON events, compatible with any SIEM [2]
• Part of core server, not an add-on [2]

Storage backends:

• PostgreSQL, integrated Raft (built-in), Consul [README][2]
• Roadmap includes cloud-native object store backends (S3, GCS) to reduce dependency on a separate Consul cluster [2]

Deployment:

• Docker and Helm supported [merged profile]
• Version 2.5.0 as of February 2026 [1]

---

Pricing: SaaS vs self-hosted math

OpenBao has no SaaS tier. It is a self-hosted tool. The comparison that matters is OpenBao self-hosted versus the alternatives you’d pay for.

HashiCorp Vault pricing: Vault’s open-source edition operates under BSL 1.1 — free to use, but with commercial redistribution restrictions. HashiCorp Cloud Platform (HCP) Vault pricing is not publicly listed with fixed tiers; it is usage-based and negotiated. Specific dollar comparisons are not available in the source material for this review.

OpenBao self-hosted:

• License cost: $0 (MPL 2.0, no restrictions) [1]
• Infrastructure: a 2–4 node cluster for HA on commodity VPS — roughly $15–40/mo depending on provider and node size, based on standard VPS pricing for the specs required
• Enterprise support: ControlPlane now offers commercial enterprise support and SLAs for OpenBao, for teams that need it [3]

What you’re actually avoiding: The primary financial argument for OpenBao isn’t switching from a low-cost tier — it’s avoiding Vault Enterprise licensing, which is negotiated per-organization and consistently described as significant cost. For teams already self-hosting open-source Vault under BSL and concerned about the license, the migration cost to OpenBao is the operational work of switching — the ongoing cost is the same [1][3].

If your current setup is HCP Vault or Vault Enterprise and you’re paying a meaningful monthly bill, OpenBao self-hosted with a ControlPlane support contract is the migration path worth pricing out [3].

---

Deployment reality check

OpenBao inherits Vault’s deployment complexity — which means it is not a one-afternoon project for someone who has never touched secrets management infrastructure before. That said, the operational model is well-documented and battle-tested.

What you actually need:

• At least one server (single-node works for dev/small teams, not recommended for production without HA)
• For HA: a minimum three-node Raft quorum, or external Consul cluster [2]
• PostgreSQL or integrated Raft for storage [README]
• A TLS certificate (the server will refuse plaintext connections in production mode)
• An unsealing strategy — manual key shares, cloud KMS auto-unseal, or hardware HSM

What the seal/unseal ceremony means in practice: Every time an OpenBao server restarts, it starts sealed. No requests are served until enough key share holders (you defined the threshold at init time) provide their shares. Forgetting this detail at 2am when a server reboots after a kernel update is how production incidents happen. This is not unique to OpenBao — it’s the Vault model — but it’s worth stating plainly for anyone new to the stack [1].

Namespaces add complexity gradually. The feature exists now and is documented, but multi-tenant namespace design requires deliberate planning around policy inheritance, auth method scoping, and token policies. The Adfinis blog post [4] is the best available primer on how they work in practice.

What can go sideways:

• High availability storage is not optional for production. The kindalame.com review [2] is explicit: “Small teams must provision and monitor this layer themselves, which can be as complex as running a managed database service.”
• Audit log discipline requires active management. Rotating and shipping logs to a SIEM is plumbing you own.
• Disaster recovery and backup procedures need to be tested, not just documented. The unseal key shares need to exist somewhere offline; losing them is losing access to everything [1][2].
• Certificate lifecycle is still a manual operational task in the current release; automated rotation is on the 2026 roadmap, not shipped yet [2].

Realistic time estimate for an experienced infrastructure engineer: 2–4 hours for a working single-node instance, a full day to get HA Raft configured and tested. For teams new to secrets management infrastructure: budget a week including policy design.

---

Pros and Cons

Pros

• Genuine MPL 2.0 license. No commercial restrictions, no BSL interpretation risk, no “what happens when HashiCorp gets acquired” anxiety. OSI-approved. Fork it, embed it, offer it to clients [1][3].
• API compatibility with Vault. Existing Vault configurations, Terraform providers, Kubernetes auth methods, and operator tooling work without rewriting. Migration from open-source Vault is low-friction [1][2].
• Namespaces without Enterprise license. Multi-tenant isolation on a single instance is now a community feature, not a premium one [4].
• Linux Foundation governance. Public TSC, working groups in the open, roadmap documented. Not controlled by a single vendor’s commercial interests [1][3].
• Production-grade audit logging out of the box. JSON event stream compatible with any SIEM, built into core [2].
• Identity-based access model. Bind secrets to workloads, Kubernetes service accounts, OIDC — not to static long-lived tokens [2][website].
• Active development. Version 2.5.0 in February 2026; regular commits; multiple working groups on namespaces, PKCS11, scalability, and supply chain [1][README].
• Commercial support now available. ControlPlane offers enterprise SLAs with a core maintainer on staff, which removes the “no support” objection for larger teams [3].

Cons

• You own all of the operations. No managed tier, no hosted option from the OpenBao project itself. Every alert, every unseal event, every DR test is your team’s problem [2].
• HA requires real infrastructure investment. A three-node Raft cluster or Consul quorum is table stakes for production. This is not a Docker-run-and-forget tool [2].
• Smaller support ecosystem than Vault. HashiCorp has thousands of enterprise customers, a full support organization, and a mature SLA market. OpenBao has ControlPlane and community Zulip. The gap is closing but real [3].
• 5,642 stars vs. Vault’s 33,000+. Vault’s mindshare, community plugins, and blog post coverage still dwarf OpenBao’s. When something breaks at 3am, the StackOverflow thread is more likely to be about Vault [1].
• Some Vault Enterprise features still not ported. Namespaces shipped; others are in working groups or backlog. If you’re migrating from Vault Enterprise and depend on a specific enterprise feature, verify it exists in OpenBao before committing [4].
• Automated certificate rotation not yet shipped. It’s on the 2026 roadmap but was not available at time of writing [2].
• Learning curve is steep for secrets management newcomers. The seal/unseal model, policy language, and auth method configuration are powerful but not beginner-friendly. This tool is not analogous to plugging in a SaaS credential manager [1][2].

---

Who should use this / who shouldn’t

Use OpenBao if:

• You are currently on open-source Vault and the BSL license is a legal or governance concern. Migration cost is low; long-term licensing certainty is the payoff.
• Your organization has a “Linux Foundation / OSI-approved only” policy for foundational infrastructure.
• You need multi-tenant secrets isolation (namespaces) but cannot justify Vault Enterprise pricing.
• You have an infrastructure team with experience running distributed systems, and you want secrets management that doesn’t report to any vendor’s commercial roadmap.
• You’re a platform team at a bank, defense contractor, or regulated industry where running third-party code under BSL creates a compliance question.

Skip it if you’re evaluating your first secrets manager:

• Start with something simpler — Bitwarden Secrets Manager (for teams), Doppler (managed SaaS), or even AWS Secrets Manager if you’re already on AWS. OpenBao is not the right first secrets tool for a non-technical founder running two microservices.

Stay on HashiCorp Vault if:

• You’re on Vault Enterprise and heavily dependent on features not yet ported to OpenBao. Audit what you’re using before moving.
• Your team has no interest in managing the operational burden and would pay for HCP Vault’s managed tier. The UX of not thinking about unseal and HA is worth real money for some organizations.

Consider a managed alternative if:

• You want Vault-compatible APIs but don’t want to run the server. Infisical offers a self-hosted or managed secrets platform with a different UX; HashiCorp’s own HCP is the path of least resistance if BSL is not a concern.

---

Alternatives worth considering

• HashiCorp Vault (open-source, BSL 1.1) — the upstream. Feature-complete, larger community, better documented, but the license question doesn’t go away. [1]
• HashiCorp Vault (Enterprise / HCP) — managed, fully supported, priced accordingly. The right choice if you want to buy your way out of operational burden and aren’t concerned about BSL. [3]
• Infisical — a newer, more developer-friendly secrets platform (MIT license, self-hostable or managed). Better UI, less operational complexity, but not Vault API-compatible. Worth evaluating if you’re starting fresh rather than migrating.
• Doppler — managed SaaS secrets manager, no self-hosting required. No per-secret pricing; subscription model. The right pick if you want zero ops overhead and don’t care about data sovereignty. [2]
• AWS Secrets Manager / GCP Secret Manager / Azure Key Vault — cloud-native options that are fine if you’re single-cloud and want zero infrastructure. Vendor lock-in is real; data leaves your control. [2]
• SOPS + age — for simpler use cases (static secrets in config files encrypted at rest), SOPS with age keys is dramatically simpler to operate than any Vault-like system. Not a replacement for dynamic secrets or PKI, but often more than sufficient for small deployments.

---

Bottom line

OpenBao is the correct answer to one specific question: “We’re running Vault under an open-source or BSL license and we need that license story to be clean forever.” If that’s your situation, the migration is low-friction, the governance is trustworthy, and the project is now mature enough — version 2.5, namespaces shipped, commercial support available — that it’s not a bet on a community experiment. It’s a bet on the Linux Foundation model, which has a reasonable track record.

The honest caveat is that OpenBao does nothing to solve the underlying complexity of secrets management infrastructure. The seal ceremony, the HA requirements, the audit discipline, the certificate lifecycle work — these are all still yours. If your team isn’t already comfortable running Consul, Raft, and a reverse proxy for TLS termination, the hours you spend on OpenBao operations will cost more than any enterprise licensing fee you’d otherwise pay. For non-technical founders and small teams without a dedicated platform engineer, a managed SaaS secret store almost certainly makes more sense. For teams that already run this stack and need the licensing question answered, OpenBao answers it cleanly.

---

Sources

1. Lalatendu Keshari Swain, Medium — “OpenBao vs HashiCorp Vault: The Secrets Management Showdown Every DevOps Team Needs to Read in 2026” (Feb 13, 2026). https://lalatenduswain.medium.com/openbao-vs-hashicorp-vault-the-secrets-management-showdown-every-devops-team-needs-to-read-in-2026-458ae0d9a408

2. ImaLamer, Kindalame.com — “OpenBao Is the Only Self-Hosted Secrets Stack Small Teams Should Consider in 2026” (Apr 3, 2026). https://kindalame.com/2026/04/03/openbao-is-the-only-self-hosted-secrets-stack-small-teams-should-consider-in-2026/

3. Andrew Martin, ControlPlane — “Why We Are Throwing Our Weight Behind OpenBao” (Mar 20, 2026). https://control-plane.io/posts/why-we-support-openbao/

4. Adfinis — “OpenBao Basics: How Namespaces Became a Reality” (Oct 29, 2025). https://www.adfinis.com/en/news/openbao-basics-namespaces

Primary sources:

• GitHub repository and README: https://github.com/openbao/openbao (5,642 stars, MPL-2.0 license)
• Official website: https://openbao.org
• Documentation: https://openbao.org/docs/