What is OpenBao?
OpenBao is an open-source secrets manager, and a fork of HashiCorp Vault managed under the Linux Foundation's OpenSSF. It stores the credentials your systems need, hands them out to the right callers, and records who asked for what.
If you already know what Vault does, OpenBao does that, with the same API. If you do not, the more useful place to start is the problem.
The problem a secrets manager solves
Every system holds credentials: database passwords, API keys, certificates, tokens between services. They have to be somewhere. The usual somewheres all fail in the same way.
In a config file in the repository. Now every developer who has ever cloned it has production credentials, and so does anyone who gets the repository later. Removing the file does not remove it from history.
In environment variables set by the deployment. Better, and now they live in the CI system's configuration, visible to whoever can edit a pipeline, and printed by any process that dumps its environment on error.
In a spreadsheet, a password manager, or one engineer's head. Fine at five people. Not fine at fifty, and impossible to answer an auditor with.
The common failure in all three is that a credential, once written down somewhere shared, cannot be un-shared. You cannot tell who has it. You cannot rotate it without finding every copy. When someone leaves, you either rotate everything or accept that they still have it.
A secrets manager makes credentials something applications fetch at runtime rather than something they are given in advance. That single change is what makes the rest possible: access can be checked per request, granted per identity, logged, and revoked.
What it does beyond storing them
- Dynamic credentials. Rather than storing a database password, OpenBao creates one when an application asks, valid for a short window, and removes it after. A credential that exists for an hour cannot leak for a year.
- Encryption as a service. Applications send data to be encrypted and get ciphertext back, without ever holding the key. The key stays where the application cannot lose it.
- PKI. Issuing and renewing internal certificates, which otherwise is a spreadsheet and an annual outage.
- Audit. Every access recorded. This is usually what turns "we should" into "we must", because it is the part a compliance requirement names directly.
Why it exists as a fork
Vault was open source under the MPL. HashiCorp changed the license to the BSL, which is not an open source license. OpenBao was forked from the last MPL version in response, and is now under the Linux Foundation's OpenSSF, with community governance rather than a single vendor.
It keeps API compatibility with Vault, so existing integrations, tooling and workflows continue to work.
For most organizations the practical question is narrower than the licensing philosophy: whether the terms you are on today are the terms you will be on when your usage grows, and who decides that. A foundation-governed project answers that question differently from a single-vendor one. Which answer you prefer is a genuine choice, and the point of this section is that it is a choice, made once, that is expensive to revisit later.
When you need one
- More than a handful of services, where credentials are being passed between systems rather than typed by a person.
- Anything an auditor looks at. "Who could read the production database password, and when did they" is a question with no good answer without this.
- Short-lived infrastructure. Containers and autoscaling groups appear and disappear; baking credentials into images does not survive contact with that.
- Someone left and you had to rotate everything. Once is a lesson.
When you do not, yet
A single application with two credentials does not need this. Your platform's built-in secret storage is a reasonable place to start, and adding a secrets manager before there are secrets to manage is infrastructure for its own sake.
If nobody will own the operational side, it becomes a single point of failure for every service that depends on it, which is worse than the problem it replaced.
What operating it involves
This is the part that separates a proof of concept from something you can depend on.
- Unsealing. The storage is encrypted at rest and has to be unsealed after every restart. How that happens without a human at three in the morning is a design decision, and it is the first one people postpone. See below, because for regulated organizations it is also where the hardware question lands.
- It becomes critical infrastructure. If applications fetch credentials at startup and it is down, nothing starts. High availability stops being optional the moment the second service integrates.
- Backups, and the recovery keys. Backing up the data is not enough; recovery also depends on key material kept somewhere separate, safe, and known to more than one person.
- Policies that stay right. Access is only as good as the policies, and policies accumulate. Without review they drift towards permissive, which is the direction that does not announce itself.
- The audit log is evidence. That means it needs to be shipped somewhere it cannot be edited by whoever the log is about.
Where the keys actually live, and HSMs
For most organizations the unsealing question above is answered in software and that is the end of it. For regulated ones it is not, because the auditor's question is not "is it encrypted" but "where does the key material physically exist, and who could extract it".
That is what a hardware security module answers. An HSM is dedicated hardware that holds key material and performs operations with it without ever handing the key back out. Software can ask it to decrypt something; software cannot ask it for the key.
OpenBao supports this directly: its PKCS#11 seal configures an HSM as the auto-unseal mechanism, and the documentation carries per-vendor guides, including one for the Securosys Primus HSM, which matters here because Securosys is Swiss. An organization that chose OpenBao to keep secrets under Swiss jurisdiction can put the key protecting them in Swiss hardware rather than only in a Swiss data center.
This is one of the clearest places the fork pays for itself. HashiCorp's own documentation states that auto-unseal and seal wrapping for PKCS11 require Vault Enterprise. In OpenBao the same capability is an ordinary seal configuration, on a project with no license fees at all. If an HSM is a compliance requirement for you, that difference is not a rounding error in the comparison; for many organizations it is the whole of it.
Two differences from HashiCorp Vault Enterprise are worth knowing before you plan the migration, and both are documented rather than incidental. OpenBao requires the key material to be created externally before the instance is initialized; it will not create its own. And it supports AEAD-enabled algorithms only, not Encrypt-Then-MAC constructions. Neither is an obstacle, and both are the kind of thing that derails an afternoon if you meet them during the migration instead of before it.
Whether you need any of this is a compliance question rather than a technical one. If nobody has asked where the key lives, software unsealing is fine, and adding an HSM is expense and operational complexity bought for no requirement.
Where VSHN fits
VSHN operates OpenBao on Swiss cloud infrastructure, with the unsealing, availability, backup and audit questions above answered rather than deferred, and migration from HashiCorp Vault where that is what you are moving away from. Our comparison page sets OpenBao against Vault and the alternatives, and the compliance page maps it to CIS Controls.
If you are early enough that the question is still whether you need one at all, that is the conversation worth having first.