Dora NodaHashiCorp put Vault's license under lock in August 2023, and by 2026 the question every self-hosted platform builder eventually hits isn't academic anymore: can you actually ship Vault as your product's tenant-secrets backend, or does the license itself say no? The short answer is no — Vault Community Edition's Business Source License 1.1 explicitly bars using it inside a product you sell, which rules it out for embedding. The longer answer is that OpenBao, the Linux Foundation fork built from Vault's last open-source release, has spent the two years since closing the one feature gap that mattered most for multi-tenant platforms: namespaces, shipped free and GA in June 2025, where Vault keeps that exact feature locked behind Enterprise.
That's the verdict up front. The rest is the clause that forces it, the comparison that justifies it, and the concrete architecture a Cluster-API-based PaaS ends up with once it picks a side.
What BSL 1.1 Actually Restricts
HashiCorp's Business Source License 1.1 isn't a license against running Vault — it's a license against reselling it. The company's own licensing FAQ defines the restricted case precisely: a "competitive offering" is a product sold to third parties, including through paid support, that "significantly overlaps the capabilities" of a HashiCorp commercial product. Hosting or embedding a HashiCorp tool as part of a solution sold competitively against HashiCorp's own commercial version is explicitly named as a violation. Running Vault internally — one team standing it up for the rest of the org to use — is fine; HashiCorp's FAQ even extends that exception across affiliated divisions of the same organization.
A self-hosted PaaS offering "built-in tenant secrets management" as a product feature is not the internal-use case. It's a third party (the platform vendor) hosting or embedding Vault as part of a solution offered to other third parties (tenants) — precisely the shape the BSL's competing-offering clause was written to catch. That holds whether or not the platform charges specifically for the secrets feature, since the FAQ's test is about overlap with HashiCorp's commercial product, not itemized billing.
There's no ambiguity to lean on here: the license text and HashiCorp's own clarifying FAQ point the same direction. Wiring Vault CE into a product you distribute to customers is the exact scenario the BSL exists to prevent, unless you separately license Vault Enterprise or route around it entirely — which is the whole reason OpenBao exists.
OpenBao's Provenance and Why It's Not Just a Snapshot
The Linux Foundation announced OpenBao in December 2023, forked from Vault 1.14.0 — the last release still under the permissive MPL-2.0 license, before the BSL switch took effect. That starting point matters: OpenBao isn't rebuilding Vault's functionality from scratch, it's continuing development of the actual pre-BSL codebase under governance that can't unilaterally re-license it out from under users again.
The project joined the OpenSSF as a Sandbox project in June 2025, and by late April 2026 sat around 5,900 GitHub stars and 408 contributors. Engineers from IBM — Vault's own new corporate parent, following IBM's $6.4B acquisition of HashiCorp that closed in February 2025 — are among the active contributor base, an odd-looking but real detail of how tangled this fork's incentives now are.
Release cadence backs up the "not just maintaining a fork" claim. OpenBao ships roughly quarterly minor releases: v2.1.0 added PostgreSQL-backed transactional storage, v2.3.1 (June 2025) shipped namespaces as GA, and v2.5.0 (February 23, 2026) moved to Go 1.25.7 to close a CVE and fixed auto-unseal regressions across AWS KMS, Azure Key Vault, GCP Cloud KMS, and OCI KMS. That's active security and reliability work landing on the free fork, not a project coasting on its founding snapshot.
The Feature That Actually Decides This: Namespaces
Namespaces are the one Vault Enterprise feature a multi-tenant platform can't easily route around, and it's exactly the feature OpenBao gives away for free. In Vault, a namespace is a logical partition inside a single cluster — its own policies, auth methods, secret engines, tokens, and identity groups, isolated from every other namespace in the same install. Without it, a platform running Vault Community Edition for multiple tenants has exactly two options: give every tenant a flat share of one Vault CE instance's single policy namespace (real isolation risk — a misconfigured policy in tenant A's secrets engine can leak into tenant B's read path), or stand up one full Vault CE cluster per tenant (real operational cost — a Raft-backed HA cluster, unseal keys, and upgrade cadence multiplied by tenant count).
OpenBao closes that gap directly: namespaces landed as GA in the 2.3.1 release (June 2025) and continue picking up refinements through 2.5.x (OIDC key rotation fixes scoped to non-root namespaces, clearable per-namespace custom metadata) — this is a maturing primitive, not a checkbox feature. A platform can now run one OpenBao cluster and give each tenant app its own namespace: isolated policies and auth methods, without either the cross-tenant blast radius of shared-namespace Vault CE or the fleet-of-clusters cost of per-tenant Vault CE.
Here's how the three realistic options stack up for a self-hosted PaaS deciding what to wire in as its tenant secrets backend:
| Vault Community Edition | OpenBao | Infisical (self-hosted) | |
|---|---|---|---|
| License | BSL 1.1 — bars embedding in a resold product | MPL-2.0, Linux Foundation/OpenSSF governed | MIT-core, self-host free |
| Multi-tenant namespaces | Enterprise-only | Free, GA since June 2025 | No Vault-style namespace hierarchy; project/org scoping instead |
| Storage backend | Raft (Integrated Storage) or Consul | Raft or PostgreSQL (transactional storage since v2.1.0) | PostgreSQL + Redis |
| Dynamic secrets, PKI engine | Yes (CE) | Yes (inherited from the fork) | Limited — mainly static/synced secrets |
| HSM / auto-unseal via cloud KMS | HSM is Enterprise-only; cloud auto-unseal in CE | Cloud auto-unseal in CE-equivalent tier (fixed in 2.5.0) | Not applicable — simpler threat model |
| Ops complexity | High — Raft/Consul HA, unseal ceremony | Same as Vault (same underlying architecture) | Low — Docker/Kubernetes-native, one Postgres |
| Safe to embed in a sold product | No | Yes | Yes |
The two columns that actually decide the question are the first and the third: license (does embedding it risk the product) and multi-tenant namespaces (does it let you scope isolation to one cluster instead of one cluster per tenant). OpenBao is the only option that clears both, if the platform's tenants need Vault-grade features — dynamic database credentials, PKI issuance, transit encryption — behind that isolation. Infisical clears the license bar too, and its PostgreSQL-only architecture is a real operational simplification, but it's the right choice only for a platform whose tenants need static secret storage and don't need dynamic credentials or an internal CA — trading Vault-class capability for Vault-class complexity being absent.
What This Actually Looks Like Wired Into a Cluster-API Fleet
For a git-push PaaS reconciling a fleet through Cluster API, the concrete shape is one OpenBao cluster (Raft-backed HA, or PostgreSQL transactional storage if the fleet already runs a managed Postgres it can lean on) run as platform-owned infrastructure — not per-tenant, not embedded inside each app's own namespace. Every deployed app gets its own OpenBao namespace, provisioned at the same time as its Kubernetes namespace and Cluster API-managed compute, with a Kubernetes auth method scoped so a tenant's own service account can only authenticate into its own OpenBao namespace. Secrets reach the running pod through the Secrets Store CSI driver's OpenBao/Vault provider, mounted as files or synced to a Kubernetes Secret, so nothing in the app's own container image needs to know it's talking to OpenBao specifically rather than any other Vault-API-compatible backend.
That architecture gets a platform three things Vault CE structurally can't provide without a license upgrade or a cluster-per-tenant tax: isolation that scales with tenant count instead of infrastructure count, dynamic database credentials issued per-namespace instead of one shared static secret sprawled across tenants, and a license that doesn't put the product itself in violation the moment it's offered to a second customer.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Wiring a licensing-clean, multi-tenant secrets backend into your own fleet is exactly the kind of infrastructure decision worth owning rather than renting. Star the repo on GitHub or deploy your first app today.
Sources
- HashiCorp adopts Business Source License
- HashiCorp Licensing FAQ
- Business Source License 1.1
- HashiCorp updates licensing FAQ based on community questions
- Meet OpenBao, an Open Source Fork of HashiCorp Vault - The New Stack
- OpenBao
- Announcing OpenBao Namespaces
- Namespaces | OpenBao
- Announcing OpenBao v2.1.0: Transactional Storage, PostgreSQL, and More!
- OpenBao 2.5.x release notes
- Understand available Vault editions | Vault | HashiCorp Developer
- Open Source Secrets Management for DevOps in 2026 | Infisical
- HashiCorp Vault Alternatives [2026] | Infisical