HashiCorp’s decision to move Vault from MPL 2.0 to the Business Source Licence (BSL 1.1) in August 2023 was the catalyst. BSL restricts use in competing products - it is not an open-source licence by OSI definition. For teams running open-source Vault on self-managed infrastructure, the immediate practical impact was minimal. The longer-term concern was: what happens when HashiCorp, now acquired by IBM in 2024, decides that “competing” includes managed service providers, cloud platforms, or internal tooling that happens to expose secrets management as a feature?
The community response was OpenBao. Now at v2.5.0 (released February 4, 2026) under Linux Foundation and OpenSSF governance, it has reached production-ready maturity. This is the decision point many teams have been deferring.
What Actually Differs Between Vault and OpenBao Today
OpenBao forked from Vault 1.14, the last version released under MPL. The fork maintains API and operational compatibility with Vault 1.14, meaning existing Vault clients, provider configurations, and automation tooling work against OpenBao without modification.
Since the fork, the two projects have diverged:
Vault 1.15 - 1.17+ (BSL) added features that OpenBao does not have:
- Some enterprise-tier plugins (HSM integration, certain cloud KMS backends) available commercially
- Performance replication improvements for global deployments
- Vault Radar (secret scanning for sprawl detection)
- Vault Secrets (the SaaS-hosted variant under HCP)
OpenBao v2.x has added community-driven improvements:
- Plugin architecture improvements enabling easier third-party auth backends
- Kubernetes auth improvements, including support for newer ServiceAccount token formats
- UI improvements (the Vault UI was never open-source in the enterprise version; OpenBao ships a fully open UI)
- Active community maintenance with IBM engineers as primary contributors
For most self-managed deployments using standard features - AppRole auth, PKI engine, KV v2, AWS and Kubernetes auth - there is no meaningful feature gap between Vault 1.14 and OpenBao 2.5. The gap exists at the enterprise edge: HSM clustering, DR replication at scale, and integrated cloud secret scanning.
The Decision Framework
Stay on Vault (BSL) if:
You have an existing HashiCorp enterprise contract and use enterprise features that are not available in OpenBao. Performance replication for multi-region active-active deployments is the most common case. If you are already paying for Vault Enterprise, the licence concern is already addressed in your contract and the migration cost outweighs the licence risk.
Also defensible: AWS-only shops where AWS Secrets Manager covers the use case adequately. Secrets Manager does not require a separately managed cluster, integrates directly with IAM, and its operational overhead is essentially zero. For teams that adopted Vault primarily because Secrets Manager lacked dynamic credential generation - that gap has narrowed significantly with Secrets Manager’s cross-account access and rotation improvements.
Migrate to OpenBao if:
You are running open-source Vault 1.14 or earlier on self-managed infrastructure and have no enterprise contract. The migration path is straightforward because OpenBao is API-compatible. The primary operational change is the binary name (bao instead of vault) and the import paths for Go client code. The Terraform hashicorp/vault provider works against OpenBao; the community maintains a dedicated openbao/vault provider that is the recommended long-term path.
Also migrate if you are building a product or platform that includes secrets management as a feature. BSL 1.1 explicitly restricts this use case. OpenBao’s Linux Foundation governance provides the licence stability that MPL 2.0 provided.
Move to a hosted alternative if:
Your primary motivation for Vault was avoiding credential sprawl and static secrets in environment variables, not the advanced features. Infisical and Doppler have both reached enterprise maturity with native CI/CD integrations (GitHub Actions, GitLab CI, CircleCI), Kubernetes operator support, and SOC 2 Type II certification. They eliminate the operational burden of running a Vault cluster entirely and cost less at the small-to-medium team scale than a Vault Enterprise licence.
For teams using Vault primarily as a place to store and rotate database credentials and API keys, Infisical’s dynamic secrets engine and Doppler’s environment syncing cover the use case without cluster management.
The Migration Path to OpenBao
If you decide to migrate from open-source Vault to OpenBao, the process is:
1. Assess your auth methods and secrets engines. Most standard engines (KV, PKI, database, AWS, Kubernetes, AppRole) are present in OpenBao. Verify that everything you use is available before starting.
2. Take a Vault snapshot. vault operator raft snapshot save backup.snap. This is your rollback point.
3. Deploy OpenBao in parallel. Run OpenBao in development mode against your existing unseal keys to verify that your Vault policies, auth configurations, and secrets engine mounts are compatible.
4. Migrate data. For KV v2, vault kv get and bao kv put with scripted iteration. For dynamic engines (PKI, database), the configuration migrates; the issued credentials do not need to.
5. Update clients. Change the VAULT_ADDR environment variable to point to OpenBao. If you are using the hashicorp/vault Terraform provider, it continues to work. Update to openbao/vault when convenient.
The hardest part of most migrations is finding all the places where VAULT_ADDR is hardcoded rather than configured via environment variable.
Static Credentials Are the Real Problem
OpenBao or Vault, the more important question is whether you are using either to distribute static long-lived credentials or to issue dynamic short-lived credentials.
Static credentials stored in Vault are safer than static credentials stored in environment variables or source code. They are not safe. A compromised Vault token with read access to the KV path containing AWS credentials is functionally equivalent to having those AWS credentials in plain text.
The right architecture pairs Vault or OpenBao with OIDC federation: GitHub Actions gets a short-lived OIDC token, exchanges it for an AWS STS credential via IAM OIDC federation, and never touches Vault at all for the AWS interaction. Vault handles the use cases where OIDC federation is not available: legacy application credentials, third-party SaaS API keys, database passwords for applications that cannot use IAM roles.
That architecture works identically with Vault 1.14, Vault 1.17, or OpenBao 2.5. The secrets manager choice matters less than the credential lifecycle design.