Open-source alternative to Vault Enterprise namespaces: the short answer
OpenBao provides namespaces in a single cluster, so teams that today pay for Vault Enterprise mainly to separate tenants, business units or environments can keep that isolation model without a Vault Enterprise license. The OpenBao namespaces documentation describes how each namespace holds its own mounts, auth methods and policies. Mapping those objects is usually the easier part of the work: you inventory each Enterprise namespace, recreate its auth mounts and secrets engines under an equivalent OpenBao path, and port the policies that reference them. Confirm the exact path syntax, policy behavior and any differences from your current Vault version against the OpenBao docs before you script the translation, and test one namespace end to end first.
The harder question is what happens to the rest of your Enterprise footprint. HashiCorp's Vault Enterprise documentation lists namespaces alongside performance and disaster recovery replication, HSM support, performance standbys, seal wrapping, FIPS compliance, control groups, Sentinel policy as code, redundancy zones, automated upgrades, lease count quotas and MFA as features that need a license applied to the cluster. Namespaces are the one you can replace directly. Each of the others needs its own decision: whether you still need it, which open-source mechanism covers it, or whether you accept the gap. Write that list before the migration starts, because a namespace move that succeeds technically can still leave a control your auditors expected in place.
Ask your Vault administrator to export a current list of enabled Enterprise features and the namespaces in use, then assign an owner and a replacement or acceptance decision to each item. Namespace isolation is a reasonable place to start because it can be validated with access tests across tenants. Plan the replication, HSM and policy-as-code decisions alongside it, since those affect your availability design and change control.
Which Vault Enterprise namespace capabilities map to OpenBao
This table maps the namespace-related features of Vault Enterprise to their OpenBao counterparts and marks where the documentation confirms a match and where a test cluster is needed. Read the rows marked as needing verification as the work list for a pilot, and treat the Enterprise features at the bottom as outside the namespace mapping. The main takeaway is that namespace isolation can be planned on OpenBao, but parity should be proven in your own environment before any cutover.
| Capability | Vault Enterprise | OpenBao and what to confirm |
|---|---|---|
| Namespace creation | Namespaces are created under the Enterprise license applied to the cluster | OpenBao documents namespaces as a concept; confirm the create, list and delete commands and API paths in your version |
| Nested namespaces | Namespaces can be nested to model tenants, business units and teams | Confirm nesting depth and naming rules in the OpenBao namespace docs against your existing hierarchy |
| Namespace-scoped policies | Policies are written per namespace and apply to paths within it | Confirm that policy paths resolve the same way inside namespaces and that root-namespace policies do not leak into children |
| Auth mounts per namespace | Each namespace can host its own auth methods such as AppRole, Kubernetes or OIDC | OpenBao documents its auth methods; test each mount type you use in a child namespace, since plugin availability differs |
| Secrets engines per namespace | KV, database and PKI engines can be mounted inside a namespace | Test dynamic secrets for each database or Kubernetes role you depend on, and confirm plugin support for your targets |
| Token scoping | Tokens are bound to the namespace where they were issued | Note that OpenBao issues a shorter new token format; confirm namespace binding and TTL behavior with your clients |
| Admin delegation | Namespace administrators manage their own tenant without root access | Write delegation policies as a test case and verify that a tenant admin cannot read or modify sibling namespaces |
| Replication and performance standbys | Performance and DR replication, plus performance standby nodes, need an Enterprise license | Outside the namespace mapping; OpenBao HA uses an active node with standbys, so plan availability separately |
| Sentinel, control groups, seal wrapping, FIPS, quotas | Sentinel policy as code, control groups, seal wrapping, FIPS compliance and lease count quotas need an Enterprise license | Outside the namespace mapping; confirm each control in OpenBao docs or by testing, and do not assume an equivalent exists |
Ways to structure tenants on OpenBao
Vault Enterprise namespaces let several teams or business units share one cluster. OpenBao includes namespaces, but how you divide tenants across clusters still determines blast radius, upgrade coordination and what an auditor can verify. The three options below cover the common choices.
One cluster with namespaces per tenant
All tenants share one OpenBao cluster, with each team or business unit given its own namespace, policies and auth mounts. This fits organizations with many small internal teams, a single platform team and no hard regulatory boundary between tenants. The trade-off is blast radius: a storage fault, a bad upgrade or a misconfigured root-level policy affects every tenant at once. Confirm in your environment that namespace policies deny cross-namespace reads in tests, and that admin tokens are scoped so no tenant admin can reach the root namespace.
One cluster per tenant or environment
Each tenant, or each environment such as production and non-production, runs its own OpenBao cluster with separate storage, unseal keys and audit devices. This fits workloads where a tenant needs its own unseal authority, separate backup schedules or an isolated network zone. Blast radius is limited to one cluster, but operations multiply: each cluster needs its own high availability design, backups, monitoring, certificates and upgrades, and each upgrade must be scheduled separately. Ask who holds unseal material for each cluster and how many clusters your staff can patch within your change window.
Hybrid: namespaces for teams, separate clusters for regulated data
Teams that share low-sensitivity secrets sit in namespaces on a shared cluster, while workloads under a regulation such as payment card or patient data run on dedicated clusters. This keeps the operational cost of many clusters down while giving auditors a clear boundary for the most sensitive secrets. The cost is a second design to document, and a rule that decides which class of data goes where. Confirm the classification rule with your compliance lead before any secret moves, and confirm that clients for regulated workloads cannot fall back to the shared cluster's address.
Coordinating upgrades across tenants
Whichever model you choose, a single OpenBao version runs across the clusters you operate, and each upgrade affects every namespace or cluster in scope. Plan a staging cluster that mirrors one production tenant, and test the upgrade path first. The OpenBao migration guide was tested only from Vault Community 1.14.1 on Raft storage, so confirm your starting version before you assume a path. Confirm with each tenant owner which maintenance windows they accept, and who signs off on rollback.
Confirming isolation in your environment
Namespace separation is a logical control inside one cluster, so it must be proven with your own tests rather than assumed from documentation. Build a test matrix that attempts cross-tenant reads, lists, policy edits and token reuse from each tenant identity, and record the results. Store the audit device output for those attempts. Ask whether any tenant's storage backend, backup or encryption key is shared with another tenant, because those shared components set the real boundary.
What changes for platform teams, app owners and auditors
Platform and security engineers own the cluster, the policy set and the administrative workflow. OpenBao keeps the Vault model of namespaces, policies and auth mounts, so most day-to-day concepts carry over. The change is in what the cluster is licensed and supported to do, and in which features you must rebuild or replace yourself.
- Namespace layout: Namespace paths and hierarchy are mapped from your Vault Enterprise design. Confirm the namespace feature set in the OpenBao namespaces docs against the exact Vault features you use.
- Policies: HCL policies generally port over, but Sentinel policy as code is a Vault Enterprise feature and must be re-created as another control, such as CI checks or manual review.
- Auth mounts: AppRole, JWT/OIDC, Kubernetes, LDAP and TLS methods are documented in OpenBao, so you re-declare each mount per namespace and test its roles.
- Admin workflow: Control groups and automated upgrades are Enterprise features. Plan approvals and patch windows as your own runbooks.
- Replication: Performance and disaster recovery replication need a separate design in your environment.
Before cutover, check each namespace's policies and auth mounts against a test cluster and document every Enterprise feature you no longer have.
Application teams see their impact mostly through paths, auth mounts and client configuration. Their secret reads should look the same once the namespace header or path is correct, but any hard-coded Vault paths, tokens or agent templates must be reviewed. Platform teams should give each team a dated list of what changes for them.
- Secret paths: Paths inside a namespace may change if the namespace prefix moves. Keep the logical secret names stable where you can, so application code changes less.
- Auth mounts: Applications authenticate through the mount for their namespace. Confirm the role names and bound claims after the move.
- Client configuration: Set the address and namespace in Vault SDKs, CLI profiles, Vault Agent and Kubernetes injector configuration. These clients are the usual source of failed reads after a migration.
- Token format: New tokens use a shorter OpenBao format, so any code that parses token strings must be checked.
- Dynamic credentials: Lease handling and revocation behavior should be tested against each database or Kubernetes engine in use.
Ask each application owner to run a read test in a non-production namespace before the production switch.
Compliance and audit leads need evidence that tenants are separated and that access is logged. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, and this page does not promise any particular outcome.
- Isolation design: Document which namespaces hold which tenant's secrets, which policies apply, and which identities can reach each namespace. Keep the design in version control.
- Access records: Confirm the audit devices you enable in OpenBao and where logs are shipped, retained and protected. Check that log entries identify the namespace and identity for each request.
- Change history: Record policy and auth mount changes through your change process, including who approved each one.
- Lost Enterprise controls: List Enterprise features you no longer have, such as Sentinel, control groups and FIPS-related options, and document the compensating control or accepted risk for each.
- Auditor review: Ask your auditor which evidence format they expect before you collect it.
Confirm the control scope and evidence requirements with your auditor before the move, not after.
Which Enterprise features do not come across with namespaces
Moving namespaces does not move the rest of the Vault Enterprise feature set. Vault treats namespaces, performance and disaster recovery replication, performance standby nodes, Sentinel policy as code, control groups, seal wrapping, FIPS compliance, redundancy zones, automated upgrades and lease count quotas as Enterprise features that need a license applied to the cluster. A namespace migration to OpenBao carries across the namespace layout, policies and auth mounts, but none of these controls is implied by it. Start by reviewing the Vault Enterprise documentation and listing which of these features your current design depends on, including any that exist only as a side effect of your deployment.
For each feature on that list, record the control it supports, the team that owns it and the evidence you rely on. Replication and performance standbys usually matter for availability and read scaling, so ask how OpenBao's high availability model and read scaling on its supported backends meet the same recovery and capacity targets. Sentinel policies, control groups and lease count quotas are policy controls, so you will need to decide whether to rewrite them in OpenBao's policy language, enforce them in a gateway or CI check, or accept the gap. Seal wrapping, HSM-backed sealing and FIPS requirements belong to a separate review, and any compliance claim should be confirmed with your assessor and the OpenBao project rather than assumed.
Do not treat this list as a feature comparison. The migration guide was tested against Vault Community 1.14.1, not Enterprise, so the Enterprise features in your cluster are outside what that guide covers. Ask the OpenBao project and your implementation partner to confirm, in writing, the equivalent or replacement control for each item you rely on, and mark any item without a confirmed answer as a blocker or an accepted risk before cutover. Record the decision for each feature in your migration plan, since an unresolved gap found after go-live is far more costly to close.
How to move namespaces and policies from Vault Enterprise to OpenBao
This sequence takes the namespace, auth, policy and secrets layout of a Vault Enterprise cluster and rebuilds it in OpenBao, with each step ending in a check that the result matches the source. It produces a verified target cluster and a cutover plan that your platform team can sign off on.
Inventory namespaces, mounts and policies
Your Vault administrators export a full list of namespaces, auth method mounts, secrets engine mounts, policies and identity entities from the Enterprise cluster through the API and CLI. Record which mounts use plugins, since the OpenBao migration guide skips plugins that OpenBao does not ship. The step is complete when every namespace has a documented owner, each mount has a recorded type and path, and the plugin-based mounts are flagged for a separate decision.
Confirm the starting version and storage
Check the exact Vault Enterprise version, storage backend and seal type of the source cluster. The OpenBao migration guide was tested only against Vault 1.14.1 Community edition on Raft with Shamir unseal, and was not tested against Vault Enterprise. Ask OpenBao maintainers or your own test results to confirm whether your version and features are covered. The step closes with a written compatibility note that lists every Enterprise feature in use, such as namespaces, replication, Sentinel or control groups, and whether each one has an OpenBao equivalent.
Choose in-place upgrade or rebuild
Decide whether to convert the existing cluster in place or build a new OpenBao cluster and move data into it. The in-place path is documented as a node-by-node upgrade for a narrow starting point, so most Enterprise clusters will need a rebuild. Record the decision with the reasons, the rollback position and the owner who approves it. The step is done when the decision is signed off and the team agrees which Enterprise features will be dropped, replaced or kept outside Vault.
Recreate namespaces and policies in a test cluster
Build a non-production OpenBao cluster and recreate the namespace hierarchy, auth mounts, secrets engine mounts and policies from the inventory. Policies are copied as HCL files under version control so the diff against the source can be reviewed. Where a Vault namespace relies on an Enterprise-only control, document the replacement, such as an external approval workflow, rather than assuming it carries over. The step ends when a policy diff shows no unexplained differences and each test namespace can authenticate with the intended method.
Move secrets through the API
Read each KV secret from the source cluster through the API, with a scripted export that writes to an encrypted store controlled by your team, and write it into the matching path in OpenBao. Dynamic secret configurations and leases are not moved this way, so applications that depend on them need new backend configuration. The step is complete when secret counts and version histories are reconciled per mount, and a sample of values is checked by the owning team without copying them into tickets or logs.
Re-point clients, agents and Kubernetes injectors
Update the Vault address, namespace path and auth configuration in each application, Vault Agent, CI job and Kubernetes injector that reads secrets. Note that new tokens use a shorter OpenBao format, so any code that parses token prefixes or stores tokens needs review. Test each consumer in the test cluster first and keep the Vault endpoint available for rollback. The step is complete when every consumer has a recorded test run against OpenBao and the list of remaining Vault references is empty or approved.
Run parallel verification before cutover
Run the old and new clusters side by side for a period your team sets, reading the same secrets from both and comparing results for each consumer and namespace. Review audit logs from both systems to confirm that access is recorded and that identities map to the right policies. Ask your auditors which evidence they expect for the change. The step closes with a signed cutover checklist that names the rollback owner and the criteria for switching traffic.
What the cost of this change is made of
The cost of moving Vault Enterprise namespaces to OpenBao splits into a recurring part and a one-time part, and the recurring part is the one most likely to be misread. The Vault Enterprise subscription is the line you stop paying, but HashiCorp publishes no Enterprise prices and directs self-managed buyers to sales, so the figure you compare against must come from your own renewal quote. Ask for the license term, the node count and whether the quote covers HCP Vault Dedicated, since that managed service runs the same Enterprise binary and would not remove the cost. Keep the license line item separate from support and infrastructure so the comparison stays honest.
Recurring costs on the OpenBao side are the infrastructure for the nodes and storage, the unseal method, third-party support and ongoing upgrades. The HA backend choice drives much of this. Integrated storage (Raft) needs at least the node count HA requires and its own backup routine, while PostgreSQL moves the operational load onto a database team that may already run it. Namespaces themselves add no license cost in OpenBao, but each tenant's policies and auth mounts add review and monitoring work. If you use an HSM or cloud KMS for auto-unseal, include its fees and the key administration effort, which recur for as long as the seal is in use.
One-time costs are the migration project and testing. Staff time covers mapping each Enterprise namespace to an OpenBao namespace, rebuilding policies and auth mounts, and testing tenant isolation before cutover. OpenBao's migration guide was tested only against Vault 1.14.1 Community, so any Enterprise-specific behavior needs a test run in your own environment before you price it. Ask any implementation partner for a written scope listing the namespaces, mounts, clusters and test cases covered, the deliverables and the timeline, and ask whether support and upgrades are a separate retainer. Confirm each assumption in writing so the quote and your internal model match.
Questions buyers ask about replacing Vault Enterprise namespaces
Are OpenBao namespaces free to use?
Yes, namespaces are part of the OpenBao feature set, which is licensed under MPL-2.0, so you do not buy a separate namespace license. The cost of running them sits in the infrastructure and staff time around the cluster. Confirm the namespace behavior against the OpenBao namespaces documentation and your target release, because feature details can change between minor versions. Your real cost questions are about the cluster that hosts the namespaces: storage, high availability design, backups, and the people who operate them.
How long does a namespace migration take, and what drives the duration?
The duration depends on how many namespaces, auth mounts, policies and secrets engines you have, and on how many clients must be re-pointed. There is no fixed figure that applies to every estate, so ask for an estimate built from your own inventory. The main drivers are the count of namespaces and their nesting, how many auth methods use plugins or settings that need manual rework, the number of applications, agents and Kubernetes injectors that read from each namespace, and how much testing your change process requires. Ask any provider, including DeployOpen, to base the schedule on a written inventory of your namespace tree.
Can our team migrate namespaces without outside help?
Many teams can, provided they have people who already run Vault and can test each change in a non-production cluster first. Start by checking the OpenBao migration guide, which documents an in-place upgrade path from a specific Vault Community version and warns that some plugins are skipped. Namespaces that exist only in Vault Enterprise are a separate exercise, because the guide was tested only against Vault Community 1.14.1. Outside help is most useful for mapping the namespace hierarchy, rebuilding policies, and proving the result to your auditors.
What does the migration need from our staff?
The work needs people who understand your Vault policies, auth mounts and client configuration, plus someone who can operate the OpenBao cluster after cutover. Expect involvement from platform engineers, application owners who manage their own secret paths, and security staff who approve policy changes. Plan for a window to run both environments side by side and for on-call coverage during the switch. Confirm with any provider which of these roles they will fill and which must stay with your team.
Can we audit that namespaces actually isolate tenants?
Yes, but the evidence has to come from your own configuration and logs, and an auditor decides whether it is sufficient. Export the namespace tree, policies, auth mounts and token scopes, then test that a token from one namespace cannot read another namespace's paths. Keep audit device logs that show who accessed which namespace. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so independent auditors and certification bodies still make the call. Ask your auditor which control evidence they expect before you start.
Do we need Enterprise replication or HSM features too?
Only if your current design depends on them. Namespaces alone do not require replication or an HSM, but many Vault Enterprise deployments enable them at the same time. Vault Enterprise lists performance and disaster recovery replication, HSM support with a PKCS#11 provider, and seal wrapping among features that need a license. Review each one in your cluster before scoping. For HSM auto-unseal, see the separate HSM support page, because key material must be created in the HSM first and the seal does not carry over without a data migration. Replication designs also need their own plan in OpenBao.
Can DeployOpen take on the namespace migration under a fixed scope?
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask for the scope to list your namespace inventory, the migration steps, the testing approach, the handover documentation and any post-cutover support. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list.
Primary sources to check before you decide
Start with the OpenBao namespaces documentation. It settles the question this page turns on: whether OpenBao's namespace model covers the way your organization separates tenants, teams or environments inside one cluster. Compare the hierarchy it describes with the namespace paths you use in Vault Enterprise, and confirm how policies and auth mounts are scoped within each namespace. Check especially how namespace-scoped policies reference paths, since small differences in path syntax are a common source of broken access after a move.
Next, read the OpenBao migration guide. It settles what the documented upgrade path covers. The guide describes an in-place upgrade from Vault Community 1.14.1 on Raft with Shamir unseal, was tested only against that version, and skips mounts that use plugins OpenBao does not ship. If your cluster runs a different Vault version, uses Enterprise namespaces, or depends on plugins, you will need to confirm each of those points with OpenBao maintainers or through a proof of concept before you plan the namespace mapping.
Then check the Vault Enterprise documentation to inventory exactly which features your current namespaces depend on. It lists namespaces alongside other features that require a license applied to the cluster, so it tells you which Enterprise behaviors you are paying for beyond namespaces. Finally, review the HashiCorp Vault pricing page. It shows the commercial models and directs self-managed Enterprise buyers to sales, so it settles the licensing model you would be comparing against, but the actual Enterprise price must come from a written quote.
How DeployOpen scopes and delivers a namespace migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For namespace work, we start from a written inventory of your Vault Enterprise namespaces, policies and auth mounts, then rebuild the tenant boundaries in OpenBao within your own cloud accounts, data centers or air-gapped network.
How we scope
- Inventory every Vault Enterprise namespace, its child namespaces, policies and auth mounts before any build begins.
- Record which Enterprise features each namespace depends on, such as replication, Sentinel policies or control groups, and mark what has no OpenBao equivalent.
- Agree scope, deliverables and timelines in writing; engagements are fixed-scope, and the written scope states what is in and out.
How we build
- Recreate the namespace hierarchy, policies and auth mounts in OpenBao on your own infrastructure, with each tenant mapped to a documented boundary.
- Test each mapped auth method and policy against representative client identities in a non-production environment before cutover.
- Adjust integrations for clients, agents and Kubernetes injectors, and confirm that tenant isolation holds under the test cases agreed in scope.
How we hand over
- Deliver a written mapping document that shows each Vault namespace, its OpenBao equivalent and every feature that did not carry over.
- Provide runbooks for operating the OpenBao cluster, backups, upgrades and access reviews, so your team can run the platform after handover.
- Document evidence for your own compliance assessments; DeployOpen prepares controls and evidence, while independent auditors issue any audit reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
- Confirm with us during scoping which OpenBao release line and upgrade cadence your platform team will follow.
- Ask for a quote based on the written scope; DeployOpen does not publish a price list, and the quote follows from the agreed deliverables.
