In August 2023, HashiCorp changed the license on Vault, the tool most of the industry had quietly standardized on for storing API keys, database credentials, and encryption keys. Vault moved from the permissive Mozilla Public License to the Business Source License, a shift that didn’t break anything for most existing users overnight, but did put a fork in the road for anyone building a product on top of it, redistributing it, or simply uncomfortable with a dependency whose terms could change again later at the vendor’s discretion.

OpenBao is the community’s answer to that fork in the road. It’s a full, independent continuation of Vault’s open-source codebase, governed in the open, licensed permissively, and built by many of the same engineers who worked on Vault before the license changed. If you’ve used Vault before, OpenBao will feel almost identical on day one. The differences that matter are underneath: who governs the project, what license it ships under, and which features Vault reserves for its paid Enterprise tier that OpenBao gives away for free.

This guide covers what OpenBao actually is, the licensing story that led to its creation, how its architecture works, what it can do out of the box, and how it stacks up against Vault today.

Why OpenBao Exists: The Licensing Backstory

Understanding OpenBao means understanding the event that created it, since the project’s entire identity is built around a licensing decision it exists to route around.

(cite index=”5-1″>As of 2026, Vault’s open-source edition operates under the Business Source License 1.1. This license permits you to use, copy, modify, and redistribute Vault, including in production, under most circumstances. The key restriction is that you cannot offer Vault as a hosted or embedded service that competes directly with HashiCorp’s paid commercial offerings, and after four years from each release date, the code converts to the MPL 2.0 license. That delayed-open-sourcing model, sometimes called a “fair source” or “source available” approach, is common among infrastructure vendors trying to fund development while still publishing their code. It’s also, by design, not an OSI-approved open-source license, which matters a great deal to organizations with procurement policies that require OSI-approved licensing for anything they depend on.

(cite index=”9-1″>Shortly after HashiCorp’s license change, the community forked Vault’s last MPL version, creating OpenBao as an open-source project under MPL 2.0 licensing. (cite index=”10-1″>The project shares Vault’s API, command surface, secrets engines, and auth methods, and for the large majority of self-hosted secrets workloads, you would struggle to tell them apart in normal operation.

(cite index=”15-1″>IBM engineers initiated the project, though IBM has not made it an official corporate product, an interesting wrinkle given that (cite index=”10-1″>HashiCorp itself was subsequently acquired by IBM, meaning IBM now has engineers touching both the commercial original and the open-source fork that exists specifically because of a licensing decision HashiCorp made before that acquisition. (cite index=”15-1″>The OpenBao community on GitHub has accumulated over 5,400 stars and 333 forks, and the project is actively maintained, with commits landing regularly.

What Is OpenBao?

(cite index=”1-1″>OpenBao is an open source, community-driven fork of HashiCorp Vault managed by the Linux Foundation, used to manage, store, and distribute sensitive data. (cite index=”1-1″>Arbitrary key/value secrets can be stored in it, and OpenBao encrypts these secrets before writing them to persistent storage, so gaining access to the raw storage alone is not enough to access your secrets.

(cite index=”1-1″>OpenBao can also generate secrets on-demand for systems like Kubernetes or SQL databases, and after creating these dynamic secrets, it automatically revokes them once the lease expires. That’s a meaningfully different security posture than the alternative most teams start with, secrets sitting in a .env file or a CI/CD variable that nobody remembers to rotate.

(cite index=”2-1″>More precisely, OpenBao is an identity-based secrets and encryption management system, providing secure storage, fine-grained access control, and lifecycle management for secrets such as API or SSH keys, passwords, certificates, and encryption keys. Governance sits with the Linux Foundation rather than any single company, which is the structural guarantee meant to prevent a repeat of the situation that created the project in the first place, no single vendor can unilaterally relicense OpenBao out from under the people depending on it.

How OpenBao Works

(cite index=”2-1″>The core OpenBao workflow runs through four stages. Authentication verifies the identity of the client and, once verified, issues a token associated with a policy. Validation checks whether the client actually has the permissions being requested. Authorization grants or denies access to specific paths and operations based on that policy. Access then limits what the client can actually do with the secret once authorized. Every secret read, write, or generation request passes through that same pipeline, regardless of which secrets engine or auth method is involved.

The Barrier, Seal, and Unseal

The most distinctive architectural concept in OpenBao, inherited directly from Vault, is the barrier.

(cite index=”11-1″>OpenBao’s encryption layer, called the barrier, is responsible for encrypting and decrypting all OpenBao data. When the server writes data to its storage backend, that backend sits outside the barrier and is considered untrusted, so OpenBao encrypts everything before sending it there. This ensures that even if an attacker gains access to the raw storage backend, the data remains unreadable until OpenBao itself decrypts it.

(cite index=”11-1″>When an OpenBao server starts, it begins in a sealed state, and before any operation can be performed, it must be unsealed by providing the unseal keys generated during initialization. (cite index=”13-1″>Prior to unsealing, almost no operations are possible, authentication, managing mount tables, none of it works until the plaintext root key needed to decrypt the data has been reconstructed.

(cite index=”11-1″>By default, this uses Shamir’s Secret Sharing technique, splitting the root key into multiple shares with a configurable threshold required to reconstruct it, though Shamir’s technique can be disabled in favor of using the root key directly. (cite index=”11-1″>Once OpenBao retrieves the encryption key and decrypts the storage backend’s data, it enters the unsealed state and loads its configured audit devices, auth methods, and secrets engines.

Manually gathering key shares from separate operators every time a server restarts doesn’t scale for most production teams, which is why auto-unseal exists. (cite index=”11-1″>The default configuration uses a Shamir seal, but OpenBao can also be auto-unsealed by a trusted cloud key management system or hardware security module, removing the manual step entirely while still keeping the barrier’s protection intact. (cite index=”13-1″>Seal migration between types is supported, including migrating from Shamir to an auto-unseal method, or between different auto-unseal providers, with some specific limitations depending on the source and destination seal types.

Storage Backends

OpenBao doesn’t store secrets in a database of its own design, it delegates that to a pluggable storage backend, always through the encrypted barrier described above. (cite index=”17-1″>OpenBao supports various physical storage backends through a plugin-like architecture, with integrated Raft (a built-in, no-external-dependency clustering option) and PostgreSQL among the commonly used choices for production deployments requiring high availability.

Core Features

OpenBao’s feature set breaks down into a few clear categories, and understanding them separately makes it much easier to reason about what to actually use for a given problem.

Static secrets. (cite index=”7-1″>Static secrets are provisioned by users directly and securely stored, the straightforward key-value case: an API key, a webhook secret, a config value that shouldn’t live in plaintext anywhere. The KV secrets engine, available in both version 1 and version 2, handles this, with version 2 adding built-in versioning so you can see and roll back to previous values.

Dynamic secrets. (cite index=”7-1″>Dynamic secrets are automatically generated on-demand to integrate with systems like databases or cloud provider identities. Instead of a database password that sits static for months, an application requests a credential from OpenBao, gets one generated on the spot with a defined lease, and that credential simply stops working once the lease expires or gets explicitly revoked. If a credential leaks, the blast radius is bounded by how long the lease had left, not indefinite.

Encryption as a service. (cite index=”7-1″>Encryption services support PKI or SSH certificate creation and KMS-like encryption-as-a-service functionality. This is what the Transit secrets engine provides: applications send OpenBao plaintext to encrypt or ciphertext to decrypt, without ever handling or storing the actual encryption keys themselves. It’s a useful pattern for teams that want centralized key management without rewriting every application’s cryptography by hand.

PKI and certificate management. OpenBao can act as a certificate authority, issuing and managing the lifecycle of X.509 certificates for internal services, which is particularly useful for teams doing mutual TLS between services without standing up a separate CA infrastructure.

SSH secrets engine. Similar in spirit to dynamic database credentials, OpenBao can issue short-lived SSH credentials or sign SSH certificates on demand, reducing reliance on static SSH keys distributed across a fleet of engineers and servers.

Authentication methods. (cite index=”4-1″>For core functionality, OpenBao is broadly API-compatible with Vault across Kubernetes auth, AppRole auth, AWS auth, and GCP auth, with CLI commands and API paths following the same conventions as Vault OSS for commonly used workflows. In practice, this means workloads authenticate using whatever identity mechanism already exists in their environment, a Kubernetes service account, an AWS IAM role, a JWT from an OIDC provider, rather than a separate OpenBao-specific credential you have to manage on top of everything else.

Namespaces: OpenBao’s Biggest Differentiator

If there’s one feature that gets brought up more than any other when people explain why they chose OpenBao over Vault OSS, it’s namespaces.

(cite index=”15-1″>Namespaces, the feature that enables multi-tenancy and workload isolation between teams, are included in OpenBao’s free, open-source version, while HashiCorp reserves the equivalent capability for Vault Enterprise. (cite index=”16-1″>The project has added features of its own beyond what it inherited from Vault, including open-source namespaces for multi-tenancy, which remain an enterprise-only feature in Vault.

In practice, namespaces let a platform team run one OpenBao cluster and give each internal team, or each customer in a multi-tenant SaaS product, its own isolated slice: separate policies, separate secrets engines, separate auth methods, all without needing entirely separate infrastructure or without any tenant seeing another tenant’s configuration. For organizations that would otherwise need Vault Enterprise purely to get this capability, it’s often the single deciding factor in evaluating OpenBao.

The isolation goes deeper than logical separation, too. (cite index=”12-1″>A proposed enhancement called Per-Namespace Sealing would let tenants seal and unseal their own namespace independently, without affecting other tenants’ data availability, and give each namespace its own encryption keys rather than relying on the operator’s shared cryptographic implementation. Whether or not that specific feature has landed by the time you’re reading this, it’s illustrative of the direction the project is heading: treating namespace isolation as a first-class security boundary, not just an organizational convenience.

OpenBao vs. HashiCorp Vault: A Direct Comparison

(cite index=”10-1″>HashiCorp reserves its most advanced capabilities for Vault Enterprise, including performance and disaster-recovery replication, hardware security module integrations, and namespaces for multi-tenancy. OpenBao’s community has been building toward parity on several of these, but you should not assume an exact match, if your architecture depends on a specific Enterprise feature, verify OpenBao’s current support for it directly rather than treating the fork as feature-complete.

The support and ecosystem picture is worth being equally honest about. (cite index=”10-1″>Vault has the largest ecosystem in the category and first-party commercial support from HashiCorp and IBM, along with HCP managed options, though the hosted roadmap has been in flux post-acquisition, so it’s worth confirming current availability directly before depending on it. OpenBao’s support model is community-driven, with IBM engineers involved as contributors rather than as an official vendor standing behind commercial SLAs the way HashiCorp does for Vault.

Deployment Options

OpenBao runs the same way Vault does operationally, which is part of the point. You can run it as a single binary on a Linux server, inside a container, or through a Kubernetes operator for teams already standardized on Helm-based deployments. High availability is handled through the storage backend, integrated Raft removes the need for a separate coordination service entirely, while backends like PostgreSQL rely on the database’s own locking mechanisms for leader election.

For a first evaluation, OpenBao also supports a dev-mode server that starts pre-unsealed with in-memory storage, useful for kicking the tires locally before committing to a real production deployment:

bao server -dev

That single command gets you a running instance with a root token printed to the console, enough to start experimenting with the CLI immediately:

export BAO_ADDR='http://127.0.0.1:8200'
bao kv put secret/myapp/config username=admin password=changeme
bao kv get secret/myapp/config

Dev mode is explicitly not meant for anything beyond local testing, since data doesn’t persist across restarts and the server starts unsealed with no real access controls in place. For anything real, you’d move to a proper production configuration with a persistent storage backend, TLS termination, and an actual seal mechanism.

Migrating From Vault

Because OpenBao forked directly from Vault’s codebase at a specific version, migration for most common workflows is closer to a rename than a rebuild. (cite index=”4-1″>For core functionality including KV v1/v2, PKI, database dynamic secrets, Kubernetes auth, AppRole auth, AWS auth, and GCP auth, OpenBao is broadly API-compatible with Vault, and CLI commands and API paths follow the same conventions as Vault OSS for commonly used workflows.

That said, “broadly compatible” isn’t the same as “guaranteed identical.” (cite index=”16-1″>Because it forked from Vault, OpenBao remains API-compatible at the level of its core authentication methods, such as JWT/OIDC, and its dynamic secrets engines, but compatibility for any specific workflow should be verified in practice rather than assumed, particularly for niche secrets engines, plugins from HashiCorp’s ecosystem that may not have an OpenBao equivalent, and anything touching Vault Enterprise-only features that don’t have a direct match on the open-source side.

The practical migration path most teams follow is: stand up OpenBao alongside the existing Vault deployment, replicate secrets and policies over, cut over auth methods and applications incrementally, and keep the old Vault instance available as a fallback until the new one has proven itself under real traffic. Treat it with the same caution you’d apply to migrating any other stateful, security-critical system, because that’s exactly what it is.

OpenBao and the Rest of Your Security Stack

Secrets management solves a specific problem: keeping credentials, keys, and certificates out of source code and config files, with lifecycle management around them. It’s a different layer from identity and access management for human users, and a different layer again from infrastructure access control. If you’re also looking at how engineers actually reach production servers, databases, and Kubernetes clusters day to day, that’s a separate but related problem, and our guide to Teleport in DevOps covers the certificate-based access model that tends to sit alongside a tool like OpenBao rather than replace it. OpenBao secures what your applications and services hold. Teleport secures how your engineers reach the infrastructure those applications run on. Most mature security stacks end up running both, for different halves of the same underlying problem: getting rid of long-lived, static credentials wherever they’re hiding.

Who Should Use OpenBao?

OpenBao tends to be the right fit for teams that:

• Want Vault’s exact operational model and feature set without the BSL licensing terms attached to it.
• Have an internal policy requiring OSI-approved open-source licensing for infrastructure dependencies.
• Need namespace-based multi-tenancy but don’t want to pay for Vault Enterprise purely to get it.
• Are comfortable with a community-governed project rather than a single vendor’s commercial roadmap and support contract.
• Are already running Vault and evaluating a lower-risk exit path in case licensing terms shift again down the line.

It’s a less obvious fit if you’re specifically depending on a Vault Enterprise-only feature like performance replication or a particular HSM integration that OpenBao hasn’t reached parity on yet, or if you need first-party vendor support with contractual SLAs rather than community-driven maintenance.

Frequently Asked Questions

Is OpenBao free to use? Yes, entirely. OpenBao is licensed under MPL 2.0, a permissive, OSI-approved open-source license with no paid tier gating core functionality, unlike Vault, which reserves several capabilities for its commercial Enterprise edition.

Is OpenBao a drop-in replacement for HashiCorp Vault? For most common workflows, yes, since it forked directly from Vault’s codebase and remains broadly API-compatible for KV secrets, PKI, dynamic database credentials, and common auth methods like Kubernetes, AppRole, AWS, and GCP. Less common plugins or Enterprise-only features should be verified individually rather than assumed to carry over.

Who governs OpenBao? The Linux Foundation, rather than any single company. IBM engineers were involved in initiating the project and remain active contributors, but IBM has not made OpenBao an official corporate product, and the intent behind Linux Foundation governance is specifically to prevent the kind of unilateral relicensing decision that led to OpenBao’s creation in the first place.

What does “sealed” mean in OpenBao? A sealed OpenBao server cannot perform almost any operation, including authentication, until it’s unsealed by reconstructing the root encryption key from unseal key shares (or through an auto-unseal integration with a cloud KMS or HSM). It’s the mechanism that keeps data unreadable even if someone gains raw access to the storage backend.

Does OpenBao support namespaces like Vault Enterprise? Yes, and this is one of OpenBao’s most significant differentiators. Namespaces for multi-tenancy are included in OpenBao’s free, open-source edition, while the equivalent capability is restricted to Vault’s paid Enterprise tier.

Can I run OpenBao in production today? Yes. As of early 2026, the project has reached version 2.5.0, is under active Linux Foundation governance, and is described by independent reviewers as production-ready rather than an early-stage experiment.

What’s the difference between static and dynamic secrets in OpenBao? Static secrets are values you store and retrieve directly, like an API key. Dynamic secrets are generated on-demand by OpenBao itself, for example a database credential created fresh for a specific request and automatically revoked once its lease expires, which limits how long a leaked credential remains usable.

Does switching from Vault to OpenBao require rewriting my application code? Usually not for common integrations, since the CLI commands and API paths follow the same conventions for the most widely used secrets engines and auth methods. It’s still worth testing thoroughly rather than assuming a seamless cutover, particularly around less common plugins or Enterprise-specific functionality.

Final Thoughts

OpenBao exists because a licensing decision made the open-source status of a tool a huge number of companies had already built critical infrastructure around suddenly uncertain. Its answer wasn’t to build something new from scratch, it was to fork the last truly open version of Vault and keep developing it in the open, under governance structurally designed to prevent the same situation from happening again.

For teams already comfortable with Vault’s model, barrier and seal, dynamic secrets, pluggable auth methods, OpenBao offers the same operational experience with a license that doesn’t come with an asterisk, plus a few genuine improvements like free namespaces that Vault reserves for paying customers. Whether that’s worth a migration depends entirely on how much your team currently depends on Vault Enterprise-specific features and how much weight your organization puts on OSI-approved open-source licensing as a procurement requirement.

For the authoritative reference on every configuration option and secrets engine covered here, OpenBao’s official documentation is the best place to go deeper.

For more breakdowns of open-source infrastructure and DevOps security tooling like this one, keep exploring the guides on CourseDrill.