mrkeyoor.com_
Fri 25 Sept 15:55 UTC
Self-Hostedevaluationupdated 25 Sept 2026

openbao review

OpenBao is a self-hosted service for storing secrets, issuing short-lived credentials, managing certificates, and encrypting data through an API. It gives operators one place to control access and revocation instead of leaving permanent credentials in application configuration.

Verdict

Our OpenBao build succeeded in 294 seconds, but its test run stopped at the 900-second cap with 41 of 47 results passing. That makes it a serious candidate for teams willing to test the exact storage, plugin, and upgrade path they will run, especially those avoiding Vault's non-OSI server license. Do not treat the easy development server as evidence that production recovery will be easy.

We ran it

Lab card: what happened when we ran openbaoScreenshot of openbao (openbao.org)
Install✓ · 75s684 packages
Build✓ · 294s
Tests✗ timed out · 900s41 passed · 6 failed of 47 (go test)
Repo5385 files~646,504 lines of source · 75.9 MB · 18 CI workflows · Dockerfile

Answers from our run

Does openbao build from source?

Dependencies installed in 75 seconds (684 packages), and the build succeeded in 294 seconds. We cloned commit a87e809 into a clean Debian container with 3 CPUs and no project-specific setup.

Do openbao's tests pass?

Not all of them: 41 of 47 passed and 6 failed when we ran the project's own test command (go test). Some failures need services or credentials a bare container does not have.

Who should not use openbao?

Teams looking for a low-maintenance password vault: OpenBao is infrastructure, and production use still needs storage, initialization, access policy, and operational recovery.

What are the alternatives to openbao?

HashiCorp Vault, Infisical, Conjur. Our OpenBao build succeeded in 294 seconds, but its test run stopped at the 900-second cap with 41 of 47 results passing.

Setup2/5Build passed, but 6 of 47 test results failed before timeout
Docs4/5Clear concepts and dev start; production detail lives off README
Community5/57,552 stars, 18 workflows, and issue activity on September 25
Maturity4/5Broad secrets feature set, with active migration and package bugs

Who it’s for

Platform teams replacing HashiCorp Vault or choosing a secrets server with an OSI-approved license.
Operators who need dynamic database or cloud credentials with leases and revocation.
Security teams prepared to own storage, unsealing, policies, audit logs, backups, and upgrades.
Go developers who need the supported OpenBao API or SDK libraries.

Who it’s NOT for

Teams looking for a low-maintenance password vault: OpenBao is infrastructure, and production use still needs storage, initialization, access policy, and operational recovery.
Operators expecting the v2.7.0 Debian package to start from its supplied configuration: open issue 4077 reports that it names the removed file storage backend.
Namespace users migrating from file storage without a tested rollback: open issue 3921 reports a second-boot panic after migration on both Raft and PostgreSQL.
Contributors who need to import the whole server as a Go dependency: the README supports only the API and SDK modules and explicitly declines support for importing the application.

Setup reality

Our sandbox installed 684 Go packages in 75 seconds and built OpenBao in 294 seconds. The test command hit the 900-second cap with 41 passed and 6 failed out of 47. The log tail shows several packages with no test files and several passing packages, but it does not identify a single cause for the unfinished run.

Development mode is one command after compilation. A useful deployment still needs a persistent storage choice, initialization and unsealing, TLS, policies, and client authentication. External KMS or HSM use in v2.7.0 may also require a plugin.

This is a 5,385-file Go repository with about 646,504 source lines and a 75.9 MB checkout. The project has a Dockerfile and 18 CI workflow files, but a full local test pass did not fit inside our 15-minute limit.

OpenBao v2.7.0 is a secrets server, not a password manager

OpenBao v2.7.0 stores arbitrary secrets, issues temporary credentials, manages certificates, and performs encryption through an API. Applications can request a database or cloud credential, receive a lease, renew it when appropriate, and let the server revoke it later. That is a different job from keeping a shared team password list. OpenBao sits in the request path for machine credentials, so availability, policy mistakes, and recovery procedures affect the systems that depend on it.

The strongest reason to choose it is control. The server uses the MPL-2.0 license and the project describes community governance under the OpenSSF. Teams coming from Vault will recognize the model, while the current code publishes supported API and SDK modules at version 2. The README draws a firm boundary around those libraries: importing the entire OpenBao application as a Go dependency is unsupported.

Our build passed in 294 seconds, while the tests exceeded 900 seconds

Our sandbox installed 684 Go packages in 75 seconds and completed the build in 294 seconds. The checkout at commit a87e809 contained 5,385 files, about 646,504 lines of source, and occupied 75.9 MB before dependencies. That is a substantial security product rather than a small daemon. A cold build is long enough to matter in ephemeral development environments and CI jobs.

The test command timed out at 900 seconds with 41 passed and 6 failed out of 47. Its final lines list several helper packages with no test files and successful results for logical, time, user-agent, and version helpers. The tail does not expose one common failure or prove that the six failures share a cause. Our test method therefore supports a narrow conclusion: this commit built, but the complete command did not pass inside a 15-minute run.

Development takes 1 command; production needs an operating model

After compilation, the README starts a development server with 1 command. That path is useful for learning the API, yet it omits the decisions that make a secrets service trustworthy: persistent storage, initialization, unseal or recovery material, TLS, authentication, policy design, audit handling, backups, and a restore drill. OpenBao can reduce credential sprawl only if somebody owns those parts after the first successful request.

Version 2.7.0 widens the production surface. Its release adds external keys for PKI and Transit, post-quantum signature support, consistency controls, PostgreSQL read scaling, and a PebbleDB backend. Several former built-ins, including LDAP and Kerberos components and some KMS seals, moved to external plugins. Existing operators should read the change list as migration work, since a new feature and a packaging change can affect the same restart.

The v2.7.0 package can ship a configuration that will not start

Open issue 4077 reports a concrete v2.7.0 failure: the Debian package supplies a configuration using file storage after that server backend was removed. The reporter reproduced the resulting unknown storage type file startup error on 2 Proxmox hosts. A pull request was already discussing a replacement configuration on September 25, which is evidence of active response, but a fresh package user still needs to inspect the shipped HCL before enabling the service.

Storage migration deserves a separate rehearsal. Open issue 3921 reports that v2.6.0 and v2.6.2 can migrate the root namespace from file storage while leaving child namespace tables in the old format. In that report, the first boot succeeds and the second boot panics on both Raft and PostgreSQL. The report concerns a specific namespace migration, not every upgrade, but its timing makes a simple start-and-health-check acceptance test inadequate. Restart the restored copy before approving a migration.

Eighteen CI workflows show activity, not a guarantee for your cluster

The repository had 18 CI workflow files, a Dockerfile, 7,552 stars, and 321 open issues and pull requests when fetched on September 25, 2026. Its last push was September 24, one day after the v2.7.0 release. Issue 2581 is updated daily with flaky tests seen in CI, and recent pull requests address the new storage defaults. Those dates show an active project and an active defect queue at the same time.

The v2.7.0 notes contain 9 security entries, covering request-header enforcement, plugin execution boundaries, policy evaluation, namespace isolation, audit logging, and PKI behavior. That release cadence is encouraging for a security-sensitive service, but it also makes prompt patch review part of ownership. OpenBao is the better bet when open governance and license terms are decisive and your team can practice restores. If you mainly need a friendly place to sync application secrets, compare Infisical before accepting this operational load.

Alternatives

ProjectWhat it isPick it when
HashiCorp Vault gh↗The upstream product family from which OpenBao originated, with a large integration catalog and commercial editions.pick this instead when vendor support or an existing Vault estate matters more than an OSI-approved server license.
Infisical gh↗A secrets platform with developer-facing workflows, application integrations, and a web interface.pick this instead when the team values an application-secret workflow and polished UI over OpenBao's Vault-compatible operating model.
ConjurA policy-based secrets service aimed at machine identities and controlled credential access.pick this instead when CyberArk integration and Conjur policy are already part of your security program.

What people are saying

  1. [github-trending] openbao/openbao

Sources

  1. OpenBao repository and README
  2. OpenBao v2.7.0 release notes
  3. Issue 4077: Debian package uses removed file storage
  4. Issue 3921: child namespace migration panic
  5. Issue 2581: tracked flaky tests

More self-hosted reviews

NewPipe · CFBox · wg-easy · probo · v2ray-core · autobrr · the whole board →