OpenBao: leases, revocation and a vault symlink in the image

The container image still symlinks vault to bao

The Dockerfile starts with a copyright line naming HashiCorp, Inc. and the SPDX identifier MPL-2.0, and then installs a compatibility symlink:

COPY LICENSE /licenses/mozilla.txt
RUN addgroup openbao && adduser -S -G openbao openbao
RUN ln -s /usr/bin/bao /usr/bin/vault

That symlink is there so existing tooling that expects a `vault` binary keeps working, and it is the most visible trace of this project's lineage. `go.mod` carries the same history in a comment, noting that the vault module is not intended to be imported into other projects. The README itself does not describe the relationship to HashiCorp Vault at all.

So if your question is whether this is a fork, the repository answers it indirectly rather than in prose. The default container flavour is `alpine:3.24.3` pinned by digest, the binary is copied into a `scratch` stage with `--chmod=555` so that one release binary produces an identical layer across image flavours, and the server is started as a non-root user with `dumb-init` and `su-exec` present.

Importing OpenBao itself is explicitly not supported

The repository publishes two libraries for other projects to consume: `github.com/openbao/openbao/api/v2` and `github.com/openbao/openbao/sdk/v2`. Those are the supported entry points.

Then it says what is not supported, in unusually direct language. The presence of `go.mod` makes it theoretically possible to import OpenBao, the application, as a dependency, and some projects have done so to reuse its testing tooling. That is NOT, and has NEVER been, a supported way to use the project. The maintainers state they will not fix bugs relating to a failed import of `github.com/openbao/openbao` into your project, and will not refactor internal code to make that easier.

This is the single most useful paragraph in the README for an integrator. A Go module system will happily resolve the server package, the build will succeed, and you get an unsupported configuration with no upstream commitment to fix it.

Every secret has a lease, and revocation works on a tree

The feature list is short, and two of its entries are the same idea seen from two sides. Leasing and renewal: all secrets in OpenBao have a lease associated with them, and at the end of that lease OpenBao automatically revokes the secret, with clients able to renew through built-in renew APIs. Revocation: OpenBao can revoke not only single secrets but a tree of secrets, for example all secrets read by a specific user, or all secrets of a particular type.

Read together, that is the architecture. Expiry is the default state of every credential, renewal is an explicit client action, and a revocation can cover a tree of secrets rather than a single key. Revocation assists in key rolling and in locking down systems after an intrusion, which is the scenario the whole design serves.

The storage story is the baseline underneath it. Secrets are encrypted before being written to persistent storage, so gaining access to the raw storage is not enough to read them, and the backends include disk and PostgreSQL.

Dynamic secrets are generated on request and revoked when the lease ends

Dynamic secrets are the feature that changes an application's credential handling. OpenBao can generate secrets on demand for some systems, such as AWS or SQL databases. The example given: when an application needs access to an S3 bucket, it asks OpenBao for credentials, and OpenBao generates an AWS keypair with valid permissions on demand. After creating those dynamic secrets, OpenBao automatically revokes them once the lease is up.

The important word is valid. The generated credential is scoped to what was asked for, which means the permission model of your cloud account now runs through OpenBao's policy layer rather than through a long-lived key held in an environment variable.

The cost is a dependency on renewal. An application that does not renew its lease loses access on a timer, by design, and any outage between the application and OpenBao becomes an outage of that application's credentials rather than a degraded service. Dynamic secrets remove the credential sprawl problem and replace it with an availability requirement.

Encryption without storage is a separate feature from the secret store

The fourth feature is not about storing secrets at all. Data Encryption: OpenBao can encrypt and decrypt data without storing it. The stated use is that security teams define the encryption parameters while developers store the resulting encrypted data somewhere such as a SQL database, without designing their own encryption methods.

This is the answer to whether OpenBao can act as a key management service, and it is a narrower one than the word KMS suggests to some buyers. The service never holds the data; it holds the ability to transform it. That design is what lets ciphertext live in a database the security team does not administer.

It also separates the audit story from the secret-store story. The README's problem statement mentions detailed audit logs as one of the things that is almost impossible without a custom solution, alongside key rolling and secure storage, and this feature is where the same service can encrypt data it never stores.

Building and running locally takes three commands and a pinned toolchain

The development instructions assume Go is installed, and pin the version used in CI and releases to `.go-version`, while saying the latest local toolchain is typically fine. The repository uses Go modules, so it recommends cloning outside the GOPATH.

Building the binary is two lines:

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

and running a development server, either from source or from what you just built:

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

The README warns that this is a large codebase that takes a while to compile from a cold cache and suggests attaching `-v` to build commands to see progress. Testing one package is `go test ./some/package`, and a Makefile exists for advanced build configurations. The repository also holds the website and the web UI application in the `website` and `ui` subtrees, each with its own README.

Two releases on the same afternoon, and a 45-minute test budget

The release record is worth reading closely. v2.7.1 shipped on 2026-10-01, and then two releases landed on 2026-10-26 about a minute apart: v2.6.5 at 20:23 and v2.7.2 at 20:24 (UTC). A patch on the previous minor line and a patch on the current line on the same day is the signature of a project that maintains more than one supported series.

The build system agrees with that. The Makefile sets a default test timeout of 45 minutes, 60 minutes for extended runs and 120 minutes for integration tests, pins protoc at 34.0, sets `CGO_ENABLED` to 0 by default and reads the minimum Go version from `.go-version`.

Around that sits the governance. The community intends to provide the software under an OSI-approved open-source licence led by open-governance principles, with `CHARTER.md`, `GOVERNANCE.md`, `MAINTAINERS.md` and `CODEOWNERS` in the repository, working groups on Zulip for namespaces, pkcs11, scalability, supply chain and UI, and a responsible disclosure address at [email protected]. The last push was on 2026-11-02 and the repository is not archived.

Editorial conclusion

Adopt OpenBao if you want secrets with expiry and revocation rather than a static credential store, and if your platform already runs Go and containers. Do not import the server into your own project: the README says that path is not supported and never has been. Before deploying, read the feature list against your own threat model, pin a release tag, and note that two releases shipped on the same day in October 2026, so the maintenance line you choose matters.

Frequently asked questions

Official sources

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