Which fits: HCP Vault Dedicated or self-hosted OpenBao for your secrets
A renewal, a licensing change or a data residency requirement is forcing a decision about where your Vault-style secrets run. HCP Vault Dedicated fits teams that want HashiCorp to operate the cluster and that accept HashiCorp's chosen data location and service terms. Self-hosted OpenBao fits teams that must keep secrets and encryption keys inside their own cloud accounts, data centers or air-gapped networks, and that have staff to run the storage, unsealing, backups and upgrades. Neither option is the right answer on price alone, because HCP and Vault Enterprise pricing is available only by quote.
The decision turns on three questions. First, do you depend on features that sit behind the Vault Enterprise license, such as namespaces, performance and disaster recovery replication, HSM support, or Sentinel policy as code? Each one needs its own mapping to OpenBao, and some will not carry over as-is, so list the features your teams actually use. Second, where must the data physically live, and who may hold the unseal material? Ask your compliance and legal owners to confirm the residency rule in writing before you talk to a vendor. Third, can your team own patching, upgrades and incident response? A managed service moves much of that work to HashiCorp, while OpenBao moves it to you.
Compare the two options on operating model, not on price. For each, ask for a written quote that lists the subscription or service terms, the regions and data location, the support scope and the exit path, and set it against your own staff time, infrastructure, storage, key management and third-party support for OpenBao. Use the OpenBao migration guide to check which current Vault versions and cluster types are covered before you assume a path. If you cannot confirm these points from the vendor documentation, record them as open items and resolve them before you commit.
Which option fits which scenario
This table maps common conditions to the option that usually fits better, HCP Vault Dedicated or self-hosted OpenBao, and explains the condition under which each advantage matters. Read each row against your own constraints, since a single requirement such as data location or staffing often decides the choice on its own.
| Scenario | Better fit | Why |
|---|---|---|
| A regulator requires keys and secrets to stay in the bank's own network | Self-hosted OpenBao | Data location is set by your infrastructure. This matters when the supervisor or internal policy requires the secret store to run inside your own network, and you must confirm what HCP region and network path a managed service would use. |
| The team has no platform or security operations staff | HCP Vault Dedicated | HashiCorp operates the managed service, so patching and cluster operations sit with the vendor. This matters only if you can accept the vendor's operating model and the quote covers the support level you need. |
| Multi-region replication is required | HCP Vault Dedicated or Vault Enterprise, to be confirmed | Replication is an Enterprise feature that needs a license on the cluster. Confirm whether your OpenBao design can meet the same recovery objectives with your own storage and failover design. |
| Heavy use of Vault Enterprise namespaces or Sentinel policy as code | Stay on Vault Enterprise, to be confirmed for HCP | Namespaces and Sentinel are Enterprise features. OpenBao includes namespaces, but mapping Sentinel policies needs a rewrite into OpenBao's policy model, so assess this before moving. |
| The environment is air-gapped | Self-hosted OpenBao | A managed service requires network connectivity to the vendor. This matters when no outbound path is permitted, and you must plan image delivery, updates and seal material handling inside the enclave. |
| A small team wants vendor-run upgrades | HCP Vault Dedicated | Upgrades are scheduled by the vendor rather than your team. This matters when change windows are hard to staff, and you should ask the vendor how maintenance windows and rollback are handled. |
| The team already runs Vault Community 1.14.1 on Raft | Self-hosted OpenBao | OpenBao's documented migration is a node-by-node in-place upgrade from this exact version and storage type. This matters because the path is tested, though you must confirm plugins and auth methods in use are supported. |
Where your secrets live and who holds the keys
HCP Vault Dedicated runs in HashiCorp-operated cloud infrastructure, while self-hosted OpenBao runs wherever you deploy it: your cloud account, your data center or an air-gapped network. With the managed service, the cluster, its storage and its backups sit in HashiCorp's environment, so the first check is which region and provider your HCP cluster uses and whether that matches your residency and sovereignty obligations. Ask the vendor in writing where encrypted storage, snapshots and support access are located. With OpenBao, the location is a design decision you own, and the same question becomes which account, region, subnet and storage volume hold the Raft or PostgreSQL data.
Key custody is where the models differ most. Under HCP, the unseal and recovery material and the root token lifecycle are managed through the service, so you should confirm with HashiCorp exactly who can access them, how they are generated, stored and rotated, and what your team can do during a provider incident. With OpenBao, you decide. Store unseal keys or auto-unseal keys in a KMS or HSM you control, split administrative duties across people, and document who can generate a root token. Audit devices are a related decision: confirm whether your audit log is delivered to a store you own, because your SIEM and incident response depend on it. Identity federation should be mapped to your existing identity provider through the OIDC, JWT, LDAP or Kubernetes auth methods, so that human and workload access do not depend on a second directory.
Compliance evidence follows the same split. You can ask HashiCorp for its own assurance documentation for HCP and review it with your compliance team, but its scope covers only the service it operates, not your configuration. With OpenBao, your team produces the evidence for access reviews, change records, backup restore tests and key ceremonies. DeployOpen can prepare these controls and evidence for your assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, and you should confirm early which scope and criteria your auditor will apply to each model.
Hosting, identity and compliance implications
Moving from a managed HCP Vault Dedicated cluster to OpenBao in your own infrastructure changes who holds the data, the unseal keys, the audit trail and the patch schedule. Each card below names one of those decisions and the condition under which it matters most for your organization.
Data residency and location
With HCP Vault Dedicated, secrets are stored in a HashiCorp-operated environment, so you need to confirm the region and hosting location available for your tenant against your residency rules. With self-hosted OpenBao, storage sits wherever you deploy it, whether that is your cloud account, a data center or an air-gapped network. This matters most when regulators or contracts name specific jurisdictions for credentials or key material. Ask HashiCorp to put the hosting location in writing and map your own storage locations for the OpenBao option.
Key and unseal custody
Both options start sealed, and the unseal material and root keys decide who can read the data. Under HCP Vault Dedicated, HashiCorp operates the cluster, so confirm in writing who can access unseal material and how auto-unseal is configured. Under self-hosted OpenBao, your team controls unseal, Shamir shares or a cloud KMS or HSM, and must document custody, rotation and break-glass procedures. This matters most when your policy requires that no single party can decrypt production secrets.
Identity and auth methods
OpenBao documents AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens, username and password, and login MFA. Map each workload and human login in your current Vault setup to one of these methods before cutover, and confirm that your identity provider supports the chosen flow. OpenBao recommends Userpass for developer machines and AppRole for servers. This matters most when workloads authenticate through Kubernetes service accounts or an existing LDAP or OIDC directory.
Audit and evidence ownership
Audit logs and the evidence an assessor will ask for are produced by the cluster itself. With a managed service, request which audit logs HashiCorp provides, their retention period and how you export them into your SIEM. With self-hosted OpenBao, you decide where audit devices write, how long logs are kept and how access reviews are documented. Preparing these controls and records is part of compliance readiness, but only an independent auditor or certification body can issue an audit report or attestation. This matters most when you need evidence for an upcoming assessment.
Network isolation and trust boundaries
A managed cluster is reached over a network path that HashiCorp operates, while a self-hosted cluster sits inside your segmentation model. Decide which workloads may reach the API, whether peering or private connectivity is required, and where the trust boundary lies between application networks and the secrets store. Confirm how your chosen deployment restricts ingress and whether standby nodes and storage backends are isolated from general traffic. This matters most when production secrets must never cross a shared or internet-facing path.
Shared responsibility for patching
With HCP Vault Dedicated, HashiCorp applies platform upgrades on its schedule, subject to the terms you agree to. With OpenBao, your team or a support partner selects versions, tests upgrades and applies security fixes, such as v2.7.1 released on October 1, 2026. Record who owns each layer (OS, storage, OpenBao binary, plugins and the Helm chart where used) and the time you commit to for critical fixes. This matters most when you cannot accept a gap between a published fix and its deployment.
How availability design differs between the two models
In a self-hosted OpenBao deployment, the availability design is your decision, and it starts with the storage backend. OpenBao's high availability model uses one active node that holds a lock in the data store, while standby nodes either forward or redirect client requests to the active node. The officially supported HA backends are integrated storage (Raft) and PostgreSQL. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended that read capability to PostgreSQL, which gives you horizontal read scaling. Writes still go through the active node, so plan capacity for the active node and confirm with the OpenBao HA documentation how your chosen backend behaves during a leader change.
With HCP Vault Dedicated, HashiCorp operates the cluster, so node count, placement and failover are part of the service design rather than your build. Before you compare, ask HashiCorp in writing for the cluster sizing tiers, the number of nodes and availability zones offered, the failover behavior, and the service level terms that apply to your contract. Those details come from the HashiCorp documentation and your quote, not from this page, and they should be read against your own recovery time and recovery point targets.
Disaster recovery is where the two models differ most in responsibility. Under self-hosting, your team must specify replication targets, snapshot schedules, the location and access controls of backups, the unseal material and its custodians, and the runbook for promoting a standby cluster or restoring from backup. Test those steps on a schedule, because a restore that has never been rehearsed is not a recovery plan. Confirm which Vault Enterprise replication features HashiCorp includes in the managed service, since performance and disaster recovery replication are Enterprise features in self-managed deployments, and decide whether OpenBao's current feature set covers your recovery design.
What each option costs to run, by component
HCP Vault Dedicated bundles most running costs into one quoted service, while self-hosted OpenBao spreads them across infrastructure, staff and projects you control. The cards below separate what is paid to whom, what is one-time and what recurs, and what changes each figure, so you can request comparable written quotes.
HCP subscription and consumption terms
HashiCorp prices HCP Vault Dedicated by quote and does not publish a rate card on its pricing page, so the recurring fee depends on the cluster size and terms you negotiate. Ask whether the quote is a fixed subscription, usage-based, or a mix, and what triggers overage. Confirm which HCP region hosts your data, which support tier is included, and whether Enterprise features you need are covered by the same agreement.
Compute and storage for the cluster
Self-hosted OpenBao needs enough compute for active and standby nodes, plus durable storage for integrated Raft or PostgreSQL. You pay the cloud or data center provider for these resources every month, and the cost rises with node count, disk size and redundancy across zones. Ask your platform team to model three-node sizing and growth for leases and audit logs, because storage use changes with workload.
Auto-unseal with HSM or cloud KMS
Auto-unseal avoids manual Shamir key handling on restart, but it needs an HSM or a cloud KMS key that you provision and pay for. HSM hardware is usually a capital or hosting cost, while KMS is metered per key and request. Confirm how your organization will protect the unseal path, who holds the key administrator role, and whether an HSM vendor support contract is required.
Load balancing, backups and monitoring
A production OpenBao cluster needs a load balancer in front of the nodes, tested snapshot backups held outside the cluster, and metrics, logging and alerting. Each adds a recurring tool or cloud charge and a maintenance task. Ask HCP for the equivalent operational coverage in writing, because what HCP manages for you may differ from what you must build.
Staff time for patching and upgrades
With HCP, HashiCorp operates the service. Self-hosted OpenBao puts patching, version upgrades, certificate rotation and incident response on your engineers, which is usually the largest recurring cost for a small team. Estimate this as a share of named roles and on-call duty, and check the OpenBao release cadence against your change process. OpenBao v2.7.1 was released on October 1, 2026 with security fixes, which is the kind of update your team would need to schedule.
One-time migration and optional support
Moving from Vault to OpenBao is a one-time project covering a plan, a test cluster, client and agent updates, and a cutover. Third-party support for OpenBao is optional and recurring if you choose it. Ask any implementation partner, including DeployOpen, for a fixed-scope written proposal with deliverables and timelines before work starts, and compare that one-time cost against the years of HCP subscription you would avoid.
What moving from HCP Vault Dedicated to OpenBao involves
The sequence turns a managed Vault Enterprise cluster into a self-operated OpenBao deployment, with each step producing an inventory, a tested target or a verified cutover. Because the documented OpenBao migration path was tested only against Vault 1.14.1 Community, every HCP Dedicated move needs its own validation before production traffic shifts.
Inventory secrets, auth methods, policies and namespaces
Your team, with help from the cluster administrators, lists every secrets engine mount, auth method, policy, namespace, audit device and identity entity in the HCP Vault Dedicated cluster. Export the policy and auth configuration through the API so you have a readable record, and tag each item as portable, needs rework or has no OpenBao equivalent. Namespaces are a Vault Enterprise feature, so map each one to an OpenBao namespace design or to separate paths and policies. The output is a signed-off inventory that names every consumer of every secret, which becomes the cutover checklist.
Export secrets through the API
Plan the data path before any restore. Raft snapshots from a Vault cluster restore only into the same cluster with the same unseal keys, so they do not move secrets into a new OpenBao deployment. Instead, read secrets and configuration out through the API under a controlled, audited process, and store the export in encrypted form with restricted access and a documented destruction date. Confirm with HashiCorp what HCP Dedicated gives you for data retrieval and what support it offers during an exit. The output is a complete export with a checksum count that matches your inventory, held in a location your security team has approved.
Stand up OpenBao in a test environment
Deploy OpenBao in a non-production environment in your own cloud account or data center, using the OpenBao Helm chart if you run Kubernetes, which requires Helm 3.6 or later. Choose the storage backend (integrated Raft storage or PostgreSQL) and the unseal method you will operate, and set up high availability, backups and audit logging in the same way you will in production. Ask your provider or internal team to confirm the recommended storage option for your scale. The output is a working test cluster with documented configuration, tested backup and restore, and an operations runbook.
Validate plugins and auth mounts OpenBao does not ship
Compare each secrets engine plugin and auth method from the inventory with what OpenBao ships. The migration guide notes that mounts using plugins OpenBao does not ship are skipped, so any HCP-specific or third-party plugin needs a replacement, a custom build or a redesign. Restore the supported auth methods (such as AppRole, JWT/OIDC, Kubernetes, LDAP or TLS certificates) and test a real login for each consumer. Because the OpenBao migration guide was tested only against Vault 1.14.1 Community, treat every HCP Dedicated move as unverified until your own test run passes. The output is a gap register with each gap closed, accepted or escalated, and a test log for every auth method.
Load secrets and rehearse the client changes
Import the exported secrets into the test OpenBao cluster and reproduce the policies and auth configuration. Update one non-production client at a time: application configuration, Vault Agent or OpenBao-compatible agents, CI pipelines and Kubernetes injectors. Check the token format change, because OpenBao issues new tokens in a shorter format, and confirm that any code parsing token strings or relying on Vault-specific paths still works. Run application smoke tests and dynamic secret requests to confirm leases and revocation behave as expected. The output is a rehearsal report that lists each client, the change made and the test that proved it works.
Cut over production clients in a planned window
Freeze configuration changes on the HCP Vault Dedicated side, load the final secret set into production OpenBao, and switch clients in the order set by your inventory, starting with the lowest-risk workloads. Keep HCP Vault Dedicated readable during the transition so you can roll back a client quickly. Monitor authentication failures, lease errors and audit logs for each batch before moving the next. Confirm that revocation and rotation still reach the systems that depend on them. The output is a cutover log showing every client on OpenBao and a signed confirmation from the application owners.
Decommission HCP Vault Dedicated and close the exit
Once every client has run on OpenBao through an agreed observation period, revoke remaining tokens and access on HCP Vault Dedicated, cancel or amend the subscription according to your contract terms, and confirm the end date in writing with HashiCorp. Remove stored credentials for the old cluster from CI systems and password vaults, and retain the final export and audit records under your retention policy. Update the runbooks, disaster recovery plan and access reviews to name the OpenBao owners. The output is a written decommission record, a list of revoked credentials and an updated architecture document that shows where the secrets now live.
Questions buyers ask before choosing or hiring help
How much does self-hosting OpenBao cost compared with HCP Vault Dedicated?
The honest comparison is by component, because HCP Vault Dedicated is quoted rather than published and self-hosting has no single license line. HCP costs are the managed subscription, which HashiCorp prices by quote. Self-hosted OpenBao costs are the infrastructure to run the cluster (compute, storage, load balancing, backups and a second region if you need one), an unseal method such as an HSM or cloud KMS, monitoring, and the staff time to operate, patch and upgrade it. Implementation is a one-time cost. Recurring costs are infrastructure and people. Ask any vendor, including DeployOpen, for a written quote that lists each component separately, and ask HashiCorp for an HCP Vault Dedicated quote for the same node count, region and support level so the two can be compared line by line.
How long does a migration from HCP Vault Dedicated to OpenBao take?
Duration depends on scope, which secrets engines and auth methods are in use, how many applications and agents must be repointed, whether validation and a parallel run are required, and the cutover window your change process allows. No general duration is safe to quote. The OpenBao migration guide documents an in-place, node-by-node upgrade from Vault Community 1.14.1 on Raft storage, but it was tested only against that version. A cluster that started on HCP or Enterprise needs a different path, so a discovery phase should come first. Ask for a fixed-scope proposal with a written list of deliverables, test cases, a cutover plan and a rollback plan before any timeline is agreed.
Can our own platform team run OpenBao without an outside partner?
Yes, if the team has the skills for the work. Running OpenBao well means operating a Raft or PostgreSQL high availability cluster, configuring unseal and key custody, writing policies and auth methods, managing TLS and backups, monitoring the cluster, and rehearsing restores and upgrades. Security engineers need to own policy design, audit logging and access reviews. Many teams can cover this in house, while others prefer to bring in help for the first migration and then keep the skills internally. Whichever model you choose, document who is on call for the cluster and who approves upgrades before go-live.
Who patches OpenBao, and how often are new releases published?
You do. OpenBao is open source, so the software is free to use, but the operator is responsible for applying updates to their own cluster. The OpenBao releases page is the place to track changes. Release v2.7.1 was published on October 1, 2026 with security fixes, and v2.6.4 was released the same day for the previous minor line. Your process should cover monitoring release notes, testing each update in a non-production cluster, scheduling node-by-node upgrades, and confirming the cluster is healthy afterwards. Managed options such as HCP Vault Dedicated move much of this work to the vendor, which is a real trade-off to weigh against cost.
Does OpenBao support Enterprise features such as replication?
Some capabilities are documented in OpenBao and some Vault Enterprise features are not carried over, so confirm each one against the current OpenBao documentation before you plan around it. The Vault Enterprise documentation lists performance and disaster recovery replication, HSM support, namespaces, performance standby nodes, seal wrapping, FIPS compliance, control groups, Sentinel policy as code, and automated upgrades as licensed features. OpenBao documents namespaces and high availability with read-only standbys, which covers part of the need. Replication, Sentinel, control groups and automated upgrades need a specific check against your requirements. Ask for a written feature mapping that marks each Enterprise feature you use as supported, partly supported or not available.
What does DeployOpen do for an OpenBao project, and what does it not do?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenBao, that can include the cluster design, migration planning, auth and policy setup, backup and restore testing, and runbooks. DeployOpen also runs security testing and prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, since independent auditors and certification bodies do that work. DeployOpen is also not a HashiCorp or IBM partner or reseller. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers, and quotes follow from the written scope.
How to decide in four checks
Four ordered checks test where your secrets must live, whether you depend on Enterprise features, whether your team can run the cluster, and where your current Vault stands, ending with a clear path toward HCP Vault Dedicated or OpenBao.
Confirm data location and key custody rules
Security, legal and the data protection owner list where secrets and unseal material may be stored, which regions and cloud accounts are allowed, and who must hold the keys. Your architecture lead checks each requirement against the HCP region options and the cloud accounts or data centers where OpenBao would run. If a rule requires that secrets and unseal keys stay in your own accounts or networks, the result points to OpenBao. If the rule accepts a managed service in an approved HashiCorp region and the key custody terms are documented in writing, the result points to HCP Vault Dedicated. Ask HashiCorp to confirm in writing where HCP stores data and who can access it, and record the answer in the decision file.
List Enterprise features you actually use
Your platform team inventories the Vault features in use today, such as namespaces, performance or disaster recovery replication, HSM seal support, seal wrapping, Sentinel policies, control groups, FIPS mode, automated snapshots and secret syncs. Each feature is marked as required, nice to have or unused. HCP Vault Dedicated runs the Enterprise binary, so required Enterprise features keep you on HashiCorp's side, which points to HCP Vault Dedicated. If the required list is empty or covered by OpenBao capabilities such as namespaces and standard auth methods, the result points to OpenBao. Confirm each remaining feature against the OpenBao documentation before you mark it as covered.
Assess staff capacity to operate and patch
The infrastructure lead estimates who will run the cluster: installing, upgrading, backing up, monitoring, rotating unseal material, responding to security releases and handling incidents. Self-hosted OpenBao means your team, or a contracted partner, owns those tasks along with the storage backend, load balancers and any HSM or cloud KMS for auto-unseal. If you have people on call for this platform and a documented upgrade routine, the result points to OpenBao. If no one can own these tasks on a continuing basis, the result points to HCP Vault Dedicated, where HashiCorp operates the service. Write down named owners and the review cadence before moving on.
Check your current Vault version and storage
Your Vault administrator records the exact Vault version, edition and storage backend. The OpenBao migration guide documents an in-place, node-by-node upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and it was tested only against that version. If you run that exact combination, the migration path to OpenBao is documented, which points to OpenBao. If you run a later Vault version, Vault Enterprise, a different storage backend or auto-unseal, the migration needs a planned data move and extra testing, so the result points to a more careful review of both options. Confirm plugin and auth method coverage with the OpenBao project before deciding, and confirm HCP migration options with HashiCorp.
Compare total cost and document the decision
Finance and the platform lead compare two cost lines. HCP Vault Dedicated is priced by HashiCorp quote, so request a written quote for the cluster size and term you need. OpenBao carries no license fee, but you pay for compute, storage, backups, monitoring, any HSM or KMS service, staff time and possibly third-party support. Ask each vendor what drives cost upward, such as cluster size, number of regions, replication and support tier. Record the decision, its reasons and the result of each check in one document, and share it with security and compliance for sign-off. The output is a signed decision record that names the chosen path and the owners for the next step.
How DeployOpen helps you evaluate, implement or migrate OpenBao
DeployOpen plans, implements, hardens, backs up and documents self-hosted OpenBao inside your own cloud accounts, data centers or air-gapped networks. We start by testing your current HCP Vault Dedicated dependencies against the features and gaps described on this page, so the decision rests on your environment rather than on a general comparison.
How we scope
- We inventory the HCP Vault Dedicated features your teams use, such as auth methods, secrets engines, replication and policies.
- We confirm which Enterprise-only features need an open-source replacement or a documented workaround before any build starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We design the OpenBao high availability layout, choosing integrated storage (Raft) or PostgreSQL based on your operating model.
- We set up unseal, backup and network controls in your infrastructure, and test failover before production use.
- We run security testing against the deployment and document the configuration, including authentication and access policies.
How we hand over
- We deliver runbooks covering upgrades, unseal procedures, snapshot restores and incident response for your own staff.
- We document which operations your team owns after handover, including patching, OpenBao version upgrades and client updates.
- We prepare control and evidence material for compliance assessments, while independent auditors issue any formal opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover monitoring of OpenBao releases and planned upgrades, with scope agreed in writing.
- Ask for a written quote that lists scope, deliverables, exclusions and the recurring support terms before signing.
