OpenBao: Linux Foundation fork of HashiCorp Vault under MPL-2.0

What is OpenBao?

OpenBao is a community fork of HashiCorp Vault, founded in December 2023 as a direct reaction to Vault's license switch from MPL-2.0 to Business Source License 1.1. The project was accepted into the Linux Foundation in April 2024 and has been under its governance since. As of May 2026 OpenBao is stable in version 2.x and production-ready, with active development by a community of IBM, GitLab, Mountpoint, IONOS, and a range of cloud-native vendors.

The fork point is Vault 1.14 -- the last version under MPL-2.0 license. Since the fork OpenBao has published its own releases with bug fixes, security patches, and new features. As of May 2026 OpenBao has its own roadmap focused on cloud-native integration, Kubernetes operator tooling, and open-standards-first. Functionally OpenBao is about 90 percent of HashiCorp Vault: all important secrets engines (KV v2, Database, PKI, AWS, Transit), all auth methods (AppRole, Kubernetes, OIDC, GitHub), auto-unseal via cloud KMS or Shamir keys, audit devices, HA cluster with Raft storage.

What Vault has and OpenBao (still) does not: some enterprise features like HSM auto-unseal, performance replication between multiple Vault clusters, FIPS 140-2 certified builds, MFA push notifications. Irrelevant for standard Swiss SME setups; for FINMA-regulated banking fiduciaries with HSM duty a gap.

The MPL-2.0 license is Mozilla Public License 2.0 -- a fully OSI-certified open-source license with copyleft at file level. It allows commercial use without restriction, allows forking and reselling as a service (which BSL 1.1 forbids), and allows mixing with proprietary code. For Swiss SMEs with OSS compliance requirements or for cloud providers wanting to offer a Vault-like product, OpenBao is the only option.

Migration from Vault to OpenBao is drop-in for almost all use cases: same API endpoints, same CLI (openbao instead of vault), same HCL syntax for policies, same storage backends. Backup with vault operator raft snapshot save can be restored in OpenBao with openbao operator raft snapshot restore. The investment in policies, engines, and integrations is preserved in the migration path.

Why it matters for OSS-strict Swiss SMEs

OpenBao is the right choice over Vault in four concrete scenarios in May 2026.

Strict OSS policy: when the SME has a compliance requirement that only OSI-certified open-source licenses may be deployed, Vault under BSL 1.1 is no longer acceptable. This requirement is common at public-sector institutions, educational institutions, NGOs, or clients with their own OSS policy. OpenBao under MPL-2.0 fully meets the requirement.

Reduce vendor lock-in risk: HashiCorp was acquired by IBM in March 2024. Vault's strategic direction is thus subject to IBM corporate policy, with potentially different priorities than at an independent HashiCorp. Linux Foundation governance is neutral -- no single company can dominate the roadmap. For Swiss SMEs with long-term planning (10+ years) this is a relevant factor.

Commercial reuse in SaaS stack: anyone building their own cloud product offering secrets management as a service (e.g. a fiduciary SaaS with built-in Vault API for clients) cannot use Vault under BSL 1.1. OpenBao under MPL-2.0 allows that without restriction. Practically relevant for all Swiss SMEs planning their own white-label service with secrets functionality.

Migration from Vault BSL without functional loss: SMEs running Vault under MPL-2.0 in production and unwilling to install new updates under BSL can migrate to OpenBao with minimal effort. Drop-in API, same CLI commands (openbao instead of vault), same HCL policies. Snapshot migration possible in 1-2 hours.

revFADP requirements: OpenBao meets all revFADP requirements Vault meets -- audit trail, access logs, rotation, compromise response. The Swiss EDÖB has no preference for a particular implementation as long as protective measures meet state of the art. OpenBao is state of the art in 2026.

Setup and migration from Vault

OpenBao runs on the same infrastructure as Vault. Setup and operations effort are identical. We show Docker Compose and the Vault-to-OpenBao migration path.

```yaml version: "3.8" services: openbao: image: openbao/openbao:2.0 container_name: openbao restart: unless-stopped cap_add: - IPC_LOCK environment: - BAO_ADDR=http://0.0.0.0:8200 - BAO_LOCAL_CONFIG={"storage":{"raft":{"path":"/openbao/data","node_id":"openbao-1"}},"listener":{"tcp":{"address":"0.0.0.0:8200","tls_disable":1}},"ui":true,"api_addr":"http://openbao:8200","cluster_addr":"https://openbao:8201","disable_mlock":true,"seal":{"awskms":{"region":"eu-central-1","kms_key_id":"alias/openbao-unseal"}}} ports: - "127.0.0.1:8200:8200" volumes: - ./openbao-data:/openbao/data - ./openbao-logs:/openbao/logs command: openbao server -config=/openbao/config/openbao.hcl ```

Initialisation at first start: openbao operator init -recovery-shares=5 -recovery-threshold=3 (analogous to Vault).

Migration from Vault to OpenBao in 4 steps:

1. Create Vault snapshot: ```bash vault operator raft snapshot save vault-final.snap vault status > vault-final-status.txt vault policy list > vault-policies.txt ```

2. Set up OpenBao cluster with same storage layout, same unseal parameters. Important: use OpenBao version that can read Vault 1.14 snapshot.

3. Restore snapshot in OpenBao: ```bash openbao operator raft snapshot restore vault-final.snap openbao operator unseal <recovery-key-1> openbao operator unseal <recovery-key-2> openbao operator unseal <recovery-key-3> ```

4. Switch applications: VAULT_ADDR=https://openbao:8200 instead of vault:8200. For vault-agent: vault-agent still works against OpenBao because API is identical. Alternatively use openbao-agent.

Example KV engine for API keys (identical to Vault): ```bash openbao secrets enable -path=kv kv-v2 openbao kv put kv/openai api_key=sk-proj-xyz... openbao kv get kv/openai ```

AppRole for server auth (identical to Vault): ```bash openbao auth enable approle openbao write auth/approle/role/treuhand-app \ token_policies="treuhand-policy" \ token_ttl=1h token_max_ttl=4h ```

Important openbao CLI commands: openbao status shows cluster status. openbao operator raft list-peers shows HA members. openbao audit list shows active audit devices. openbao token lookup shows token details. openbao token revoke <id> revokes token immediately.

Integration with other tools: openbao-agent as sidecar, OIDC auth against Authentik/Authelia, Kubernetes operator (openbao-secrets-operator) for K8s workloads, Terraform provider (openbao/openbao) for infrastructure-as-code.

OpenBao roll-out in 5 steps

1. 01Decision check: assess BSL 1.1 vs MPL-2.0 for the SME; if Vault already runs, choose migration vs greenfield setup.
2. 02Set up OpenBao cluster: 3 nodes with Raft storage, auto-unseal via cloud KMS or Shamir keys (3-of-5); run openbao operator init and unseal.
3. 03Configure secrets engines and auth methods: KV v2, Database, PKI; AppRole, OIDC via Authentik/Authelia; policies by least privilege.
4. 04Migration from Vault (if existing): snapshot with vault operator raft snapshot save, restore with openbao operator raft snapshot restore, switch applications to new endpoint.
5. 05Audit, rotation, and monitoring: audit engine to Loki/Splunk, rotate static secrets every 90 days, document compromise runbook (72h notification), check HA cluster health monthly.

When to choose OpenBao over Vault

OpenBao is the better choice over Vault in four constellations in May 2026.

Strict OSS license policy: SMEs or public institutions with a compliance requirement of "only OSI-certified open-source licenses". BSL 1.1 is not OSI-certified, MPL-2.0 is. OpenBao is the only direct option. Alternative would be Bitwarden Secrets Manager (GPL-3) -- functional but significantly less powerful.

Multi-tenant SaaS builds: anyone building their own product delivering Vault-like functionality to clients as a service (e.g. fiduciary SaaS with secrets API for client-owned tooling) cannot use Vault under BSL 1.1. OpenBao under MPL-2.0 is the only viable choice.

Vendor lock-in reduction: SMEs with long-term strategy (10+ years) and concern about IBM strategy shifts after the HashiCorp acquisition. Linux Foundation governance offers neutrality.

New greenfield deployments without Vault history: anyone building a secrets management setup from scratch in 2026 has no investment protection reason to choose BSL Vault. OpenBao is functionally equivalent for 90 percent of use cases, with OSS license advantage and neutral governance.

Vault BSL remains the right choice when: (a) HSM auto-unseal is mandatory (FINMA banking fiduciary with HSM requirement); (b) performance replication between multiple data centres is needed; (c) FIPS 140-2 certified builds in regulated US environments are mandatory; (d) HashiCorp Cloud Platform (HCP Vault) is used as managed service -- OpenBao cloud variant is not yet available at comparable maturity in May 2026.

When OpenBao is not enough

Three cases where OpenBao is not the right choice in May 2026.

FINMA banking fiduciary with HSM duty: HashiCorp Vault Enterprise supports HSM auto-unseal via PKCS#11 interface against hardware security modules (Thales, Utimaco, AWS CloudHSM). OpenBao does not have that in standard build as of May 2026. Anyone with FINMA high-risk mandates and HSM duty stays with Vault Enterprise.

Managed service need with enterprise SLA: HashiCorp Cloud Platform (HCP) offers Vault as managed service with 99.95 percent SLA, 24/7 support and IBM corporate backing. OpenBao cloud variants in May 2026 exist only from small providers without comparable SLA. Anyone needing managed service with enterprise SLA goes to HCP Vault.

Performance replication between data centres: Vault Enterprise has active performance replication between multiple Vault clusters (e.g. Zurich and Frankfurt). OpenBao can do disaster-recovery replication but no active performance replication with read/write forwarding. For multi-region setups with latency requirements, Vault Enterprise remains the choice.

General pitfalls in OpenBao deployments: (a) assumption that all Vault modules work 1:1 -- most yes, some special modules (HSM, FIPS, MFA push) no. (b) Wanting to migrate Vault Enterprise license to OpenBao -- enterprise modules are closed source, OpenBao has only OSS modules. (c) Hiring HashiCorp consultants for OpenBao setup -- most do not yet know the tool in depth, ask Linux Foundation maintainers or independent consultants. (d) OpenBao version jump from 1.x to 2.x without test phase -- check API changes, snapshot test restore in advance.

Trade-offs

FAQ

Related topics

Sources

1. OpenBao -- official documentation · 2026-05
2. OpenBao GitHub -- v2 release notes · 2026-04
3. Linux Foundation -- OpenBao project page · 2026-03
4. HashiCorp -- BSL 1.1 license FAQ · 2026-03
5. OWASP Secrets Management Cheat Sheet · 2026-03