OpenBao: Open-Source Secrets Management

What OpenBao is

OpenBao is software for managing, storing, and distributing sensitive data: secrets, certificates, and keys. Its documentation describes it as an identity-based secrets and encryption management system, where a secret is anything you want to tightly control access to, such as API tokens, passwords, encryption keys, and certificates. Clients reach it through a UI, a CLI (the binary is bao), or an HTTP API.

The problem it targets is credential sprawl. A modern system needs database credentials, API keys for external services, and credentials for service-to-service communication. Knowing who is accessing which secret is hard and platform-specific, and adding key rolling, secure storage, and detailed audit logs on top is, in the README's words, almost impossible without a custom solution. OpenBao centralizes those credentials, requires every user, app, and machine to authenticate and be explicitly authorized, and keeps an audit trail of what clients did.

The project's stated intent is to provide this software under an OSI-approved open-source license, led by a community run under open-governance principles. Its security disclosure address and community channels sit under the OpenSSF, and the README shows OpenSSF Scorecard and Best Practices badges.

How it works

OpenBao works primarily with tokens, and every token is tied to a policy. Policies are path-based: each rule constrains which operations a client may perform on which API paths. The documented workflow has four stages:

1. Authenticate: the client presents information OpenBao can use to identify it.
2. Validate: OpenBao checks that information against a trusted source such as GitHub, LDAP, or AppRole, then issues a token bound to a policy.
3. Authorize: the client's requests are matched against that policy, which declaratively grants or denies access to paths and operations.
4. Access: OpenBao serves secrets, keys, and encryption operations according to the policy, and the client uses its token for further calls.

Functionality is organized as plugins: secrets engines, auth methods, and audit devices. Storage is pluggable as well. The README names disk and PostgreSQL; the changelog documents Raft integrated storage, a PostgreSQL backend that gained horizontal read scalability in 2.7.0, and a new PebbleDB backend, while the older file backend was removed in 2.7.0. OpenBao Agent and Proxy are documented companions for client-side use.

Key features

• Secure secret storage: arbitrary key/value secrets are encrypted before being written to persistent storage, so access to the raw storage alone does not expose them.
• Dynamic secrets: OpenBao can generate credentials on demand for systems such as AWS, Kubernetes, or SQL databases, and revokes them automatically when their lease ends.
• Data encryption: encrypt and decrypt data without storing it, so developers can keep ciphertext in their own databases without designing their own cryptography.
• Leasing and renewal: every secret has a lease; clients renew through built-in APIs, and expired leases are revoked.
• Revocation: revoke single secrets or whole trees, such as everything read by one user or every secret of one type, which helps with key rolling and intrusion response.
• Namespaces: tenant isolation, which the changelog describes as API-compatible with the upstream implementation, plus per-namespace Shamir sealing.
• PKI and Transit engines: certificate issuance and encryption as a service; 2.7.0 added ML-DSA post-quantum signatures to both and support for keys held in external KMS or HSM via plugins.
• Post-quantum TLS options: 2.7.0 lets operators require pure post-quantum key exchange on listeners.
• Control groups: a policy stanza requiring a second party to approve requests for a path, added in 2.7.0.
• OCI-distributed plugins: plugins can be pulled and pinned by image digest.

Getting started

The install docs list Homebrew, FreeBSD packages, Linux packages (including Arch Linux and EPEL), container images on GHCR, Quay, and Docker Hub in Alpine and RHEL UBI variants, precompiled zip binaries, and a Helm chart for Kubernetes. On macOS:

$ brew info openbao
$ brew install openbao

On Fedora or RHEL with EPEL enabled:

$ dnf install -y openbao

Verify the binary is on your path:

$ bao -h

To build from source and run a development server, the README gives:

$ mkdir -p bin
$ go build -o bin/bao .

$ go run . server -dev # Or `./bin/bao server -dev` if you've built the binary already.

Dev mode is for local experimentation only. For production, follow the server configuration reference, and the install guide's post-installation hardening section, which covers disabling memory paging (swap) so secrets are not written to disk by the operating system.

Use cases

• Replacing hardcoded credentials: move database passwords and API keys out of config files and source code into one audited store.
• Short-lived cloud and database credentials: let applications request credentials when they start and have them revoked automatically when the lease expires.
• Internal certificate authority: run PKI for service TLS, including ACME-based issuance.
• Application-level encryption: use the Transit engine so services encrypt fields before storing them, with key rotation handled centrally.
• Multi-tenant platforms: isolate teams or customers with namespaces.
• Kubernetes workloads: deploy via Helm and authenticate pods using the Kubernetes auth method.

How it compares

OpenBao's changelog makes its lineage clear: the 2.0.0 release retracted all prior Vault versions of the core, API, and SDK modules, restored some features "from upstream", fixed compatibility with pre-built Vault plugins, and kept HTTP headers such as X-Vault-Request. In practice that means teams familiar with HashiCorp Vault will recognize the concepts, paths, and many APIs, but OpenBao has diverged since: it removed Vault Enterprise-only stubs, moved several seals and auth methods into external plugins, and added features on its own schedule. Check the documentation for each engine you depend on rather than assuming parity. Compared with cloud-provider secret managers, OpenBao is self-hosted and cloud-neutral, with the operational responsibility that implies.

Things to know before adopting

• License: MPL-2.0, a file-level copyleft license. You can use and embed it commercially; modifications to MPL-licensed files must be shared under the same license.
• You operate it: unsealing, storage backend choice, high availability, backups, and upgrades are your responsibility.
• Breaking changes in recent releases: 2.7.0 removed the file storage backend, moved the cloud KMS and PKCS#11 seals out of the main binary into external plugins, discontinued the separate HSM distribution, and moved LDAP, Kerberos, and RADIUS engines into openbao-plugins. Read the changelog before upgrading.
• Go module path: the module moved to github.com/openbao/openbao/v2, and only the api/v2 and sdk/v2 packages are supported for import.
• Active security maintenance: the 2.7.1 and 2.6.4 releases on October 1, 2026 both shipped multiple security fixes, so plan for regular patching.

Project activity

As of October 2026 the repository has roughly 8,300 stars. It was created on November 9, 2023, is written in Go, and is licensed under MPL-2.0. The 2.0.0 general availability release landed in July 2024, and the most recent releases at the time of writing are 2.7.1 and 2.6.4, both dated October 1, 2026. The source is at github.com/openbao/openbao, and documentation is at openbao.org. Community discussion runs through GitHub Discussions, an OpenSSF mailing list, and Zulip channels with working groups for namespaces, PKCS#11, scalability, supply chain, and the UI.