OpenBao: Community-Driven Secrets Management

The governance difference

OpenBao is a community-led fork of HashiCorp Vault, created because Vault moved to a Business Source License incompatible with free and open-source software use. OpenBao operates under the Open Software Security Foundation with active working groups organizing development: the namespaces working group handles isolation and multi-tenancy, the scalability group addresses performance and clustering, the PKCS11 integration group works on hardware security module support, the supply chain security group manages artifact verification and signing, and the UI working group maintains the web interface. The MPL-2.0 license permits any use, including commercial, without vendor restrictions or license enforcement. The last push was 2026-09-28 and recent releases (v2.7.0 in September, v2.6.3 the same day) indicate ongoing maintenance. HashiCorp still controls Vault's direction; OpenBao's community decides its roadmap through transparent governance. The project also maintains public communication channels including a mailing list, GitHub discussions, and Zulip chat with dedicated channels for discussion, support, and technical steering.

How it manages secrets

OpenBao stores secrets in encrypted form before writing to persistent storage (disk, PostgreSQL, Cassandra, or other backends you configure). Its core primitives are leases and revocation. Every secret has a lease duration; when the lease expires, OpenBao automatically revokes it. Dynamic secrets go further: instead of storing a static password, OpenBao generates temporary credentials on demand. Request a database password, and OpenBao asks the database to create a temporary user account with an expiring password, returning that credential to your application. When the lease expires, the account is deleted. This minimizes the blast radius if credentials leak: they work only for the lease duration. Revocation is hierarchical. Revoke all secrets belonging to a user, or all secrets of a type, in a single operation. Encryption is transparent: OpenBao encrypts data at the application level before storage, meaning even if someone dumps your database, the secrets remain encrypted. The repository includes two importable libraries, `github.com/openbao/openbao/api/v2` and `github.com/openbao/openbao/sdk/v2`, for developers building integrations.

Build from Source with Go and Start in Development Mode

OpenBao requires Go 1.27.0 or later (pinned in the `.go-version` file). Clone the repository and build the binary:

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

Start the server in development mode (unencrypted in-memory storage, suitable for testing):

go run . server -dev

For faster iteration, attach the `-v` flag to see compilation progress on cold builds. The Makefile provides convenience targets for build variants: `make dev` for development builds, `make bin` for releasable binaries, and test targets via `make test`. The repository uses Go Modules for dependency management. Development instructions for the web UI and documentation are in `website/README.md` and `ui/README.md`. The project maintains an AUTHORS file and follows a CONTRIBUTING guide that all pull request submitters must read before contributing.

Core features in practice

Secure secret storage lets you store arbitrary key-value data; OpenBao encrypts it before writing to disk. For SSH, OpenBao can sign temporary SSH certificates, issuing a certificate tied to your principal and a specific IP range, valid for minutes or hours. Database secret engines generate temporary database credentials: tell OpenBao how to connect to your MySQL, PostgreSQL, or other database, and it creates users with expiring passwords on demand. The PKI engine acts as a certificate authority, issuing TLS certificates without running a separate CA infrastructure. The data encryption engine lets you encrypt and decrypt data at rest without storing it. All of these emit leases: your application renews the lease before expiration, or the credential is revoked. Audit logging captures every API call, every secret access, and revocation event, providing a detailed record for compliance and incident investigation.

Authentication methods and secret engines

OpenBao supports multiple authentication methods for different architectures. LDAP authentication integrates with directory services. JWT (JSON Web Token) authentication works with external identity providers. Kubernetes authentication binds OpenBao to Kubernetes service accounts for in-cluster access. AppRole provides a role-based authentication mechanism for applications without human identity. Each auth method is configurable and can be disabled or enabled per mount. Secret engines are the plugins that generate or store secrets. Beyond the core engines (database, SSH, PKI, key-value), OpenBao supports AWS, Azure, Google Cloud, and other cloud-specific engines that generate temporary credentials tied to your infrastructure. The learning curve for configuring these correctly is steep; misconfiguration creates security gaps rather than preventing them.

Limitations and cost

OpenBao cannot fully automate secret rotation without external tooling; it revokes at lease end but does not reissue. Cluster setup requires careful configuration of storage backends and communication; this is not a single-command deployment. The server must be highly available (multiple replicas), which adds operational cost. Seal operations (starting after a crash) are manual without integration to a KMS or cloud HSM. Data remains at rest encrypted only if the server performs that encryption; unencrypted storage backends are possible but not recommended. The operational burden of running OpenBao includes monitoring the health of storage backends, managing high availability, and tuning performance as the secret store grows.

Comparing to HashiCorp Vault

OpenBao and Vault share the same API and secret engine architecture because OpenBao is derived from Vault's open-source version. The critical difference is governance and licensing. Vault now requires a license for features like Sentinel policy as code; OpenBao has no license enforcement. Vault's development is controlled by HashiCorp and prioritizes enterprise features; OpenBao's roadmap is decided by its community working groups and reflects community needs. Vault offers commercial support contracts and integrations; OpenBao's support comes through mailing lists, GitHub discussions, and Zulip channels provided by volunteers. Neither is faster or more featureful than the other at the codebase level; they diverge in which features are added next and the governance model under which decisions are made.

Recent Releases and Container Deployment

Recent releases include v2.7.0 (2026-09-23) and v2.6.3 (2026-09-23), indicating active maintenance. The Dockerfile demonstrates container deployment; OpenBao runs as a non-root user (openbao) in the image, with `/openbao/config` as the configuration directory and `/openbao/logs` for audit logs. The binary is compiled to `/usr/bin/bao` in the official image, with a symlink `/usr/bin/vault` for compatibility. The Go codebase is well-tested; a Makefile target runs all test suites including integration tests with configurable timeouts. The project uses a multi-stage Dockerfile build to ensure identical binary layers across different base images (Alpine, UBI, Distroless).

Editorial conclusion

Adopt OpenBao if you manage infrastructure secrets across multiple services and need open governance with no vendor lock-in. It suits teams already familiar with Vault's API and want community leadership instead of corporate stewardship. Verify compatibility with your storage backend (disk, PostgreSQL, Kubernetes) before migration, and budget for operational overhead: the server must be highly available and its data encrypted at rest.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. openbao/openbao on GitHub
3. Project website
4. README
5. Releases