OpenBao vs HashiCorp Vault: when each one fits
If your team runs HashiCorp Vault in production or has it on the shortlist, the decision now turns on licensing as much as features. OpenBao fits when your policy requires an MPL-2.0 licensed secrets manager and you do not depend on Vault Enterprise features that you would have to keep paying for. Vault fits when you already hold a Vault Enterprise license and rely on its features, or when you prefer HCP Vault Dedicated, the managed service that runs the same binary as self-managed Vault Enterprise. HashiCorp announced in August 2023 that future releases would move to the Business Source License 1.1, and the Vault LICENSE now names IBM as licensor, so the terms you accept today are the terms you will live under.
Confirm the current release lines before you plan. OpenBao 2.7.1 and 2.6.4 were released on October 1, 2026, and Vault 2.2.0 was released on October 15, 2026. Check which Vault features your cluster actually uses, since the Vault Enterprise documentation lists namespaces, performance replication, HSM support, seal wrapping, Sentinel and control groups as features that need a license applied to the cluster. OpenBao supports namespaces, but its migration guide was tested only against Vault 1.14.1 community edition, so any Enterprise-only setting needs its own test in a non-production cluster before you commit.
The decision turns on four questions: your license policy, how much of your current Vault estate depends on Enterprise features, which storage and HA design you will run (integrated Raft storage and PostgreSQL are the officially supported HA backends in OpenBao), and how much migration effort your teams can absorb. Ask HashiCorp for a written Enterprise quote if you intend to stay, and ask your DeployOpen or other implementation partner to scope a migration test if you intend to move. Either way, put the license decision in writing before the next renewal.
Which platform fits which team situation
This table matches common team situations to the platform that usually fits better, with the condition that would reverse the choice. Read each row against your own licensing policy, existing Vault footprint and operating model, because the better fit depends on those facts more than on feature lists.
| Situation | Better fit | Why and when the other option wins |
|---|---|---|
| Policy requires OSI-approved licenses | OpenBao | OpenBao is MPL-2.0 and Vault's Business Source License 1.1 is not an OSI-approved license. Vault wins only if the policy accepts source-available terms and the team needs HashiCorp-supported Enterprise features. |
| Vault Enterprise features already in use | HashiCorp Vault | Replication, HSM support, Sentinel, control groups and FIPS builds are Enterprise features that OpenBao may not replicate. Stay on Vault unless you have confirmed that each feature you depend on has an OpenBao equivalent. |
| Multi-tenant namespaces on a single cluster | OpenBao | OpenBao documents namespaces for multi-tenancy within one instance, a capability HashiCorp documents as Vault Enterprise. Confirm the exact behavior you need against the OpenBao namespaces documentation before you commit. |
| Managed service preferred | HashiCorp Vault | HCP Vault Dedicated runs the same binary as self-managed Vault Enterprise, so the vendor operates it. OpenBao has no managed offering in the supplied facts, so you would operate it yourself or through a partner. Ask providers to confirm any hosted OpenBao option. |
| Air-gapped site | Depends on storage and seal design | Both can run in isolated networks, but the choice then turns on the seal method and storage backend you can operate offline. Confirm offline licensing, update delivery and unseal procedures for each platform in your environment. |
| New deployment with no existing Vault | OpenBao | With no Vault footprint, MPL-2.0 licensing, integrated Raft or PostgreSQL storage and the same core secrets engines give a clean open-source start. Vault fits better if you expect to buy Enterprise features soon and want one vendor relationship with IBM. |
| Migrating a Vault Community deployment | OpenBao | The OpenBao migration guide was tested only against Vault 1.14.1 community edition, so the in-place swap is the more direct path for community users. Test your exact Vault version and configuration in a non-production environment before cutover. |
| Heavy use of Vault Enterprise HA or performance replication | HashiCorp Vault | Performance and disaster recovery replication are Enterprise features, and OpenBao's HA model is documented around Raft and PostgreSQL standbys. Keep Vault if your recovery design depends on replication, and ask OpenBao maintainers about any roadmap for it. |
| Regulated buyer that needs a support contract from the software maintainer | HashiCorp Vault | Vault Enterprise is sold by HashiCorp under IBM with commercial terms. OpenBao is community-led under the Linux Foundation's OpenSSF, so support comes from third parties. Confirm which support model your auditors and procurement accept. |
How OpenBao and Vault are built and what that means for operations
Both products run an active node and standby nodes, but they differ in which storage backends they support for high availability, how standbys scale reads, and which deployment options are open to you. The cards below cover the components you will operate, and each one names the check to make before you commit.
Active and standby HA model
One node holds a lock in the data store and serves requests as the active node, while standby nodes forward or redirect requests to it. If the lock holder fails, a standby takes over. Ask your team how failover is tested, how long clients tolerate a leader change, and whether load balancers route to the active node correctly. The same model applies to both products, so the check is about your network and client behavior rather than the product choice.
Integrated storage (Raft)
Raft replicates secret data across OpenBao nodes without an external database. OpenBao lists integrated storage as a supported HA backend, and HashiCorp recommends it for most Vault use cases. The operational cost is that you own the replication, node sizing, snapshots and recovery of the cluster itself. Confirm your backup and restore procedure before you go live, since the cluster is the only copy of its state.
PostgreSQL as a storage backend
OpenBao can store data in an external PostgreSQL server or cluster, and it lists PostgreSQL as a supported HA backend. The OpenBao docs describe PostgreSQL as easier to operate safely than Raft, which suits teams that already run and back up PostgreSQL. Vault's documented external backends, including PostgreSQL, have limited support, so a Vault team moving to PostgreSQL should confirm that path with HashiCorp before depending on it.
Standby read scaling
Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and OpenBao 2.7.0 extended this to PostgreSQL. Read traffic can therefore spread across standbys instead of hitting only the active node. This matters for high-read workloads such as frequent secret lookups by many services. Test which requests your clients send and whether your applications tolerate slightly stale reads before you count on this capacity.
Seal and unseal at a high level
A sealed cluster cannot decrypt its data, so every restart needs an unseal step. Each product supports sealing and unsealing, and the choice between key shares held by people and automatic unsealing through a key management service changes your runbook and your recovery risk. Losing the seal material can make the data unrecoverable. Decide how your team will unseal after a reboot and document who holds the material before the first production deployment.
Community binary, source and HCP Dedicated
OpenBao ships as a community project under MPL-2.0 that you build or install and run in your own infrastructure. Vault is available as Community Edition binaries or source, as licensed Vault Enterprise, and as HCP Vault Dedicated, a managed service that runs the same binary as self-managed Vault Enterprise. Choose the model based on who operates the cluster and where secrets may reside. Confirm with HashiCorp which Enterprise features and support terms apply to your contract.
What the BSL 1.1 change means for Vault licensing
OpenBao is the community fork of Vault. Its repository is licensed under MPL-2.0 and it is led by a community under open-governance principles. The project is a Sandbox project of the Open Source Security Foundation (OpenSSF) under Linux Foundation stewardship, so its roadmap and releases are not set by a single vendor's commercial decisions.
- License: MPL-2.0 applies to the repository, which is a file-level copyleft that keeps modifications to covered files open when you distribute them.
- Governance: A community leads the project under open-governance principles, with OpenSSF Sandbox status under Linux Foundation stewardship.
- Current lines: OpenBao 2.7.1 and 2.6.4 were released on October 1, 2026.
- Enterprise-style features: Namespaces for multi-tenancy within a single instance are documented in OpenBao, a capability HashiCorp documents as part of Vault Enterprise.
- Migration basis: The OpenBao migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise.
Confirm with OpenBao which features your environment needs before assuming parity with a Vault Enterprise deployment.
Vault Community Edition is offered as binaries or source. Since HashiCorp announced on August 10, 2023 that future releases would move from MPL-2.0 to the Business Source License 1.1, the license that applies depends on the Vault version you run. The Vault LICENSE file now names IBM as licensor and covers Vault 1.15.0 or later.
- Announcement: HashiCorp announced the change to BSL 1.1 on August 10, 2023.
- Licensor: The Vault LICENSE file names IBM as licensor, following IBM's acquisition of HashiCorp, completed on February 27, 2025.
- Competitive use limit: The license bars competitive hosted or embedded offerings, so offering Vault as a service to third parties needs a separate review.
- Conversion: Each version converts to MPL-2.0 four years after publication.
- Current release: Vault 2.2.0 was released on October 15, 2026, following 2.1.2 on October 7, 2026.
Have legal counsel read the LICENSE file for the exact version you plan to run, especially if you embed Vault in a product you sell.
Vault Enterprise is licensed software. Several features, including performance and disaster recovery replication, HSM support, namespaces, performance standby nodes, seal wrapping, FIPS compliance, control groups, Sentinel policy as code and MFA, need a license applied to the cluster. HashiCorp does not publish Vault Enterprise prices on its pricing pages and directs self-managed Enterprise buyers to sales.
- Licensed features: The Enterprise documentation lists the features that need a license on the cluster, not only the binary.
- Pricing: Vault Enterprise prices are not published, so cost depends on the commercial terms HashiCorp offers.
- Recurring cost: Expect the license to recur on an annual or term basis, which you should confirm in writing.
- Upgrades: Automated upgrades are listed as an Enterprise feature, so upgrade effort may differ from Community.
- Quote scope: Ask for the license terms, support scope, feature list and renewal conditions in one written document.
Request a written quote from HashiCorp that lists the exact features, node count and term, and compare it against the features you actually use.
HCP Vault Dedicated is HashiCorp's managed service. It runs the same binary as self-managed Vault Enterprise, so the Enterprise feature set and license model are the starting point, while HashiCorp operates the infrastructure. It is a hosted option, so the data location and operating responsibility differ from a self-hosted cluster in your own infrastructure.
- Same binary: HashiCorp states that HCP Vault Dedicated runs the same binary as self-managed Vault Enterprise.
- Operating model: HashiCorp runs the managed service, which moves infrastructure operation to the vendor.
- Pricing: HCP pricing is set through HashiCorp's commercial models, and the Enterprise self-managed prices are not published, so ask for a written quote.
- Data residency: Confirm the region, data location and key handling with HashiCorp before you choose this option for regulated data.
- Exit path: Ask how data and configuration would be exported if you later self-host, since the license terms affect that move.
Before you choose a managed option, ask HashiCorp for the written terms covering data location, support scope and exit.
Feature gaps and additions: namespaces, replication, HSM, Sentinel and FIPS
This table compares the capabilities OpenBao documents with the Vault Enterprise features HashiCorp lists as license-gated. Read each row as a question to settle with the OpenBao project before you plan a migration, because only some rows have a confirmed OpenBao answer. The main takeaway is that namespaces and standby reads are documented for OpenBao, while replication, HSM, governance and FIPS need confirmation.
| Capability | OpenBao | HashiCorp Vault |
|---|---|---|
| License | MPL-2.0, a community-led fork managed under the Linux Foundation's OpenSSF | Business Source License 1.1 with IBM as licensor, covering Vault 1.15.0 or later |
| Namespaces | Documented for secure multi-tenancy within a single instance | Listed as an Enterprise feature that needs a license applied to the cluster |
| Read scaling on standbys | Raft standbys serve read-only operations since 2.5.0; PostgreSQL added in 2.7.0 | Performance standby nodes, listed as an Enterprise feature that needs a license |
| Performance and DR replication | No supplied OpenBao fact; confirm current support with the OpenBao project | Listed as an Enterprise feature that needs a license |
| HSM and PKCS#11 support | No supplied OpenBao fact; confirm HSM seal and PKCS#11 provider status | Listed as an Enterprise feature with an HSM and PKCS#11 provider |
| Sentinel policy as code and control groups | No supplied OpenBao fact; do not assume equivalents without confirmation | Both listed as Enterprise features that need a license |
| FIPS compliance and seal wrapping | No supplied OpenBao fact; confirm FIPS-validated builds and seal wrapping options | Both listed as Enterprise features that need a license |
| Lease count quotas and MFA | Login MFA is documented; confirm lease count quota behavior with the project | Both listed as Enterprise features that need a license |
| Auth methods | AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens, userpass | Confirm the methods your integration needs against current Vault documentation |
Namespaces in OpenBao and the Enterprise features to verify
OpenBao supports namespaces for secure multi-tenancy within a single instance, which is the capability HashiCorp documents as part of Vault Enterprise. For a team that runs one OpenBao cluster for several business units, namespaces let each unit have its own space for policies, auth configuration and secret engines, so the cluster does not have to be split into separate deployments for every group. That saves operating effort, but it also concentrates risk: one cluster, one seal and one upgrade path now serve every tenant. Before relying on namespaces, check the OpenBao namespaces documentation for exactly what is isolated and what is shared, including whether root-level administrators can see or change tenant data and how delegated administration is scoped to each namespace.
Namespaces are only one part of the picture. Several Vault Enterprise features have no OpenBao equivalent in the sources reviewed for this page: performance and disaster recovery replication, HSM seals and the PKCS#11 provider, Sentinel policy as code, control groups, and FIPS-compliant builds. Confirm each one against the OpenBao documentation and the Vault Enterprise documentation before deciding, because a missing feature in OpenBao may still be covered by a different mechanism in your design. Write the answers down as a checklist: for each feature your current Vault or planned design depends on, record whether OpenBao provides it natively, through another feature, or not at all, and who owns the gap.
Ask the same questions of any vendor or integrator you engage. Request a written list of the namespace isolation guarantees you will rely on, a test plan that proves a tenant administrator cannot read another tenant's secrets or policies, and a decision record for each Enterprise feature you need. If a replacement is needed for replication, HSM sealing or FIPS, plan it as a separate workstream with its own owner and acceptance test, and confirm the compliance evidence you will need with your assessor before the cutover.
Moving from HashiCorp Vault to OpenBao: what transfers and what is rebuilt
This sequence moves a Vault deployment to OpenBao with a tested rollback path, so each dependency is inventoried, verified on a copy and confirmed before production traffic moves.
Inventory your Vault version and edition
The platform owner records the exact Vault version, whether the cluster runs Community Edition or licensed Vault Enterprise, and every Enterprise feature in use, such as performance replication, HSM seals, namespaces, control groups, Sentinel policies or MFA. Enterprise features are licensed to the cluster, so the list shows which items have no direct OpenBao equivalent and must be redesigned. The output is a written inventory signed off by the security owner.
Confirm the migration guide covers your version
Compare your inventory with the OpenBao migration guide. The guide was tested only against Vault 1.14.1 Community Edition, not Vault Enterprise or later Vault releases, so any gap between your version and that test point must be confirmed in writing with the OpenBao project or your implementation partner before work continues. Record each open question with an owner. The check is complete when every version and edition in use is either covered or has a confirmed path.
Back up data and document the rollback plan
Take a consistent snapshot of the storage backend, which is Raft or PostgreSQL in most clusters, and store unseal material and recovery keys in a separate, access-controlled location. Document the exact steps to restore the original Vault binary and data, who authorizes a rollback and how long clients can tolerate an outage. Restore the backup into an isolated environment to confirm it works. The step closes when a restore test succeeds and the rollback runbook is approved.
Rehearse the binary swap on a copy
Build a non-production copy of the cluster from the production snapshot, with the same storage backend, seal configuration and auth methods. Replace the Vault binary with the OpenBao build in place, follow the migration guide's configuration changes, and start the nodes. Note every error, warning and configuration key that changed. The rehearsal is complete when the copy starts cleanly, reports healthy status and the team has a list of required configuration edits.
Verify auth methods, policies and secret engines
On the copy, test each auth method in use, including AppRole, JWT/OIDC, Kubernetes, LDAP, TLS certificates and tokens, and confirm that existing policies evaluate as expected for representative identities. Read a sample of static secrets, request dynamic credentials from database and Kubernetes engines, and confirm leases revoke correctly. Check that any feature you rely on from Enterprise has been replaced or removed. Enable an audit device and confirm events are written. Sign-off comes from the owners of each application that consumes secrets.
Rebuild Enterprise-only features and client tooling
Redesign each Enterprise feature from the inventory using the controls OpenBao provides or your own architecture, and confirm the approach with the OpenBao project for anything not documented. Update client tooling, SDKs, CI pipelines, Helm charts and scripts that reference the Vault binary, endpoints or environment variables, and remove license files and licensing dependencies that no longer apply. Ask your vendor which commercial agreements end at cutover. The step is complete when every Enterprise dependency has a documented replacement or an accepted gap.
Cut over and monitor with rollback ready
Schedule the production swap in a change window agreed with application owners. Perform the binary swap node by node in the order your HA design supports, confirm the active node and standbys report healthy status, and watch secret read errors, lease revocations and audit log volume. Keep the rollback runbook live until the agreed monitoring period ends. The cutover is closed when applications read secrets without errors, the audit trail is intact and the change record is filed.
What drives the running cost of each platform
Licence terms set the starting point, but most of the running cost sits in people, storage and the operations that keep a Vault-style cluster unsealed, upgraded and recoverable. The cards below separate what is paid to a vendor, what is paid to your own staff, and what is paid once during migration, so you can ask each party for a comparable written quote.
Software licence and subscription
OpenBao is MPL-2.0 licensed, so the binary carries no licence fee for community use. Vault is available as Community Edition, as licensed Vault Enterprise, and as HCP Vault Dedicated, and HashiCorp's pricing pages direct self-managed Enterprise buyers to sales rather than publishing prices. Ask for the licence scope, the term, the renewal terms and which features the quoted tier actually includes, such as replication, HSM support, FIPS and Sentinel. Confirm whether any quote changes if IBM-era pricing terms are revised at renewal.
Infrastructure and storage backend
Both platforms need compute, load balancing and a storage layer sized for HA. OpenBao supports integrated storage (Raft) and PostgreSQL as its officially supported HA backends, and its documentation describes PostgreSQL as easier to operate safely than Raft. Vault's integrated storage and Consul are the officially supported backends, with external options listed as limited. Each choice shifts cost between nodes, a managed database service and the backup tooling you already run, so ask for the node count and storage sizing that the quote assumes.
Staff skills for HA and seal management
Running a Vault-style cluster recurs as operator time: monitoring leader election, rotating certificates, handling standby failover and managing unseal material. Under Shamir unseal, people hold key shares, and under auto-unseal the cloud KMS or HSM becomes another service to operate. Estimate the staff hours this takes in your own environment rather than relying on a vendor figure, and confirm whether the team already has these skills or needs training.
Upgrades and release tracking
Upgrades recur on whatever cadence each project ships. OpenBao currently has two supported release lines, 2.7.1 and 2.6.4, both released on October 1, 2026. Vault's current release is 2.2.0, released on October 15, 2026. Budget for regression testing against your own policies, auth methods and secret engines on each minor release, and confirm which release lines each vendor or partner will support and patch.
Support: vendor or services partner
Support can come from HashiCorp under an Enterprise or HCP contract, from the OpenBao community and its project channels, or from a services partner. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in the client's own infrastructure, typically under a fixed-scope engagement with ongoing support available as a retainer. Ask any provider for response targets in writing, who is on call, and what is excluded from the retainer.
One-time migration effort
Moving from Vault to OpenBao is a one-time cost, and it depends on the Vault edition in use. OpenBao's migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so any cluster using Enterprise-only features needs a separate replacement plan and testing. Ask for a scope covering configuration changes, rollback planning, validation of auth methods and dynamic secrets, and a written list of Enterprise features to replace.
Where OpenBao and Vault implementation projects usually run long
Implementation projects on either platform tend to run long in the same places: the storage and HA layout, the unseal method, identity and workload integration, policy and secret engine design, and audit and backup. For OpenBao, the storage and HA decision comes first. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and the OpenBao documentation describes PostgreSQL as easier to operate safely than Raft. Teams that pick a backend before confirming how their operators will patch, back up and restore it often rework the layout later. For Vault, the same decision sits next to the question of whether the Community Edition or Vault Enterprise is in scope, because the storage and HA choices differ with the license.
The most expensive surprise is an unclear Enterprise dependency found late. Vault Enterprise lists performance and disaster recovery replication, HSM support, namespaces, performance standby nodes, seal wrapping, control groups, Sentinel and FIPS compliance as features that need a license applied to the cluster. If a design quietly assumes one of these, the gap appears during cutover review, not during design. Before scoping, list every Vault feature the current cluster uses, then check each one against the OpenBao feature documentation and the Vault Enterprise documentation. The same check applies to unseal. Shamir key shares and auto-unseal need different custody records, and an undocumented ceremony for either is a common cause of delay, because nobody can rehearse a restart or a recovery until the procedure is written down and witnessed.
Migration testing has its own trap. The OpenBao migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so a test plan that uses a different Vault version or an Enterprise build has no published basis. Ask the vendor or your own test lab to confirm the exact version pairing before building the test plan, and record every result against that version. Fixed-scope engagements, which DeployOpen typically uses, agree scope, deliverables and timelines in writing before work starts, so the version pairing, the unseal custody model and the Enterprise feature inventory should all be settled in the statement of work. No duration is estimated here, and any timeline should come from a written scope for your environment.
Questions buyers ask before switching from Vault to OpenBao
Is OpenBao a drop-in replacement for Vault?
Not automatically, and the answer depends on which Vault you run. OpenBao is a community fork of Vault under MPL-2.0, and its migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise. Teams on community Vault should test their own configuration, auth methods and storage backend in a non-production environment before planning a cutover. Confirm the exact Vault version you run against the migration guide, and confirm with the OpenBao project how it handles any Vault features your configuration depends on.
What does the BSL 1.1 change mean for an existing Vault deployment?
HashiCorp announced on August 10, 2023 that future releases would move from MPL-2.0 to the Business Source License 1.1. The Vault LICENSE now names IBM as licensor, covers Vault 1.15.0 or later, and bars competitive hosted or embedded offerings. Each version converts to MPL-2.0 four years after publication. Internal use of Vault is not what the license restricts, but if you offer a competing hosted or embedded product, the terms matter. Have your legal team read the LICENSE file against your actual use before deciding, and do not assume the terms apply the same way to every version you run.
How much effort is a migration and who does it?
Effort is driven by the number of auth methods, secret engines, policies, namespaces and clients that depend on Vault, the storage backend in use, and whether you rely on Enterprise features. Cost has two parts: internal engineering time for testing, cutover and rollback, and any external services you buy under a written scope. DeployOpen plans, implements and documents this kind of work as fixed-scope engagements, and quotes follow from that agreed scope. Ask any provider for a written plan that lists the Vault version, the features in use and the rollback steps.
Can our team run OpenBao without outside help?
A team that already operates Vault in production can usually run OpenBao with its existing skills, because the core secrets engines, auth methods and HA model are documented as similar. The areas that need care are storage choice, HA configuration, unseal procedures and backups. OpenBao documents integrated storage (Raft) and PostgreSQL as the officially supported HA backends. Consider outside help when your team has no Vault operations experience, when the cutover window is short, or when you need documented runbooks for an audit. Whatever you choose, confirm the support path with the OpenBao community and your own internal owners.
Which Vault Enterprise features do we need to replace?
Start by listing every Enterprise feature in use. HashiCorp's Enterprise documentation lists performance and disaster recovery replication, HSM support and a PKCS#11 provider, namespaces, performance standby nodes, seal wrapping, FIPS compliance, control groups, Sentinel policy as code, redundancy zones, automated upgrades, lease count quotas and MFA. OpenBao supports namespaces for multi-tenancy within a single instance, and since v2.7.0 PostgreSQL standbys can serve read-only operations. Other features need a replacement plan, a different architecture, or a decision to accept the gap. Ask the OpenBao project which items are covered and which are not.
Do we need a consultant for an air-gapped deployment?
Not always, but air-gapped sites add work that is easy to underestimate. You need offline binary and package delivery, internal documentation of the unseal process, backup handling that does not depend on external services, and a tested recovery path. DeployOpen implements self-hosted platforms inside the client's own networks, including air-gapped ones, and prepares documentation and evidence, but it does not issue audit reports or certifications. Confirm your unseal method and key custody model first, then ask any provider for a written scope that covers offline installation and recovery testing.
What should we confirm with the vendors before switching?
Confirm five things in writing. First, the exact Vault version you run and whether the OpenBao migration guide covers it. Second, the license terms for the Vault version you will keep running, read against your use. Third, which Enterprise features you depend on and whether OpenBao covers each one. Fourth, the storage and HA design you will use, including the support status of each backend. Fifth, your rollback plan, including how you would return to Vault if the cutover fails. Check the OpenBao releases page for the current lines, OpenBao 2.7.1 and 2.6.4, released on October 1, 2026, before you choose a target version.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, so an OpenBao decision is tested against your environment before anything is installed. We start with the questions that decide between OpenBao and Vault: which Vault Enterprise features you rely on, how your clusters unseal and store data, and how far your team can carry the operating load.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory the Vault features in use, such as auth methods, secret engines, namespaces, replication and seal configuration, and mark which have an OpenBao equivalent.
- Written scope lists which Vault Enterprise features need a replacement, a redesign or a decision to stay on Vault, with the quote following from that scope.
How we build
- We deploy OpenBao in your cloud accounts, data centers or air-gapped network, with storage (integrated Raft or PostgreSQL) chosen against your HA requirements.
- We reproduce your existing auth methods and policies in a non-production cluster and test them with your real client workloads before cutover.
- We run security testing against the deployed cluster, covering access paths, token handling and the configuration we set for seal and storage.
How we hand over
- Handover documents the deployed architecture, storage and HA design, seal and recovery procedures and the rollback plan.
- Migration deliverables include a tested in-place or parallel cutover runbook, with the Vault versions the work was validated against recorded.
- Your team receives documented procedures for backups, upgrades and access reviews, written so staff can run the cluster without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover tracking OpenBao release lines and planning upgrades against your change windows.
- Compliance readiness work produces the configuration, access and evidence records your assessors request, while auditors and certification bodies issue any opinion.
