Should you stay on HashiCorp Vault or move to OpenBao?
Stay on HashiCorp Vault if you need Vault Enterprise features such as namespaces or replication, or vendor support, and your budget and contract can absorb them. Move to OpenBao if you want MPL 2.0 licensing, community governance and a fork you can run without depending on HashiCorp's roadmap. Vault Community suits teams that use no enterprise features and accept the Business Source License 1.1 terms that HashiCorp applied to future releases after its August 10, 2023 announcement. Vault Enterprise and HCP Vault Dedicated suit teams that need namespaces, replication or a commercial support contract. OpenBao suits teams that want a Linux Foundation-stewarded project under MPL 2.0 and are prepared to operate it.
Many teams reach this question at a renewal, a licensing review or when IBM's ownership, which completed on February 27, 2025, raises questions about the product's direction. Start by inventorying which Vault edition you run and which features are active, including namespaces, replication, Sentinel policies, secrets sync and HSM auto-unseal. Each of these either has an OpenBao counterpart, has a documented gap or needs a separate project, so the list of features in use often decides the answer more than the license does. Confirm the exact Vault version too, because OpenBao's documented in-place upgrade path was tested only from Vault Community 1.14.1 on Raft storage with Shamir unseal.
The decision then turns on three things: which Vault edition and features your teams depend on, where your data must reside, and how much internal capacity you have to run, patch and back up a secrets cluster. A self-hosted OpenBao deployment keeps secrets inside your own infrastructure, but your team or a partner carries upgrades, unseal key handling and incident response that a managed HCP service would otherwise take on. Ask your Vault account team for a written statement of the features and support terms in your current contract, and test OpenBao against a non-production copy of your highest-value mounts before you commit.
Which option fits which situation
This table maps common situations to the option that fits best, with the condition that makes each choice correct. Read it against your current Vault edition, license obligations and whether you need Enterprise features or a support contract. Confirm feature availability for your exact Vault version before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| Running Vault Community with no Enterprise features in use | Stay on Vault Community | Choose this when you use only Community capabilities and your license terms under the Business Source License 1.1 are acceptable to your legal team. Confirm the terms for your use case. |
| Needing multi-tenant namespaces and replication from HashiCorp | Vault Enterprise or HCP Vault Dedicated | Choose this when namespaces, replication or other Enterprise features are required and you accept a quote-based subscription. Confirm the exact feature list with HashiCorp. |
| Requiring a fully MPL 2.0 licensed secrets manager | OpenBao | Choose this when your policy mandates MPL 2.0 for the components you run. OpenBao's repository is licensed under MPL-2.0, while newer Vault releases fall under the Business Source License 1.1. |
| Operating a Vault 1.14.1 cluster on Raft with Shamir unseal | OpenBao | Choose this when your cluster matches the version, storage and unseal method OpenBao's migration guide documents. Test the in-place upgrade in a non-production copy first. |
| Depending on Vault Enterprise-only features such as HSM auto-unseal or secrets sync | Stay on Vault Enterprise, or plan a redesign | Choose this when a feature you rely on has no OpenBao equivalent in your version. Confirm each feature gap in OpenBao's documentation before you commit to a migration. |
| Needing a vendor support contract with a single accountable supplier | Vault Enterprise or HCP Vault Dedicated | Choose this when procurement or your risk policy requires a commercial support agreement. OpenBao is community-driven, so you would need to contract a third-party provider for support. |
What the BSL change and IBM ownership mean for your roadmap
On August 10, 2023, HashiCorp announced that all future releases of its products would move from the Mozilla Public License 2.0 to the Business Source License 1.1. Its APIs, SDKs and most libraries stayed under MPL 2.0, and the main restriction targets vendors that offer competitive services built on HashiCorp products. For most internal users of Vault, that restriction is not the question. The question is which edition you will run after the next upgrade, because Vault Community, Vault Enterprise and HCP Vault Dedicated are sold and licensed differently. Check the HashiCorp announcement and have counsel confirm how the BSL applies to your specific use, including any embedded or customer-facing use.
IBM completed its acquisition of HashiCorp on February 27, 2025. Before renewing or planning an upgrade, ask IBM and HashiCorp, in writing, several questions: whether the Community edition's feature set and license terms will change, which Enterprise features they plan to move between editions, how list and renewal pricing will be set for your term, whether HCP Vault Dedicated will keep its current scope, and what notice period applies to end-of-life decisions. Ask for the roadmap commitments that apply to your contract rather than relying on public statements. Record the answers, since they will matter if your procurement team needs to justify a move later.
OpenBao is licensed under MPL 2.0, the same file-level copyleft license HashiCorp used for Vault before the change. It is a Sandbox project of the Open Source Security Foundation (OpenSSF) under Linux Foundation stewardship and is led by a community operating under open-governance principles. Sandbox status is an early stage in the OpenSSF project lifecycle, so assess the project's maturity, release history and maintainer depth against your own risk tolerance. Confirm the current governance documents, contributor base and security response process directly with the project. Any decision that depends on how a license applies to your products, customers or hosting model should go to legal review before you commit.
Where OpenBao has gaps you must check before switching
OpenBao covers most of the secrets engine and auth surface teams use day to day, but several Vault Enterprise capabilities either do not exist in OpenBao or do not carry over automatically. Each card below names one component, the condition under which it matters for your estate, and what to confirm with the vendor or in a test cluster before you commit to a cutover.
Enterprise namespaces versus OpenBao namespaces
Vault Enterprise namespaces isolate tenants, policies and auth mounts inside one cluster, and teams often rely on them for business-unit separation. The gap matters if your namespace hierarchy uses Enterprise-only behavior, such as replication scoping or per-namespace features you depend on. Map every namespace, its policies and its auth mounts to the OpenBao namespace model, then confirm in a test cluster that tokens, policy paths and identity aliases resolve the same way. Ask the OpenBao community which namespace features are present in the release you plan to run.
Replication and performance features
Vault Enterprise offers replication and performance features for multi-region reads and disaster recovery. OpenBao's documented high availability model centers on a single active node with standbys, and read scaling for standbys is documented for Raft and PostgreSQL. This gap matters if your recovery objectives depend on cross-region replicas or on failover behavior you configured in Enterprise. Document the RPO and RTO you need, then test failover and restore in a staging cluster before retiring the Enterprise setup.
Plugin and auth method gaps from the migration guide
The migration guide states that mounts using plugins OpenBao does not ship are skipped during the in-place upgrade, and it was tested only from Vault Community 1.14.1 on Raft with Shamir unseal. This matters if you run third-party or Enterprise-only secrets engines or auth methods. Inventory every mount with vault secrets list and vault auth list against your current cluster, then confirm each one has an OpenBao equivalent or a replacement path before you upgrade.
HSM seal support
Teams that pay for Vault Enterprise to auto-unseal with an HSM need to know that OpenBao offers a PKCS#11 seal plugin, but a Vault HSM seal is not expected to carry over without a data migration. This matters if your unseal keys or recovery keys live in an HSM partition. Confirm with the OpenBao project which HSMs are tested, create the key material in the HSM before cutover, and rehearse the unseal procedure in a non-production cluster.
Secrets sync to cloud stores
Vault secrets sync to AWS, Azure, GCP, GitHub Actions and Vercel requires Vault Enterprise or HCP Vault Dedicated. Without it, OpenBao has no built-in push of secrets into those stores, so consumers that read from cloud-native stores need an external process. This gap matters if pipelines or serverless functions depend on synced copies. Inventory each sync target, choose between an external sync job and a different tool, and test rotation propagation end to end before retiring the Enterprise sync.
Support contracts and upgrade ownership
Vault Enterprise comes with a vendor subscription and support terms that are quoted by HashiCorp. OpenBao is community-led under open governance, so there is no single vendor contract to replace that support. This matters if your audit or change-control process requires a named support party for security fixes and incident response. Decide who patches OpenBao, who monitors releases, and whether you need a third-party support agreement, and ask any provider for written response commitments before go-live.
Data location, hosting models and compliance implications
Self-managed Vault runs in your own cloud account, data center or network, and secrets are stored in the storage backend you configure, typically integrated Raft storage in the Vault cluster. Your team owns the nodes, the storage volumes, the seal configuration and the upgrade schedule. HashiCorp supplies the binaries and, for Enterprise, the support contract and features, but it does not hold your secrets in this model.
- Secret location: Encrypted secrets sit on storage you operate, and backups and snapshots are copies you must place, encrypt and control.
- Unseal material: Your organization generates and stores the Shamir keys or the auto-unseal key reference, and must document who can reconstruct them.
- Patching: Your team applies Vault releases and security fixes on its own timeline, and must track HashiCorp advisories for the version you run.
- Licensing terms: Current Vault releases fall under the Business Source License 1.1 as of the 2023 announcement, so confirm with counsel whether your use is permitted before you depend on it for a service.
- Evidence: Expect to provide configuration baselines, access policies, audit device logs and change records for each node.
Ask HashiCorp and your legal team which Enterprise features, if any, your compliance scope depends on, and confirm the license terms that apply to your deployment.
HCP Vault Dedicated is HashiCorp's managed service, which runs the Vault Enterprise binary in a HashiCorp-operated environment. Your secrets live in the cloud region and network you select within HashiCorp's service, and HashiCorp operates the cluster, including availability and upgrades. Your data location and provider responsibilities must be read from HashiCorp's contract and documentation, not inferred from this page.
- Secret location: Secrets are stored in HashiCorp-managed infrastructure in the region you choose, so you depend on the provider's data handling terms.
- Unseal material: HashiCorp operates unsealing for the managed cluster, so confirm with the vendor how keys are protected and who can access them.
- Patching: HashiCorp applies upgrades to the managed cluster, and your team coordinates maintenance windows and client changes.
- Subscription terms: Pricing is quote-based, and the contract defines support, service levels and audit reports available to you.
- Evidence: Request the provider's third-party assurance reports and the shared responsibility matrix, then document your own controls for client access, network paths and key rotation.
Ask HashiCorp which assurance reports cover the service, in which regions the service runs and whether your data residency requirement can be met in writing.
Self-hosted OpenBao runs inside your own cloud account, data center or air-gapped network. Because OpenBao is open source under MPL 2.0, no vendor operates the cluster or holds your secrets, and every location, key and patch decision sits with your organization or the implementation partner you choose. This model gives the strongest control over data residency and isolation, and it places the full evidence burden on your team.
- Secret location: Encrypted secrets go to the storage backend you select, such as integrated Raft storage or PostgreSQL, in the location you approve.
- Unseal material: Your organization generates, splits and protects unseal keys or uses a KMS or HSM for auto-unseal, and records custody for each key holder.
- Patching: Your team or DeployOpen applies OpenBao releases, such as the v2.7.1 security fix line, and tests them before production.
- Air-gapped operation: Plan how packages, plugins and container images enter the isolated network and how advisories are reviewed.
- Evidence: Assemble configuration baselines, key custody records, access reviews, backup restore tests and patch records for the auditor.
DeployOpen prepares controls, configurations and evidence for your compliance assessment, but it does not issue audit reports, attestations or certifications, which come from independent auditors and certification bodies.
How much operating effort OpenBao asks of your team
OpenBao runs as a cluster with one active node and one or more standby nodes. The active node holds a lock in the data store, and standbys forward or redirect requests to it. Integrated storage (Raft) and PostgreSQL are the officially supported high availability backends, and the storage choice is the first operating decision you make. The OpenBao storage documentation describes PostgreSQL as easier to operate safely than Raft, which matters if your team does not already run Raft clusters. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended that to PostgreSQL, so read scaling is now available on both backends. Confirm in a test environment how your clients behave when they hit a standby, because read-only behavior is not the same as write availability.
Release cadence determines how often you will touch the cluster. OpenBao v2.7.0 was released on September 23, 2026, v2.7.1 on October 1, 2026 with security fixes, and v2.6.4 the same day for the previous minor line. Before you plan a maintenance window, check the OpenBao releases page for the current patch level and any security notes, and decide which minor line you will run and how quickly you will apply patch releases. Your team owns the operating system, the OpenBao binary, the storage backend, TLS certificates and the Helm chart or service unit that deploys them.
Three duties stay with your team regardless of who installs the cluster. First, backups of the storage backend must be scheduled, tested by restore and kept outside the cluster. Second, unseal key handling needs a documented custodian model, with key shares held by named people or stored in an HSM or cloud KMS for auto-unseal, and a rehearsed procedure for an unseal after a restart. Third, patching and upgrades need a runbook that covers standby nodes first, a failover check and a rollback path. If you use DeployOpen for implementation, these duties can be scoped in writing, and the scope should name the backup targets, the unseal model and the upgrade procedure explicitly.
Cost components on each side and what drives them
This section sets out what you pay for on each side. HashiCorp does not publish Vault Enterprise or HCP Vault Dedicated prices in the sources used here, so no figures appear. DeployOpen does not publish prices either: a quote follows from a written scope, so ask for one built from the components below.
Vault subscription or HCP quote
Vault Enterprise is a self-managed subscription, and HCP Vault Dedicated is HashiCorp's managed service. Both are priced by quote, and the HashiCorp pricing page confirms that Enterprise and HCP pricing are available by quote. Ask which metrics drive the quote, what the support tier includes, how upgrades are billed and how renewal terms change the price. OpenBao removes this recurring line, but the staff, support and infrastructure lines below still apply.
Nodes and storage for high availability
Both sides run a cluster with an active node and standbys, so compute capacity is similar on your own servers. OpenBao supports integrated storage (Raft), PostgreSQL, PebbleDB and in-memory storage, and its documentation describes PostgreSQL as easier to operate safely than Raft. Choosing PostgreSQL adds a database to run, back up and patch, though your team may already operate one. Count node count, disks or database capacity, snapshot retention and disaster recovery copies. Confirm your current storage backend before pricing the target.
Auto-unseal hardware or key service
Auto-unseal removes manual unseal key handling after a restart. Vault Enterprise offers HSM-based auto-unseal as an Enterprise capability, and OpenBao provides a PKCS#11 seal plugin for HSMs. Each choice carries its own cost: HSM hardware and support, or a key service with usage charges, plus the role that manages key custody. Confirm which seal options your OpenBao version supports and whether your HSM models are tested with it before you order hardware.
Third-party support contracts
Vault Enterprise support is part of the Enterprise subscription, so confirm exactly what your agreement covers. OpenBao is open source with no vendor subscription, so support comes from an internal team or a contracted service provider. Ask any provider for response times in writing, the versions it covers, whether it handles upgrades and incident response, and how it bills across development, staging and production. This line is recurring and grows with the number of clusters you operate.
Internal staff time
Someone owns upgrades, certificate rotation, unseal and recovery procedures, backups, restore tests and audit log handling. Under HCP Vault Dedicated, HashiCorp operates the platform, which shifts much of this work. Estimate staff time from your own runbooks and on-call rota rather than from vendor figures. Include the cost of covering the secrets service out of hours, because an outage affects every application that reads secrets at runtime.
One-time migration project
Moving to OpenBao is a one-time project covering assessment, test clusters, the upgrade itself, updates to clients, agents and Kubernetes injectors, and a rollback plan. OpenBao's guide describes a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft with Shamir unseal, and states it was tested only against that version. Later Vault versions and Enterprise features need a separate assessment. DeployOpen scopes such work in writing before it starts, so ask for a fixed-scope quote with named deliverables.
What a move from Vault to OpenBao involves
The sequence takes a Vault deployment from an inventory of editions, mounts and clients to a validated OpenBao cluster, with each step producing a record you can check before moving on. It separates the documented upgrade path from the cases that still need their own assessment.
Inventory editions, mounts and plugins
Your platform or security team records the exact Vault edition and version on every node, the storage backend, the unseal method, and every enabled secrets engine, auth method and plugin. Confirm whether any cluster runs Vault Enterprise or a version other than Vault Community 1.14.1, because the documented in-place path covers only that combination. Done when you have a written inventory signed off by the owners of each cluster.
Check the inventory against the migration guide
Compare the inventory with the OpenBao migration guide. The guide documents a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and states that it was tested only against that version. Mounts that use plugins OpenBao does not ship are skipped, so list each one and decide whether it is replaced, removed or handled separately. Done when every cluster is marked as either on the documented path or requiring separate assessment.
Plan plugin, token and client changes
Assign owners for the skipped plugins and the replacements you will use. Note that new tokens use a shorter OpenBao format, so any code that parses, stores or validates Vault token strings needs review. List every client, Vault Agent instance and Kubernetes injector, and the configuration each one needs to point at OpenBao. Done when the change list has an owner and a test for each item.
Rehearse in a non-production cluster
Build a non-production cluster that mirrors the production edition, storage backend, unseal method and mount set. Run the node-by-node upgrade there, then exercise the clients and workloads from your change list. For Kubernetes, install OpenBao with the Helm chart, which requires Helm 3.6 or later, and test the injector path. Done when the rehearsal completes without manual repair and each workload reads its secrets.
Run the node-by-node upgrade
Upgrade the standby nodes first, then the active node, one at a time, checking cluster health and the unseal state after each node. Keep Shamir unseal keys and a current Raft snapshot available before the change window opens, and keep a documented rollback path. Done when every node reports as healthy in the OpenBao cluster and the mount list matches the inventory, minus the skipped plugins.
Validate secrets, leases and access
Confirm that key/value data reads correctly, that existing leases and dynamic secret roles behave as expected, and that auth methods accept logins from the expected identities. Check audit logging and monitoring, since your dashboards and alerts may depend on Vault-specific metrics or log fields. Done when your test cases pass and the results are recorded in the change record.
Cut over clients and retire Vault
Repoint clients, agents and injectors to OpenBao in a planned window, starting with the lowest-risk workloads. Keep the Vault cluster in read-only standby until the cutover is complete and the rollback window your team set has passed. Done when all workloads authenticate to OpenBao, the old Vault endpoints receive no traffic, and the decommission plan is approved by the data owners.
Questions buyers ask before switching from Vault
Can we migrate from Vault to OpenBao ourselves or do we need a partner?
You can migrate yourself if your cluster matches the documented path, and many teams do. The OpenBao migration guide describes a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and the project states it was tested only against that version. If you run a later Vault release, an Enterprise cluster, a different storage backend or auto-unseal, the work moves from a documented upgrade to a design exercise. Read the OpenBao migration guide first, then decide whether your gaps justify outside help. DeployOpen plans, implements and hardens self-hosted platforms in your own environment under a written, fixed scope, so the question is whether your team has the time and the Vault expertise to own the cutover.
What does a Vault to OpenBao migration need from our team?
Expect the work to need people who understand your Vault policies, auth mounts, secret engines and every client that reads secrets. The main contributors are the platform team that runs the cluster, a security owner who approves access and key handling, and application owners who re-point clients, agents and Kubernetes injectors. The migration guide notes that mounts using plugins OpenBao does not ship are skipped, and that new tokens use a shorter OpenBao format, so someone must inventory plugins, token consumers and any code that parses token strings. Your team also needs a tested rollback plan and access to the unseal material during the change window.
How long does a migration to OpenBao take?
Duration depends on the factors that drive the work, not on a standard timeline. The main drivers are the number of clusters, the Vault version you run, whether you use Raft or another storage backend, how many auth methods, secret engines and plugins you have, how many clients must be updated, and how much testing your change process requires. A single cluster with a short list of clients is a different project from a multi-region estate with dozens of consumers. Ask any provider, including DeployOpen, for a timeline built from a written inventory of your environment, and confirm it against your own change calendar.
Does OpenBao support our Vault Enterprise namespaces and replication?
OpenBao documents namespaces as a way to isolate tenants inside one cluster, so teams that use Vault Enterprise namespaces for multi-tenancy should check the OpenBao namespaces documentation against their own layout. Map each Enterprise namespace to an OpenBao namespace, then compare policies, auth mounts and secret engines one by one. Replication is a separate question. Vault Enterprise performance and disaster recovery replication are not the same feature set as OpenBao's high availability design, which uses an active node with standby nodes and supported backends of integrated storage (Raft) and PostgreSQL. Confirm each replication requirement in writing before you commit to a design.
Is the OpenBao Helm chart the right install path on Kubernetes?
For most Kubernetes installs, yes. The OpenBao Helm chart is the project's recommended way to install OpenBao on Kubernetes, and it requires Helm 3.6 or later. Confirm your cluster's Helm version before you plan the install. The chart does not replace the decisions you still own: storage backend choice, unseal method, TLS, network policy, backup of the storage layer and how Kubernetes auth is configured for your workloads. Review the OpenBao Helm chart guide and pin chart and OpenBao versions in your deployment code so upgrades are deliberate.
Does moving to OpenBao change our compliance evidence?
Yes, the evidence changes because the software, its release and patch records, its configuration and its governance all change. Your control design may stay the same, but auditors will ask for proof about the new platform: version history, the security fix process for each release, access logs, key ceremony records and change approvals for the cutover. OpenBao's current release, v2.7.1, was published on October 1, 2026 with security fixes, so document how you track releases and apply them. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations, so agree the evidence plan with your assessor before the migration starts.
Does OpenBao's license and governance change our long-term risk?
OpenBao is licensed under MPL-2.0 and is a Sandbox project of the Open Source Security Foundation under Linux Foundation stewardship, so its code and governance differ from Vault's Business Source License terms for newer releases. The licensing question matters most if you plan to build or offer services on the software or if you depend on a vendor roadmap. Read the license terms yourself and ask your legal team to review them. Also note that a Sandbox project is an early stage of the foundation's process, so assess the community's activity and release record against your own support needs.
What support options exist for self-hosted OpenBao after migration?
Support options fall into three groups: your own staff, a vendor or consultancy with a written support scope, and the open-source community. Each has different cost and response characteristics. Your internal team pays through salaries and on-call rotations. A support contract or retainer is quoted from the scope you agree in writing, and DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Ask any provider which OpenBao versions they cover, how they handle security releases and what their response expectations are in writing before you sign.
What a DeployOpen engagement covers
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted OpenBao inside your own infrastructure, whether that is your cloud accounts, a data center or an air-gapped network. For a Vault-to-OpenBao decision, the work typically includes confirming the Vault version and storage backend you run today, choosing between integrated storage (Raft) and PostgreSQL for high availability, setting up unseal and key custody, mapping auth methods and policies, and documenting the cluster so your own staff can operate it. DeployOpen also runs security testing against the resulting deployment, covering the cluster, its APIs and the integrations that call it. Confirm with us which of these items your environment actually needs before the scope is written.
Engagements are fixed-scope. Before any work starts, we agree in writing the scope, deliverables, timelines and the responsibilities on each side, including which parts of a migration your team performs and which parts we perform. Items that depend on your environment, such as client re-pointing, plugin inventory or the handling of Enterprise-only features, should be named explicitly in that scope so nothing is assumed. Ongoing support, upgrades and continuous testing are available as a retainer after the initial work, which is useful if you want a partner to track OpenBao releases and apply them on your schedule.
A quote follows from the written scope. DeployOpen does not publish a price list, so the most useful input you can give us is an inventory: your current Vault edition and version, the number of clusters, storage type, secrets engines and auth methods in use, and the consumers that read secrets. DeployOpen is not a vendor partner, reseller or certified provider of HashiCorp, IBM or the OpenBao project. Any licensing for OpenBao is obtained directly from the project under its open-source terms, and any Vault Enterprise or HCP subscription remains a separate contract with HashiCorp.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For HashiCorp Vault vs OpenBao, we start from your current Vault edition, your data location needs and the features your applications depend on, then turn that into a written scope.
How we scope
- We inventory your current Vault edition, storage backend, auth methods, secrets engines and Enterprise features in use.
- We map each dependency to OpenBao capabilities and flag gaps, such as namespaces, replication or HSM seals, for confirmation before work starts.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work begins.
How we build
- We plan the target OpenBao topology, including high availability design on integrated storage or PostgreSQL inside your network.
- We test the upgrade path in a non-production copy, checking mounts, plugins, client authentication and token behavior.
- We configure auth methods, policies and seal options, then run security testing against the deployed cluster before go-live.
How we hand over
- You receive documentation of the architecture, configuration, backup and restore procedures and the runbook for your team.
- We walk your operators through upgrades, release tracking and the steps for updating clients, agents and Kubernetes integrations.
- We prepare control and evidence material for your compliance assessments, while independent auditors perform the actual assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover patching against OpenBao releases, backup verification and periodic security testing of the cluster.
- Ask any provider, including us, to confirm in writing which Vault features are supported, what changes and who maintains each component.
