readystack/openbao repository overview

⁠OpenBao

readystack/openbao:v2.7.2-CE-ubuntu24.04-r2

Source, recipe and records

• Source and build recipe: https://readystack.dev/products/openbao/recipe⁠
• Upstream source at this release's pinned commit (v2.7.2): https://github.com/openbao/openbao/tree/9e0a0d3c3504a0a00b45e61355afac5e35c78379⁠
• Product page: https://readystack.dev/products/openbao⁠
• Hermetic Build Kit for this release (free with an account): https://readystack.dev/products/openbao⁠
• Release history (JSON): https://readystack.dev/api/releases/openbao⁠
• Defect record: https://readystack.dev/defects.html?product=openbao⁠
• Today's scan: https://readystack.dev/products/openbao#pp-grade⁠
• Report an issue: https://github.com/ReadyStackFree/readystack/issues/new?template=bug.yml&product=openbao⁠
• Signing key (cosign): https://readystack.dev/keys/cosign.pub⁠

A cosign-signed build of github.com/openbao/openbao v2.7.2 (MPL-2.0 — Linux Foundation OSS fork of HashiCorp Vault), built clean-room from official upstream source by ReadyStack⁠.

⁠Who uses it and why

Who: Platform, security and DevOps teams who need to store, control and audit access to secrets, keys and certificates.

Why: OpenBao is an identity-based secrets and encryption management system. It checks who each client is, hands out only the secrets its policy allows, and keeps detailed audit logs.

Use case: A team's applications keep database passwords in configuration files. With OpenBao each application authenticates, receives only the secrets its policy allows, and can get database credentials generated on demand that are revoked when their lease ends, while every access is recorded.

About the upstream project, written from its own description: https://github.com/openbao/openbao⁠ · https://openbao.org/docs/what-is-openbao/⁠

⁠What you get

Signature, user and attestations below were measured on the published digest sha256:60a3df33c083d4e8b4e92764557d904d933df80c28280ef6f464dcc3b1717ac3 on 2026-10-29.

• Scan scores — we scan every image we publish every day (an SBOM made with syft, vulnerabilities matched with grype, scored with cerodeo-v1, the rubric ce.rodeo published until 2026-10-26) and record each scan with how its score was derived. This release's first and latest scan: https://readystack.dev/products/openbao⁠
• ReadyStack release check — passed at release on 2026-10-28: no fixable critical or high vulnerability (Docker Scout and OSV), a non-root user, SBOM and provenance attached. This is ReadyStack's own test, not a Docker grade; vulnerabilities published since then are in today's result at https://readystack.dev/queue⁠.
• Signed — cosign signature by the ReadyStack release key (fingerprint 04daa92344a52dbc) on this release's index digest sha256:60a3df33c083d4e8b4e92764557d904d933df80c28280ef6f464dcc3b1717ac3; verify with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/openbao:v2.7.2-CE-ubuntu24.04-r2.
• Attestations — An SPDX SBOM and SLSA v1 build provenance are attached to this digest.
• Runs as a non-root user (openbao).
• Built from source by ReadyStack.

⁠Which tag should I pull?

This image follows the ReadyStack release-tag convention:

• The current release is v2.7.2-CE-ubuntu24.04-r2 — the release listed at readystack.dev. Release tags use the pattern <upstream-version>-CE-<base-os>-r<N>; the current one is signed, attested (SBOM + provenance), and is provided under the ReadyStack Agreement⁠.

• Earlier release tags (an older version or revision in the same pattern) are superseded. They stay pullable so existing deployments can pin them, but they are no longer re-graded, and fixes appear only in newer releases: move to the current release. For a superseded release's build kit, ask support.

• Release tags never move, so pulling the same tag again never changes the image. To be offered each new release automatically (a new revision r<N+1>, or a new upstream version), use the ReadyStack Renovate preset: https://readystack.dev/updates.html⁠

• Any tag beginning with internal- is an engineering-pipeline artifact published for build observability. It is unsupported, may change or disappear without notice, and must not be used in production.

# ✓ current release
docker pull readystack/openbao:v2.7.2-CE-ubuntu24.04-r2

# ✗ unsupported (do not pull)
docker pull readystack/openbao:internal-...

This release is signed; verify it with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/openbao:v2.7.2-CE-ubuntu24.04-r2 (the signature is recorded in the public Sigstore transparency log). Support: [email protected]⁠, as set out in the ReadyStack Agreement⁠.

⁠Deployment

Single container, single static Go binary. The image's ENTRYPOINT is bao and its default command is server -config=/openbao/config/openbao.hcl, a configuration shipped in the image: integrated (raft) storage in /openbao/data, a plain-HTTP listener on 0.0.0.0:8200 (tls_disable = true), api_addr http://127.0.0.1:8200⁠ and cluster_addr http://127.0.0.1:8201⁠ (cluster port 8201). The server starts uninitialized and sealed and has no built-in root token: nothing is usable until you initialize it once (bao operator init prints the unseal keys and the initial root token, only that once) and unseal it (bao operator unseal, once per key until the threshold, 3 of 5 by default). Secrets management, KV, dynamic secrets, PKI and transit encryption over the HTTP API on :8200. No SQL database, no sidecar. The web UI is not bundled; the API and the bao CLI are.

docker run -d --name openbao -p 127.0.0.1:8200:8200 -v openbao-data:/openbao/data readystack/openbao:v2.7.2-CE-ubuntu24.04-r2

Starts a persistent OpenBao server with its data in the openbao-data volume. It answers within a few seconds, uninitialized and sealed: initialize it once with docker exec openbao bao operator init (it prints the unseal keys and the root token, only this once) and unseal it with docker exec openbao bao operator unseal '<unseal key>', once per key until the threshold (3 of 5 by default); unseal it again after every restart. Port 8200 is published on 127.0.0.1 only: the listener speaks plain HTTP, and until the server is initialized, anyone who can reach the port can initialize it and receive the root token. The archive ships no Compose file.

⁠The full ReadyStack Hermetic Build Kit

The complete --network=none build kit for this image — plus admin/DB/API handbooks, the build's validation records, and its build provenance records — is a free download for any registered account at readystack.dev/products/openbao⁠. A clean-room rebuild from this release's archive on an egress-blocked host reproduced its linux/amd64 digest sha256:4eafd7bfd952cc01a016796173f74b90d1cd329b8cf8c25f63de5efd0d538696 on 2026-10-28.

— ReadyStack · readystack.dev

⁠Tags no longer offered

These tags are on Docker Hub but ReadyStack does not offer them. They are kept so existing pulls do not break, but they are unsupported and receive no security updates; do not use them in production. Use the current release named on this page.

• v2.5.5-CE-ubuntu24.04-r1 — ran OpenBao as a dev-mode server ('bao server -dev'): in-memory storage, so every secret is lost when the container stops, and a fixed, publicly known root token; withdrawn, never use it; use v2.7.2-CE-ubuntu24.04-r2, which starts sealed, keeps its data in /openbao/data (integrated storage) and has no built-in root token (labelled 2026-10-29)
• v2.5.5-CE-ubuntu24.04-r2 — ran OpenBao as a dev-mode server ('bao server -dev'): in-memory storage, so every secret is lost when the container stops, and a fixed, publicly known root token; withdrawn, never use it; use v2.7.2-CE-ubuntu24.04-r2, which starts sealed, keeps its data in /openbao/data (integrated storage) and has no built-in root token (labelled 2026-10-29)