OpenBao over Vault — same docs, more freedom
I would still pick Vault if I were running infrastructure for a bank. I'm not running infrastructure for a bank.
In my homelab and across everything I run personally on cjoga.cloud, the secrets engine is OpenBao, not HashiCorp Vault. Three replicas in the openbao namespace, fronted by External Secrets Operator, backing every workload on the cluster that needs a credential. I picked it deliberately, I know the trade-offs, and I would still pick Vault if I were running infrastructure for a bank. I'm not running infrastructure for a bank.
The background is short and well documented. HashiCorp moved Vault from MPL 2.0 to the Business Source License in 2023. OpenBao is the Linux Foundation-backed fork that continues the project under MPL 2.0. The fork is real, the maintainers are real, the release cadence is real, and the upstream momentum is enough that for the operational surface I care about it tracks Vault closely. I'm not here to litigate whether HashiCorp's call was right or wrong — they made a business decision, that's their prerogative. What matters to me is what that decision implies for anyone betting their stack on the product downstream.
The reason OSS preference matters for personal infrastructure is not ideological, it's risk management. When you build on a vendor's product you are implicitly trusting that the rules under which you adopted it will not change. Past behavior across the industry tells us those rules do change — pricing tiers shift, license terms tighten, features move behind enterprise editions, the free version stops getting the good updates. For something as foundational as secrets storage, where every workload in the cluster has a dependency on the thing, I want governance that removes that class of risk. A project under a foundation, under a permissive OSS license, with a community of maintainers, doesn't have a single board that can change the terms on me next quarter. That's the bet.
The compatibility argument is the part that makes the choice cheap. OpenBao is a fork of the same code. The API surface is the same, the CLI ergonomics are the same, most of the documentation still applies one-to-one. If I read a Vault tutorial from 2022 about KV v2, auth methods, or policy syntax, it works on OpenBao. My External Secrets Operator config doesn't know the difference. The Terraform provider works. The Helm chart works. Same docs, same product, more freedom — that is genuinely the trade I'm making, and the migration cost for current features is close to zero because for current features it isn't actually different software.
Where Vault still wins is at enterprise scale, and I want to be honest about that. The supported product comes with a support contract, an SLA, a roadmap funded by a vendor with real engineering muscle behind it, HSM integrations, advanced replication topologies, namespaces, performance standby nodes, the long tail of features that exist precisely because Fortune 500 customers paid for them. If I were running a regulated financial platform with auditors who want a vendor name on the support contract, I would write the check and run Vault. That is what the commercial product is for, and pretending otherwise would be dishonest.
The disclaimer I owe anyone reading this: OpenBao is younger as a project than Vault is. Some enterprise features lag, some integrations may not exist yet, and the support model is community-based — meaning when something breaks you read the source and the issue tracker, not a support contract. For a homelab and personal infrastructure, that's fine. It's actually part of the appeal. For regulated production with compliance gates on your back, weigh it honestly against what a supported product gives you, and don't let OSS preference make the decision for you.
The proof point that running OpenBao in a lab has its own operational realities is the sibling entry on OpenBao auto-unseal, where I went with a static-key seal because cloud KMS and the other auto-unseal back-ends are the wrong abstraction for a self-contained lab. That's the discipline I try to keep: pick the tool for the context you're actually in, name the trade-offs out loud, and don't pretend the choice was free.