By OpenBao v2.6 landed on August 6 with two features HashiCorp Vault’s open-source tier has never offered: per-namespace sealing and a native workflow engine. If you’ve been watching the Vault-to-OpenBao migration debate from the sidelines, this release gives you something concrete to evaluate — OpenBao is no longer just catching up. It’s diverging.
A Quick Reset on Why OpenBao Exists
When HashiCorp flipped Vault’s license from MPL 2.0 to BSL 1.1 in 2023, a group of IBM engineers forked the last open-source version (1.14.0) and handed it to the Linux Foundation. The result is OpenBao: API-compatible with Vault for the common engines (KV, PKI, database secrets, Kubernetes auth, AppRole), genuinely open-source, and governed by the OpenSSF. Vault keeps getting more expensive — enterprise pricing is up 10–15% per year — while OpenBao ships new features from a growing contributor community.
Per-Namespace Sealing: Cryptographic Tenant Isolation Without Multiple Clusters
The biggest addition in v2.6 is sealable namespaces. Until now, if you ran a multi-tenant platform and needed to guarantee that Team A’s secrets couldn’t be read by Team B’s administrators — or by the platform operator — your only real answer was to spin up separate Vault clusters. That’s expensive, operationally painful, and doesn’t scale.
Sealable namespaces flip that model. When you create a namespace with sealing enabled, it gets its own keyring and root key, completely separate from the global barrier keyring. The platform operator can hold the cluster’s global root key all they want — it won’t decrypt a sealed namespace’s data. And if a tenant suspects their namespace key is compromised, they can seal and rekey in isolation without touching anyone else’s data.
There’s one significant caveat: only Shamir seals are supported right now. Auto-unseal (cloud KMS, HSM) isn’t implemented yet. That’s real friction for teams running OpenBao on cloud infrastructure. The OpenBao team has it on the roadmap — check the sealable namespaces documentation for current status before building production workflows around this feature.
The Workflow Engine: Kill Your Secrets Glue Code
The second major feature is a workflow engine exposed through new sys/workflows endpoints. The problem it solves is embarrassingly common: you need to rotate a database credential, update the associated PKI certificate, and notify a downstream service — so you write a bash script that chains three separate API calls, adds error handling, and hopes nothing breaks between calls.
OpenBao v2.6 lets you define that sequence declaratively and execute it as a single managed workflow inside OpenBao itself. The API surface:
sys/workflows/manage/<path>— define and store workflow profilessys/workflows/execute/<path>— run a workflow (authenticated)sys/workflows/unauthed-execute/<path>— run with credentials passed in the request bodysys/workflows/trace/<path>— debug mode that logs every request and response in the pipeline
Workflows are built on the same profile engine that powers OpenBao’s declarative self-initialization, so the mental model stays consistent. This is the kind of quality-of-life addition that makes OpenBao feel like its own product rather than a Vault repackage. See the full release notes for workflow syntax details.
The GitLab Signal and Community Velocity
There’s a useful data point beyond the feature list: GitLab built its Secrets Manager directly on OpenBao, and it reached limited availability on August 20 — two weeks after this release. GitLab’s engineering team evaluated the options, chose OpenBao over Vault, and shipped it to their enterprise customer base. That’s a strong production-readiness signal from an organization that has to maintain this for tens of thousands of teams.
The contributor numbers from v2.6 also matter: 42 first-time contributors, 27 with multiple changes, 8 with double-digit contributions. The OpenBao v2.6 announcement calls this their most collaborative release yet. This isn’t a three-person side project — it’s a Linux Foundation project with real community velocity behind it.
Should You Actually Migrate from Vault?
If you’re running Vault CE (the BSL-licensed version), the honest answer is: yes, and the main question is timing. The API compatibility story is solid for the common engines. There’s no automated migration tool yet — you’ll need to script the re-creation of your engine configs, policies, and auth methods — but the in-place migration guide is clear enough to follow.
If you’re on Vault Enterprise, the calculation changes. Features added to Vault after the 1.14.0 fork point aren’t in OpenBao, and auto-unseal for sealable namespaces isn’t done yet. Weigh those gaps against what you’re paying for Enterprise support and licensing before committing.
OpenBao v2.6 is the first release where the project is genuinely ahead of open-source Vault on features that matter for multi-tenant and complex pipeline use cases. The fork is three years old. It took this long to get here, but the divergence has started — and it’s going in the right direction.
