OpenBao
| License | FOSS problems | Maintenance | SSO | Users | Tested |
|---|---|---|---|---|---|
| MPL-2.0Copyleft license. Only the covered files must stay open — surrounding proprietary code in separate files is permitted. | — | Active | ✅ | Unlimited | ❌ |
Description
OpenBao is an open-source secrets management platform, forked from HashiCorp Vault's last MPL-licensed release before Vault moved to the Business Source License — the same fork story OpenTofu has with Terraform. Governed by a Linux Foundation Technical Steering Committee, not any single company.
Features
- Dynamic secrets — generated on demand and expiring on their own, rather than static credentials created once and left indefinitely.
- SSH secrets engine — acts as a certificate authority, issuing short-lived, signed SSH certificates per connection instead of distributing static keypairs. Servers trust the CA's public key once (
TrustedUserCAKeys); access itself becomes an issuance event with a built-in expiry, not a standing credential. - Transit encryption — encryption-as-a-service for application data, without the app itself ever holding the key.
- Multiple CA issuers per mount — rotating the signing CA itself doesn't require a hard cutover.
- Self-hostable — deployable via Docker or a single binary; also where the same risk this catalog already flags for Infisical applies — self-hosting the thing that holds the keys to everything else means its own backup and recovery has to be solved separately.
Usage patterns
- SSH access, replacing static keys — see Walkthrough → Security → Security architecture for the actual gap this would close: a server-management key shared across multiple machines gives its holder the same reach everywhere it's authorized, regardless of what any UI-level permission model (Coolify's Teams, for instance) shows. An SSH CA makes each connection its own short-lived grant instead of a standing key.
- Secrets injection — the same subprocess-environment shape
pass-cliand Infisical's CLI already use; adopting it wouldn't change how provisioning tooling authenticates, just which tool backs it.
License and governance
MPL-2.0, OSI-approved, no commercial restrictions — the license Vault itself shipped under before HashiCorp's 2023 BSL change. Hosted under the Linux Foundation and OpenSSF, governed by a Technical Steering Committee rather than one vendor; the project can't be relicensed without community consensus. IBM engineers are among the key contributors, alongside the broader community that forked it.
Conclusion
Why you would — the SSH certificate authority is the specific capability nothing else in this catalog offers: replacing static, indefinitely-valid SSH keys with short-lived certificates issued per connection, closing the gap where a shared key's actual reach exceeds what any dashboard-level permission suggests.
Why you wouldn't — genuinely new operational surface for what's currently a single-server setup: running, unsealing, and backing up a secrets engine is real infrastructure to maintain, and whatever host it runs on still needs its own durable, non-delegated way in — OpenBao's dynamism doesn't remove that one root of trust, just relocates it. Worth adopting once there's more than one server to actually issue certificates for, not before.