Learn Secret Management - Fork History, Linux Foundation Manifesto & Why Choose OpenBao

#Introduction

In episode 0 you set up your environment: the bao CLI is installed, the dev-mode server is running, and BAO_ADDR and BAO_TOKEN are ready to use. Episode 1 addresses one question that is rarely answered thoroughly: where does OpenBao come from, and why do hundreds of DevOps teams choose it?

The answer is not just about features. OpenBao was born from an event that changed the direction of the secret management industry: HashiCorp's decision to change Vault's license from open source to a more restrictive one. This episode will walk you through that story, help you understand the OpenBao manifesto under the Linux Foundation, and then weigh whether OpenBao is really the right choice for your needs.

#The Beginning: HashiCorp Vault's License Change

For years, HashiCorp Vault was the de-facto standard for secret management under the MPL-2.0 license, which the OSI recognizes as open source. But in 2023, HashiCorp announced a major change: its products, including Vault, would no longer use a traditional open source license, switching instead to the Business Source License (BSL/BUSL).

This change sparked long discussions within the community. Technically, BSL still allows you to read and modify the code, but commercial use is restricted — Vault could no longer be considered 100 percent open source. For teams that had long built infrastructure on Vault and relied on its open source license, this change signaled that control over the product's future lay in the hands of a single vendor.

#December 2023: The Fork is Born Under the Linux Foundation

The community responded quickly. In December 2023, a fork of Vault was born under the name OpenBao, and it quickly found a neutral home: the Linux Foundation through the LF Projects umbrella.

Why does the Linux Foundation umbrella matter? Because the Linux Foundation is a non-profit organization that stewards hundreds of major open source projects. By joining LF Projects, OpenBao gained:

• Neutral governance — no single company controls the direction of development.
• A clear community structure — contributors from various organizations have an equal voice.
• License certainty — the code stays in the community's hands forever.

This fork is not just a copy of the code: OpenBao inherited Vault's entire codebase at the last still-open-source version, then continued development at its own pace and with the community's own priorities.

#OpenBao's Commitments

The OpenBao manifesto can be summarized in three main commitments.

#100% Truly Open Source (MPL-2.0)

All of OpenBao's code is released under the MPL-2.0 license — the same license Vault used before moving to BSL, still recognized by the OSI as open source. This means:

• The code can be read, modified, and distributed.
• Companies can use it commercially without license fees.
• No features are locked behind an enterprise edition.

#Transparent, Community-Based Governance

Unlike the vendor-driven model, OpenBao is community-managed: change proposals are discussed openly, decision-making involves contributors, and the roadmap is prioritized based on real user needs — not the commercial interests of a single company.

#No Hidden Paid Features

Ever heard the term open-core? That model offers a free version with limited features, then locks the important features behind a paid edition. OpenBao rejects that model — features like auto-unseal, dynamic secrets, and replication are available in the community release with no hidden price tag.

#Backward Compatibility with Vault 1.15.x

The most common question: "Is OpenBao compatible with the Vault already running in our production?" The answer is yes — with a version caveat. OpenBao is designed to be 1:1 backward compatible with HashiCorp Vault versions 1.15.x and below:

• REST API endpoints /v1/... remain the same.
• Configuration file format still uses HCL.
• Every vault CLI command can be mapped one-to-one to bao.

Because of this, teams migrating do not need to rewrite their integrations. You can even use alias vault=bao and most legacy pipelines will run without meaningful changes — we will cover full migration in episode 18.

bao version
bao status

bao status will show server information such as version and seal status. If both commands run without errors, the episode 0 environment is ready to host all of this episode's practice.

#Why Choose OpenBao?

Let's go through one by one the reasons that make OpenBao attractive to Security, DevOps, and Backend teams.

#Centralized Secret Storage

All secrets — passwords, API keys, tokens, certificates — are stored in one central, encrypted location. No more secrets scattered across .env, configuration files, or repositories. One point of control means one point of audit.

#Dynamic Secrets

This is one of the most revolutionary features. Instead of storing static passwords that remain valid for years, OpenBao creates on-demand credentials with a short lifetime that are then revoked automatically. If they leak, their lifetime has already passed before they could be misused. You will practice this in episode 4 with dynamic database credentials.

#Transit Encryption-as-a-Service

OpenBao can act as the encryption engine for your applications: send it data, OpenBao returns ciphertext, and vice versa — without ever storing the data itself. Ideal for protecting sensitive data such as national ID numbers or card numbers. Covered in depth in episode 5.

#PKI Engine

OpenBao can act as an internal Certificate Authority, automatically issuing TLS certificates with short TTLs. No more subscribing to public CAs for internal services. This material awaits you in episode 6.

#Auto-Unseal

With cloud KMS integration, an OpenBao server can unseal itself on boot, without human intervention. This solves one of the biggest operational problems in production, and will be discussed in episodes 2 and 16.

#Zero Vendor Lock-in

Because the code and license belong to the community, you are not dependent on any vendor's roadmap or pricing policy. That is a guarantee of long-term investment.

#OpenBao vs Vault vs Other Alternatives

To clarify OpenBao's position, let's compare it with commonly used alternatives:

From this table you can see: OpenBao offers Vault-equivalent — even greater — capabilities, but with a fully open source license and no vendor ties. Cloud secrets managers are convenient, but they bind you to a single ecosystem. Kubernetes Secrets are practical, but they do not provide at-rest encryption, dynamic credentials, or comparable lifecycle management.

#Conclusion

In this episode 1, you learned about OpenBao's journey from its response to HashiCorp Vault's license change, its birth in December 2023 under the Linux Foundation, its commitment to MPL-2.0 open source with community governance, its 1:1 compatibility with Vault 1.15.x, and the technical reasons to choose OpenBao for secret management.

Key takeaways:

• OpenBao was born from a community decision — Vault's license change to BSL triggered the fork in December 2023.
• MPL-2.0 and the Linux Foundation guarantee that OpenBao stays 100 percent open source and community-managed.
• Compatible with Vault 1.15.x and below — existing integrations do not need to be rewritten.
• The core features Vault brought remain intact — centralized storage, dynamic secrets, transit, PKI, and auto-unseal.

In the next episode, episode 2, we dive into OpenBao's deepest layers: core architecture and initialization operations — how storage backends like Raft work, what the barrier engine is, how Shamir secret sharing works with unseal keys, the bao operator init process, manual unsealing, auto-unseal, and best practices for managing the root token. Make sure your dev-mode server is running, because we are going to practice initialization for the first time!