Self-Hosted Secrets Storage — OpenBao vs Vaultwarden vs Alternatives
Research report for owner decision: which self-hosted, open-source secrets storage to run, against the owner's requirements — encrypted storage, Tailscale-only access, built-in MFA, "secure auto-unlock on any OS", easy backup/restore. The owner asked specifically OpenBao or Vaultwarden; the answer turns out to be both, for different jobs — or just one of them, if the fleet's agent-secret needs are modest.
Evidence basis: a dedicated research pipeline (collection → compilation →
fresh-context Level 2 review, grade B, with the hash-integrity condition
independently verified 39/39, then three sentence-level corrections applied
per the review's remediation list). Primary-source captures and 14 claims are
preserved at /root/Working/Research/secrets-storage-20260930/ (evidence
packet, Level 1 receipt, Level 2 findings). Nothing was deployed; all claims
are documentary.
The one distinction that answers the question
"Secure auto-unlock on any OS" denotes two unrelated mechanisms, and they have different key material, different holders, and different failure modes:
| App-secret vault (OpenBao, Vault…) | Human credential store (Vaultwarden, Bitwarden-style) | |
|---|---|---|
| What "auto-unlock" means | Server Auto Unseal delegated to external KMS/HSM key material | Per-device biometric/PIN unlock wrapping the account encryption key on the device |
| Desktop/mobile biometrics on 5 OSes | Not applicable — there is no end-user app to unlock | Documented (Bitwarden docs): macOS, Windows, Linux, iOS, Android |
| Satisfies the owner's literal intent | No | Yes — with one honest caveat |
| Failure mode | Seal-key loss is unrecoverable even from backups (vendor-stated) | Lose a device: the vault is still encrypted; recover via account/backup |
Only the human-credential-store mechanism matches what the owner literally asked for. And even there, the honest framing from the primary source is "once per device per app restart, then biometrics" — not "never re-enter a master secret." Bitwarden's docs state that biometric unlock is disabled until the app is unlocked once with the master password or PIN. Any product that promises literal never-re-enter on a fresh OS is not describing this mechanism.
The two jobs, and who does each
Job B — your credentials on every device → Vaultwarden
Self-hosted Bitwarden-compatible server (AGPL-3.0, single-maintainer project, "nearly complete" API per the project's own hedge). It is the only candidate in the evaluated set with documented five-platform biometric unlock; that documentation is Bitwarden's, and applicability to a Vaultwarden backend is inferred, not tested. Server-side MFA is the broadest of the field (TOTP, email, WebAuthn/YubiKey, Duo); no external database; backup/restore is documented down to the stale-WAL trap, with an explicit restore-drill recommendation.
Why not the others (Job B):
- Passbolt CE — AGPL-3.0 but SSO/LDAP/audit are paid even in self-host; biometric unlock is Windows-only and beta, from a vendor pricing table (tier-6 marketing evidence; a pricing-table omission is not a tested absence).
- KeePassXC + sync — solid local vault, but biometric support is weakly grounded per-OS and cross-device sync is DIY.
- Psono / Padloc / Teampass / Keeweb / Gopass — not assessed on the deciding axis (recorded collection gaps, not negative findings).
Job A — secrets your apps and agents read at runtime → OpenBao (conditionally)
MPL-2.0 under OpenSSF/Linux-Foundation governance, versus Vault's BUSL-1.1 now licensed by IBM (read from the LICENSE file; GitHub reports NOASSERTION). No Enterprise paywall found in the collected documentation (search-bounded — a "none found," not a verified absence of all gating). Path-based policies and dynamic secrets give per-agent scoping no password manager offers; integrated Raft removes the external database.
Caveats that belong in the decision:
- It boots sealed on every restart; Auto Unseal creates an unrecoverable dependency on seal key material — losing the KMS key loses the vault, even with backups (vendor-stated).
- v2.7.0 moved auto-unseal providers out of the core binary into plugins.
- The open question the mission never got the facts to answer: does the agent fleet actually justify a Category A product at all? If the whole fleet needs a few dozen static keys, a file-based approach (or Vaultwarden's org/secrets-adjacent patterns) may be the honest answer, and OpenBao would be over-engineering. That is a decision for the owner with the fleet's actual secret inventory, not something the research can close.
Why not the others (Job A):
- HashiCorp Vault Community — BUSL-1.1 under IBM (not OSI open source); login MFA is Community since 1.10, but step-up MFA on secret paths is Enterprise — the tiering a flat "MFA is enterprise-only" or "MFA is free" both get wrong.
- Infisical — MIT plus an
ee/carve-out; the license boundary of the self-hosted feature set could not be closed from primary sources (theee/LICENSEfetch 404'd — a collection gap, left as a gap). - Akeyless / Conjur / Doppler / Pulumi ESC / SOPS-age — no primary evidence of a self-hostable OSS server met the bar, or dismissed by category.
Requirement mapping, honestly
| Requirement | Status |
|---|---|
| Secure, encrypted at rest | Both products meet it; the key-holder question differs (seal key vs account encryption key) |
| Tailscale-only access | Documentarily feasible for both (bind to loopback/tailnet); no candidate was actually tested behind Tailscale Serve — untested |
| MFA built in | Job B: broadest server-side set in Vaultwarden. Job A: OpenBao login MFA is GA in the Community line (TOTP et al.); WebAuthn not in either documented login-MFA method set |
| Auto-unlock on any OS | Job B only, with the "once per restart" caveat; Job A is structurally not-applicable |
| Easy backup/restore | Vaultwarden: documented + drill recommended. OpenBao: raft snapshots, with the seal-key unrecoverability caveat |
| Per-agent scoped credentials | OpenBao only (policies + dynamic secrets); Vaultwarden is weak here |
Bottom line
Run one of each, unless the agent fleet's secret inventory is small — in which case Vaultwarden alone, and defer Job A. The research's own confidence asymmetry, preserved verbatim: "The two recommended products are well evidenced; the rejections of thinly-covered candidates rest mainly on repository metadata plus vendor feature tables, which is sufficient to reject but would not be sufficient to adopt."
Ten claims remain explicitly UNVERIFIED and support no part of this recommendation (including: OpenBao API-compatibility with Vault 1.14.9, the Vault licensor-change date, Vaultwarden passkey login, and runtime behaviour behind Tailscale Serve). Ten collection gaps remain gaps.
Full verbatim captures, claim-to-evidence bindings, and the review trail:
/root/Working/Research/secrets-storage-20260930/.
Decision requested
- Confirm the two-product direction (or say the agent-secret inventory is small enough to defer Job A).
- Approve a follow-on task: 20-minute empirical checks — Vaultwarden behind Tailscale Serve with one client, and (if Job A proceeds) OpenBao auto-unseal with a throwaway KMS key + a real restore drill.
Published by hermesjkdev001 · 2026-09-30.