OpenBao, the Vault fork and the MPL 2.0 licence

OpenBao, the Vault fork and the MPL 2.0 licence

OpenBao is a fork of HashiCorp Vault taken a few commits after the 1.14.8 release, right before Vault's maintenance branch moved to the Business Source License. The current release is 2.6.2 from 18 August 2026, the licence file is simply called LICENSE, and it still opens with the notice Copyright (c) 2015 HashiCorp, Inc.. That notice is not an oversight.

Where OpenBao came from

The fork point is documented down to the commit, in a place that is easy to miss: the file website/src/components/FAQSection/index.tsx, that is, the project website's code rather than its documentation. The answer to the question about which Vault version the fork came from says that OpenBao was forked prior to upstream's last commit before the BUSL, with the short hash 8993802, and that this corresponds to a few commits after 1.14.8 but before 1.14.9 was cut.

That description can be verified independently and it holds. The LICENSE file in the hashicorp/vault repository at tag v1.14.8 starts with the notice Copyright (c) 2015 HashiCorp, Inc. and contains the Mozilla Public License version 2.0. The same file at tag v1.14.9 starts with a notice about MariaDB Corporation Ab's rights to the Business Source License text. Vault 1.14.8 shipped on 6 December 2023, and 1.14.9 only on 31 January 2024. OpenBao therefore caught the last release under an open licence and branched from the code just past it.

The order of events is not linear, and that is a common source of confusion. Vault 1.15.0 shipped on 27 September 2023 and was already under the BSL. The 1.14.x branch kept receiving MPL releases for another four months, and the licence switch reached it late, at 1.14.9. The same treatment covered older branches: the licence file at tag v1.13.13 is BSL text as well. The last Vault release under an open licence therefore remains 1.14.8, a release that has not received security fixes for a long time.

Governance changed twice. OpenBao started under LF Edge, and on 17 June 2025 it was accepted as a sandbox project into the OpenSSF. The project site's footer still signs itself "OpenBao a Series of LF Projects, LLC", so formally this is a Linux Foundation project now run under the OpenSSF, not a separate foundation. The first generally available release, 2.0.0, carries the date 17 July 2024 on its GitHub release page, while the blog post announcing it is dated 25 July 2024. The eight-day gap comes from the tag being pushed twice, which the release note itself explains: the original commit 7e0e830 was replaced by commit 700fe3f with no code changes.

Project scale at the time of writing: the openbao/openbao repository has roughly 7.1 thousand stars, 544 forks, 244 open issues and 70 open pull requests.

The OpenBao licence from three sources

The first source is the file in the repository. At tag v2.6.2 the root directory holds exactly one licence file, LICENSE, at 15958 bytes and 365 lines. The variants LICENSE.md, LICENSE.txt, license.md, COPYING, NOTICE and LICENSING.md all return 404. The api/ and sdk/ directories, which are separate Go modules, have no licence files of their own. The content is HashiCorp's 2015 copyright notice, followed by the full text of the Mozilla Public License version 2.0, down to Exhibit A and Exhibit B. Source file headers, for example in sdk/logical/storage.go and version/version_base.go, carry two lines: // Copyright (c) HashiCorp, Inc. and // SPDX-License-Identifier: MPL-2.0.

Keeping the predecessor's notice is not an omission but a requirement of the licence itself: MPL 2.0 mandates preserving existing copyright notices in covered code. Valkey did exactly the same, leaving the Redis Ltd. notice in its COPYING file. The practical conclusion is identical in both cases: another company's copyright notice inside a fork says nothing about who runs the project today.

The second thing to note in that file is Exhibit B. MPL 2.0 allows code to be marked "Incompatible With Secondary Licenses", which cuts off combining it with GPL, LGPL and AGPL code. In the OpenBao repository this exhibit appears only as part of the standard licence text and is attached nowhere as a notice on the code. The code is therefore plain MPL 2.0, compatible with secondary licences.

The second source is the package registry, and this is where it gets unusual. OpenBao is a Go project, so the registry is the module proxy. There are several modules and their paths diverge. The main server module is still github.com/openbao/openbao, with no /v2 suffix, even though releases are numbered 2.x. The consequence is that the proxy cannot serve version 2.6.2 for that module at all and returns an invalid version error, because go.mod declares a path without /v2. Asking for the latest version returns the pseudo-version v0.0.0-20260714213526-4771dc118499. The client libraries do have correct paths: github.com/openbao/openbao/api/v2 at version 2.6.0 from 22 June 2026, and github.com/openbao/openbao/sdk/v2 at version 2.6.2 from 22 July 2026. The numbering of the three modules does not track the server's numbering.

The same registry still carries retracted versions, a whole list of them. The go.mod file contains the directive retract [v0.1.0, v1.17.0], which invalidates every number inherited from Vault. The proxy cache still lists those versions, from v0.1.0 through v1.15.5, even though the corresponding tags have been deleted from the repository and fetching any of them fails with an unknown revision error. Check this before a dependency audit, because the module's version list looks as though OpenBao once shipped a 1.15.5, which it never did.

There is no license field in this registry at all: the go.mod format has no such field. A metadata collector therefore has to read the file rather than the registry.

The third source is the content of the published package. The archive of module github.com/openbao/openbao/api/v2 at version 2.6.0, fetched from the proxy, contains 70 files, including 57 .go files and 423762 bytes of unpacked content in total, so there is real code in there, not just a description. The archive holds a LICENSE file of 15958 bytes, exactly the same size as the file in the repository root, with the same content, from the HashiCorp notice to the MPL 2.0 text. The api/ directory in the repository has no such file, so it lands in the archive through the Go module mechanism, which pulls in the nearest enclosing licence file.

# third source: what is actually inside the published package
curl -sO https://proxy.golang.org/github.com/openbao/openbao/api/v2/@v/v2.6.0.zip
unzip -l v2.6.0.zip | grep -i license
unzip -p v2.6.0.zip 'github.com/openbao/openbao/api/v2@v2.6.0/LICENSE' | head -3

What this means for a company. MPL 2.0 is file-level copyleft. You can run OpenBao in production, offer it to customers as a hosted service, compete with anyone, sell support and keep your own code closed. If you modify files covered by the licence, those files must be made available under MPL 2.0. There is no user-count threshold, no revenue threshold, no change date and no vendor approval. The project's answers page states plainly that there are no plans to change the source code licence, and points to the MPL 2.0 patent provision as the reason for choosing it.

One more thing to know before a first pull request. The CONTRIBUTING.md file has a section on the policy towards source-available code: it prohibits copying from any source covered by a source-available licence, including Business Source License 1.1, and names every repository in the HashiCorp GitHub organisation. Work on feature parity has to be done using a clean room methodology. On top of that there is a mandatory DCO sign-off and a warning to disable all generative coding assistants while working on OpenBao.

What happened to Vault

Vault today is under Business Source License 1.1, and it looks different from other projects on that licence. With SurrealDB the BSL parameters are set separately for each version. Here there is one blanket entry.

The discrepancy in the Licensor row is real and checkable: the licence file at the tag of the latest release names HashiCorp, and the file on the main branch names IBM. The licensor rename landed on the branch after 2.0.4 was cut. If you maintain a register of dependency licences, record the version from the tag you actually use.

The Licensed Work field reads "Vault Version 1.15.0 or later", so it covers everything from 1.15.0 upward in a single sentence, without per-release parameters. The Change Date is phrased as a rule rather than a date: four years from that version's publication. Every release therefore converts to MPL 2.0 on its own anniversary. Vault 1.15.0 shipped on 27 September 2023, so it becomes MPL 2.0 code on 27 September 2027, a little over a year from today. Release 2.0.4, published on 4 August 2026, converts only in August 2030.

The Additional Use Grant is the parameter that actually decides whether you may use Vault. It permits production use provided your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with Vault's paid versions. The licence text defines its own terms. A competitive offering is a product offered to third parties on a paid basis, including through paid support arrangements, whose capabilities significantly overlap with those of the paid versions of Vault. There is a protective clause: if your product was not a competitive offering when it first became generally available, it does not become one later merely because Vault gained new capabilities. Products not provided on a paid basis are not competitive by definition. Embedded means including the source or executable code in a competitive offering, and also packaging that offering such that Vault must be accessed or downloaded for it to operate. Hosting or using Vault for internal purposes within an organisation is not a competitive offering, and the organisation is taken to include all affiliates under common control.

There is no user-count threshold and no revenue threshold here. The boundary is the type of use, not the scale. A bank with twenty thousand employees can run Vault internally with no licensing at all. A two-person company selling hosted Vault with paid support cannot. The licence itself refers you to the vendor's answers page for binding interpretive guidance, so borderline cases are not a solo reading exercise.

Beyond the Additional Use Grant, the general BSL 1.1 terms apply: you may copy, modify, create derivative works, redistribute and make non-production use. Production use comes solely from that one paragraph.

Policy, client and data compatibility

The project has a written compatibility policy, ratified on 8 February 2024, which splits the problem into three layers. That is a better starting point than asking "can I switch".

The layers are hierarchical: seal compatibility implies storage compatibility, which implies API compatibility. The 2.0.0 release note says OpenBao is fully API compatible with Vault 1.14.9 and seal compatible for the plugins the project supports. Access policies remain the same path-based format, so policy files carry over without rewriting.

Clients are a different matter, and here comes the first trap. Environment variables were renamed from the VAULT_ prefix to BAO_. The file api/client.go at version 2.6.0 contains not a single reference to a VAULT_-prefixed variable, and the command documentation lists only BAO_ variants. A curiosity for anyone reading the code: the Go identifiers are still named EnvVaultAddress, EnvVaultToken and so on, only the values changed.

# client configuration moves to the BAO_ prefix
export BAO_ADDR=https://bao.example.com:8200
export BAO_TOKEN=s.xxxxxxxxxxxxxxxx
export BAO_NAMESPACE=platform-team
export BAO_CACERT=/etc/openbao/ca.pem
export BAO_CLIENT_TIMEOUT=60s
bao status

The Go library import changes along with the module path: instead of github.com/hashicorp/vault/api you take github.com/openbao/openbao/api/v2. That means your own integrations need recompiling, not just an address swap.

Data and the installation itself are the most demanding layer. The project publishes an in-place migration guide and states plainly what it was tested against: Vault version 1.14.1 in the community edition, OpenBao 2.2.0, Raft storage and a Shamir seal, that is, without auto-unseal. The limitations are spelled out. If your Vault is older than 1.14.1, upgrade it to 1.14.1 first. If it is 1.15.0 or newer, this guide will not work. If Vault was bootstrapped on a version older than 1.3, you will probably need to rekey the instance, because that Shamir implementation has been removed from OpenBao.

Two further changes need planning before the switch. The token format differs: OpenBao issues tokens shaped as [sbr].<random>, while Vault uses longer ones prefixed hvs, hvb and hvr. Old tokens are honoured to the end of their time to live, but new ones have a different shape, so consumers validating token format with a regular expression will break quietly. The second change is disable_mlock: OpenBao has not used mlock since version 2.0.0, and leaving the option in the configuration is an error. If you use the file audit device, the log file has to be handed to the user OpenBao runs as, after Vault is stopped.

# Raft cluster migration: followers first, the leader last
systemctl stop vault && systemctl start openbao
bao operator raft join https://vault-03.example.com:8200
bao operator unseal
bao operator raft list-peers   # wait until the Voter column reads true

Built-in and external plugins

The biggest functional difference is not in the core but in what ships inside the binary. The file helper/builtinplugins/registry.go in Vault 1.14.8 lists 55 plugin names, some of them carrying a deprecated or removed status. The same file in OpenBao 2.6.2 lists 25 names.

Note one entry Vault does not have: valkey-database-plugin. OpenBao ships separate plugins for Redis and for Valkey, which sounds familiar after the history of that other fork. Support for PostgreSQL stayed in the binary, both as a dynamic credentials engine and as a storage backend.

What left the binary did not leave the project. The openbao/openbao-plugins repository provides external plugins run as separate processes talking over gRPC: authentication through AWS, Azure, GCP and GitHub, secret engines for AWS, Azure, GCP, GCPKMS, Nomad and Consul, a MongoDB database driver, and six auto-unseal plugins including AliCloud KMS, AWS KMS, Azure Key Vault, Google Cloud KMS, OCI KMS and OVHcloud KMS. The plugin system distinguishes four types: secret, auth, database and kms. Declarative plugins are registered in the server configuration file and can be pulled from an OCI registry, while the API-driven plugin catalogue supports every type except kms, since that one is needed before unsealing.

The cost of this arrangement is obvious: what was a single secrets enable aws under Vault is now a job for whoever maintains the deployment. The gain is equally obvious: a smaller binary and a plugin release cycle decoupled from the server.

What OpenBao added after the fork

Release 2.0.0 brought no great novelties, because it served to stabilise the fork, shrink the binary and publish artefact signatures. It did not even have a graphical interface, which returned only later. The one larger feature was paginated lists: LIST requests accept optional after and limit parameters, which caps response size over large key sets.

The pace picked up afterwards. Among the things in the 2.x branch that Vault 1.14 did not have: transactional storage in Raft, namespaces, recursive listing, declarative configuration, XChaCha20-Poly1305 keys in the transit engine, soft deletion of keys in transit, a choice of key export format through format=der or format=pem, the token_strictly_bind_ip parameter binding a token to the request's source address, and the removal of mlock from the core.

Release 2.6.0 from 14 July 2026 added four things worth naming. Namespace sealing allows an additional Shamir seal and a scoped barrier keyring to be built when a namespace is created, so a tenant can revoke the instance operator's access to their namespace by sealing it, without touching the others. The new kms plugin type in the configuration file pushes auto-unseal mechanisms out into external binaries. Workflows under sys/workflows let an operator compose multi-request flows spanning different plugins. There is also a container image variant based on distroless, in which the only executable is OpenBao itself, plus authenticated sys/generate-root-token endpoints replacing the older unauthenticated ones. The project reports 42 first-time contributors in this release.

Announcements for 2.7.0 cover control groups with a human in the loop approving operations, external keys as a redesign of the enterprise managed keys, and horizontal scaling on PostgreSQL. Those are announcements, not shipped code.

Where to get OpenBao

The binary is called bao, or bao.exe on Windows, and it is the only file needed to run a server. Installation through package managers covers Homebrew on macOS, pkg on FreeBSD, pacman on Arch Linux together with separate plugin packages, and EPEL for Fedora and RHEL. The project also maintains packages for Amazon Linux, Debian, Fedora, RHEL and Ubuntu, available through its own repositories and for direct download.

# Arch Linux, together with the list of available plugins
pacman -Sy openbao
pacman -Ss ^openbao-plugin

# Fedora and RHEL through EPEL
dnf install -y epel-release
dnf install -y openbao

# container image, three registries to choose from
podman pull ghcr.io/openbao/openbao
podman pull quay.io/openbao/openbao
podman pull docker.io/openbao/openbao

Container images are published to three registries at once, which helps if your internal policy rules one of them out. The base variant is built on Alpine Linux, the openbao-ubi variant on RHEL UBI, and since 2.6.0 there is a distroless variant. For Kubernetes there is a Helm chart.

The downloads and ecosystem pages on the project site do not render without JavaScript: the raw HTML contains only a message about fetching release information from GitHub, so the file and adopter lists cannot be read from them at the command line. Among confirmed production deployments, the project blog names the adoption of OpenBao as the secret store for EdgeX Foundry and a talk about its use at GitLab. There was no confirmation that any major cloud provider offers a managed OpenBao service, so treat that as a gap rather than a fact in either direction.

If you are assembling a platform yourself, OpenBao sits alongside the rest of the operational layer without surprises: TLS termination through Traefik or Caddy, while injecting secrets into applications launched by Coolify needs a step of your own, because such panels have no native OpenBao integration.

Common mistakes

First: assuming VAULT_ADDR and VAULT_TOKEN will work. They will not. The bao client reads only BAO_-prefixed variables, so operational scripts need reviewing before the migration, not after.

Second: planning a migration on the assumption that the aws, azure or gcp engines are in the binary. They are not. They have to be registered as external plugins, which means extra binaries to distribute and an extra step in the server configuration.

Third: attempting an in-place migration from Vault 1.15.0 or newer. The documentation says outright that the guide does not cover it. The realistic path is moving secrets through the API, or staying on Vault.

Fourth: leaving disable_mlock in the configuration file. OpenBao has not used mlock since 2.0.0 and that option is a configuration error, not an ignored leftover.

Fifth: go get github.com/openbao/openbao in the hope of getting version 2.6.2. The main server module has no /v2 suffix, so the proxy refuses and returns a pseudo-version. Client libraries come from the api/v2 and sdk/v2 paths.

Sixth: the belief that you can stay on Vault 1.14.8 because it is the last MPL release. Formally yes, practically no: that is a December 2023 release with no further security fixes, and a secrets manager is the last component where sitting on two-year-old code pays off.

Seventh: reading the BSL as a ban on commercial use. Vault's Additional Use Grant permits production and internal company use at no charge. The line is drawn at selling Vault to third parties as a hosted or embedded offering.

When OpenBao is not worth it

If your deployment rests on Vault Enterprise features, OpenBao will not reproduce them. The 2.0.0 release note says so plainly, and the compatibility policy explains why: replication, seal wrapping and some engine features cannot be reproduced without reverse engineering, which the project forbade itself through its own clean room policy.

If you need a support contract with an enforceable response time, an OpenSSF sandbox project will not give you one. The funding model is community and member-company work, not a contract.

If your tooling around secrets assumes Vault by name, expect friction. Some Kubernetes operators, continuous delivery plugins and infrastructure-as-code modules reference Vault's addresses, variables and plugin names. API compatibility helps but does not remove the work of reviewing integrations one by one.

And finally something easy to forget while comparing features: OpenBao's production deployment base is still smaller than Vault's, and there are correspondingly fewer write-ups, incident reports and ready answers for unusual problems. For a component that can stop an entire platform, that is a real cost.

FAQ

Is OpenBao free for commercial use?

Yes, without qualification. MPL 2.0 has no user-count threshold, no revenue threshold, no change date and no competitive offering clause. You can sell hosted OpenBao. The only obligation appears when you modify covered files: those files go out under MPL 2.0.

Which Vault version did OpenBao come from?

From the code a few commits after the 1.14.8 release, before 1.14.9 was cut, at the commit with short hash 8993802. That is the last state before the 1.14.x branch moved to the BSL. You can check it by comparing the LICENSE file in the hashicorp/vault repository at tags v1.14.8 and v1.14.9.

Will my Vault policies and clients work unchanged?

Policies yes, they are the same path-based format. Clients not quite: environment variables use the BAO_ prefix instead of VAULT_, and the Go library has a different import path. Calling the API itself is compatible at the level declared for Vault 1.14.9.

Can I migrate an existing cluster without moving secrets by hand?

You can, but within a narrow window: the in-place migration guide was tested on Vault 1.14.1 with Raft storage and a Shamir seal, and it explicitly does not apply to Vault 1.15.0 and newer. Outside that window, moving secrets through the API is what remains.

When does Vault become open licensed code again?

Each version separately, four years from its own publication, converting to MPL 2.0. Vault 1.15.0 from 27 September 2023 converts on 27 September 2027. Release 2.0.4 from August 2026 only in August 2030.

Does OpenBao have every plugin Vault has?

No. The binary carries 25 plugin names against 55 in Vault 1.14.8. Cloud engines, consul, nomad and most database drivers have to be installed as external plugins from the openbao/openbao-plugins repository.