OpenBao: Secret Management for Self-Hosted Teams

TL;DR: OpenBao is an MPL-2.0 secret-management project written in Go. It targets the same niche as the long-dominant closed-source incumbent: storing, distributing, and rotating secrets, certificates, and keys. The repository has 8K stars and 590 forks after roughly three years.

What it is

The repository openbao/openbao sits under the openbao Organization and describes itself as “a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys.” That sentence is the right elevator pitch for the project: it is a vault-style tool, open source, written in Go, with project documentation hosted at openbao.org.

Topics listed on the repository are exactly three: go, secret-management, security. That is unusually focused. There are no padding tags aimed at search discoverability; the audience is the audience.

What the data points tell you

• 8,018 stars and 590 forks since the repository was created on 2023-11-09.
• 327 open issues, which is the highest open-issue-to-star ratio in this batch and signals a project that, while popular, still has rough edges the team is working through.
• Topics explicitly listed: go, secret-management, security (three tags, all directly relevant).
• MPL-2.0 license, a deliberately chosen middle path between the permissiveness of MIT and the copyleft of AGPL. MPL-2.0 keeps modifications to the project’s own files open while letting the surrounding application stay proprietary.
• Most recent push 2026-09-24, three days before this post.

The MPL-2.0 license is the data point to dwell on. The choice tells you the project wants to be embedded inside larger products without becoming a viral copyleft fixture inside them. That is a deliberate positioning decision the maintainers made when the repository was created.

How to try it

The on-ramp for a vault-style Go service in 2026 is mostly the same as it was in 2023:

1. Install the OpenBao binary or pull the official container image.
2. Initialize a single-node dev server against a local data directory, with the seal keys written to a separate location.
3. Enable the secret backends your infrastructure uses (KV, database, PKI for certificate issuance).
4. Wire your deployment tooling against the OpenBao HTTP API or one of the SDKs, using short-lived tokens rather than long-lived root tokens.

For teams with production-grade expectations, the next step is unseal automation with the auto-unseal flow backed by a cloud KMS, plus high-availability storage using a Consul or Raft backend.

When to evaluate OpenBao

Pick OpenBao when the team’s compliance posture forbids sending secrets to a hosted control plane, or when the team prefers a project under MPL-2.0 over an MIT/AGPL offering. The license choice matters when the secret manager is going to be re-distributed inside commercial software, and the Go runtime matters when the team already runs its services on Go-native infrastructure.

Skip it when the team is happy with a hosted secret manager and does not need to operate the unseal, audit, and replication surfaces themselves. Self-hosted vault software is not free in practice, even when the source is open source.

Configuration surface

The configuration lives in HCL files for the server side and an HTTP API for runtime operations. Policy files are HCL too, which keeps the secret-management surface consistent with the rest of the Go ecosystem.

Source and Accuracy Notes

• Project page: https://openbao.org/
• Source repository: openbao/openbao (verified via GitHub API html_url)
• License: MPL-2.0 (verified via GitHub API license.spdx_id)
• Stars at time of writing: 8,018