Which open-source alternative to HashiCorp Vault fits your team
If you are renewing a Vault contract, reacting to a licensing change, or trying to keep secrets inside a jurisdiction or network you control, OpenBao is the closest open-source fork of Vault and is licensed under MPL 2.0. Other options fit other workloads, so the right choice depends on whether you need a drop-in continuation of Vault's API and policies or a different model for a specific platform. Teams review Vault for two documented reasons. On August 10, 2023, HashiCorp announced that future releases of its products would move from the Mozilla Public License 2.0 to the Business Source License 1.1, while its APIs, SDKs and most libraries stay under MPL 2.0 (HashiCorp's announcement). On February 27, 2025, IBM completed its acquisition of HashiCorp (IBM's announcement). Neither event changes what your current binaries do, but both change what you can rely on for future releases, and your legal and procurement teams should read the license text for the versions you plan to run.
Vault is offered as the free Community edition, self-managed Vault Enterprise, and the managed HCP Vault Dedicated service. Enterprise and HCP pricing are available by quote only, so this page does not compare figures. Ask for written quotes that list the feature set, node count, support level and term, and compare them with the cost of operating your own cluster. Those operating costs include engineers' time for upgrades, unseal procedures, backups and on-call coverage, which recur every year, and the one-time cost of migration and policy rewrites. Confirm with each vendor which features they require for your use case, because some capabilities have been Enterprise-only in Vault.
Open-source options that replace Vault and what each one costs you
Teams leaving or reconsidering Vault usually choose between a community fork that keeps Vault's API, a different secrets model with its own policies, or keeping an older Vault build. Each option carries a different licence, migration effort and ongoing maintenance load, so the cost comparison depends on which one you choose.
OpenBao under MPL 2.0
OpenBao is a community fork of Vault, managed under the Linux Foundation's OpenSSF and licensed under MPL 2.0. Its backers include SAP, GitLab, Adfinis and Proton. The most recent release cited in the supplied sources is v2.7.1, released October 1, 2026. Its migration guide describes a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and that path was tested only against that version. Confirm your exact Vault version and storage backend before planning.
Fork maintenance responsibility
Running OpenBao means your team or your provider tracks upstream security fixes, applies upgrades and tests them against your own mounts and integrations. Cost sits mainly in staff time and test environments rather than licence fees. Ask any implementation partner who owns patch cycles, how emergency fixes are rolled out, and whether backups are tested before each upgrade.
Plugin and token format gaps
The migration guide states that mounts using plugins OpenBao does not ship are skipped during upgrade, and new tokens use a shorter OpenBao format. Any integration that parses token strings or depends on a non-shipped plugin needs rework or replacement. Inventory every enabled secrets engine, auth method and plugin, and confirm each one exists in OpenBao before cutover.
Conjur Open Source policy model
Conjur Open Source server code is licensed under the GNU LGPL v3.0, with API clients and extensions under Apache 2.0. Its access model is policy-as-code and differs from Vault's paths and policies, so migrating means rewriting policies and machine identities rather than only changing the server. CyberArk sells separate commercial offerings and documents a migration path to CyberArk Secrets Manager, Self-Hosted. Check which edition your team would run and who supports it.
Staying on pre-change Vault builds
Vault releases made before the August 10, 2023 move to the Business Source License remain under their original MPL 2.0 terms. Continuing to run such a build avoids licence change but leaves you without later security fixes and features. Confirm the exact version your installation runs, since only builds that predate the change qualify, and weigh the security exposure of an unpatched release.
How each Vault capability maps to OpenBao and Conjur
This table compares the main Vault capabilities with OpenBao and Conjur Open Source, the two open-source paths most often considered. Confirm each entry against the current OpenBao feature list and release notes, and against CyberArk's Conjur documentation, before you plan a migration. Enterprise-only Vault features need separate review because they may not map one to one.
| Capability | OpenBao (MPL 2.0) | Conjur Open Source (LGPL v3.0) |
|---|---|---|
| Encrypted secret storage | Listed as a core feature; confirm storage backends and unseal method in your environment | Secrets stored encrypted in Conjur's database; confirm key handling for your deployment |
| Dynamic secrets for databases and Kubernetes | Listed as a core feature; confirm which secret engines ship and which plugins are skipped during migration | No documented one-to-one equivalent to Vault dynamic engines; confirm before planning |
| Encryption as a service | Listed as a feature; confirm the exact operations, key rotation and API parity with your Vault calls | Not a documented equivalent; applications would need to use an external encryption service |
| Identity-based access control | Listed as a feature; policy syntax is inherited from Vault, so existing policies need review | Policy-based model with its own syntax; policies and machine identities must be rewritten |
| Lease management and revocation | Listed as a feature; confirm TTL and revocation behavior for each secret type after upgrade | Different lifecycle model; confirm revocation and rotation behavior for each secret type |
| Tokens and client authentication | New tokens use a shorter OpenBao format; clients that parse token formats need updates | Uses Conjur's own authentication; Vault clients and tokens do not carry over |
| Enterprise-only features (namespaces, replication, HSM) | Not confirmed from supplied sources; check the OpenBao feature list and release notes before assuming parity | Different product structure; confirm replication, HSM and multi-tenancy options against CyberArk documentation |
How the documented in-place upgrade from Vault 1.14.1 works
The documented in-place upgrade moves a Vault cluster to OpenBao one node at a time, without standing up a parallel cluster and migrating data. The OpenBao migration guide describes this path starting from Vault Community 1.14.1 on Raft integrated storage with Shamir unseal. That combination is the only one the project states it tested, so it is the only one you should treat as documented. Each node is replaced in turn while the cluster keeps quorum, and mounts that use plugins OpenBao does not ship are skipped during the upgrade, which means you must plan a separate path for those secrets engines before you start. Read the guide at OpenBao: Migrating from Vault and map every mount in your cluster against the plugins OpenBao ships before you schedule a change window.
Confirm your environment before relying on that path. If you use Consul, a cloud KMS or HSM for auto-unseal, or any storage backend other than Raft, the tested path does not cover you, and you need written confirmation from the OpenBao project or a rehearsal in a non-production copy of your cluster. Run the upgrade first against a snapshot restored into a lab, and record which mounts, auth methods and audit devices were skipped or behaved differently. Auto-unseal and Enterprise-only features such as namespaces or replication need the same check, since their presence changes the upgrade scope.
Two changes affect operations rather than storage. New tokens issued by OpenBao use a shorter format than Vault tokens, so any client, sidecar, CI job or log parser that validates, pattern-matches or truncates tokens needs review and testing before cutover. For Kubernetes, the OpenBao Helm chart is the recommended installation route, and it requires Helm 3.6 or later, so check your Helm version and your chart values against the OpenBao Helm chart documentation before you upgrade a cluster running in a pipeline. Rollback should be planned as a restore from snapshot, and you should agree that restore procedure with your operations team in writing.
What you give up when you move off Vault and the workarounds
Moving from Vault to OpenBao is an in-place upgrade with a defined path, but it is not a feature-for-feature swap. The cards below cover the items that most often change scope: skipped plugin mounts, Enterprise-only capabilities, provider and ecosystem coverage, vendor support, and token format. Verify each one against your own mount list and license terms before you set a cutover date.
Mounts using unshipped plugins
The OpenBao migration guide states that mounts using plugins OpenBao does not ship are skipped during the upgrade. A skipped mount is not migrated, so its secrets and policies stop being served after cutover. Before you start, list every mount with vault secrets list and compare each plugin type against the OpenBao plugin catalog. For a mount with no equivalent, the usual workaround is to rebuild the plugin from source against the OpenBao plugin SDK, or to replace the mount with a supported engine and migrate the data by hand. Test both paths in a staging cluster first.
Enterprise-only features
Some capabilities you may rely on, such as namespaces, Sentinel policy enforcement, HSM or seal wrap support, replication, and certain auditing and compliance features, were licensed only in Vault Enterprise. Do not assume the fork provides an equivalent. Build an inventory of every Enterprise feature your configuration references, then confirm with the OpenBao project whether each one exists, is partial, or is absent. Where a feature is missing, the usual workaround is to move the control to an external system, such as an policy engine or a managed KMS, and document the change for your auditors.
Ecosystem and provider gaps
Your Terraform providers, Kubernetes operators, CI plugins, and client SDKs may target Vault-specific endpoints, versions, or release channels. Some integrations will continue to work because the API is compatible, while others will need new versions or new maintainers. Make a list of every integration that touches Vault, record the version each one requires, and test each against a pre-release build of OpenBao. Where an integration is unmaintained, the usual workaround is to pin your own fork or switch to a generic client that calls the HTTP API.
Vendor support contracts
Vault Enterprise and HCP Vault Dedicated come with vendor support, service levels, and a commercial escalation path. OpenBao is community-driven, so the support you rely on comes from the project, your internal platform team, or a third-party provider you contract with directly. Ask any provider for a written scope, the versions they cover, and their response commitments before you rely on them for production incidents. Confirm these points with the vendor and in your own contract, since no support terms are published here.
Token format changes
The OpenBao migration guide notes that new tokens use a shorter OpenBao format. Any tool that parses, validates, or stores token strings by pattern, including custom scripts, proxies, and secret scanners, may fail or misclassify tokens after the upgrade. Search your code, pipelines, and secret scanner rules for Vault token patterns, and test every token consumer against tokens issued by a migrated test cluster. Existing tokens and their leases should be verified during the staging run rather than assumed to behave the same way.
Migrating from Vault to OpenBao step by step
This sequence moves a Vault deployment to OpenBao with a tested fallback at each stage, so the team ends with a running OpenBao cluster, verified clients and a Vault environment retired only after a final backup.
Inventory mounts, plugins, policies and clients
The platform team lists every secrets engine mount, auth method, policy, audit device and client that reads from Vault, including CI jobs, Kubernetes operators and application SDKs. Pay particular attention to mounts that use third-party or custom plugins, because the OpenBao migration guide says mounts using plugins OpenBao does not ship are skipped during the upgrade. The step is done when each item has an owner and a status of migrate, replace or retire, and the list is reviewed against the Vault version in production.
Confirm the Vault version and storage backend
Record the exact Vault version and whether storage is Raft with Shamir unseal, since the OpenBao migration guide documents an in-place path only from Vault Community 1.14.1 on Raft storage with Shamir unseal. If your version or storage differs, treat the upgrade as a path to validate rather than a documented route, and confirm the position with the OpenBao maintainers before planning further. The step closes with a written note of the version, storage type, unseal method and any Enterprise features in use, such as namespaces or replication, which need a separate mapping.
Map policies, auth methods and Enterprise-only features
Compare each policy, auth method and secrets engine against OpenBao's documented feature set and note anything that depended on Vault Enterprise capabilities. Write a mapping sheet that lists each Vault object, its OpenBao equivalent, and any object that needs redesign. Check how client tokens and their lifetimes are handled, because new tokens use a shorter OpenBao format and any code that parses or stores token strings must be tested. The step is complete when the sheet has no unresolved entries and each open item has an owner.
Build and validate a pilot OpenBao cluster
Stand up a non-production OpenBao cluster with the OpenBao Helm chart if you run on Kubernetes, which requires Helm 3.6 or later, or with your standard server packaging otherwise. Restore a copy of a non-sensitive Vault dataset or recreate representative mounts, then run the migration steps against the pilot. Verify that the expected mounts appear, that skipped plugin mounts are logged and understood, and that a sample of dynamic secrets and leases behaves as before. The pilot is finished when the team can document every difference from production.
Test a tested backup and rollback procedure
Take a full Vault backup, verify it can be restored to an isolated environment, and rehearse the rollback path before any production change. Because the migration guide was tested only against the documented Vault version, a successful pilot does not guarantee the same result on other configurations, so the backup must be proven, not assumed. Record the restore time you observed and the people authorized to trigger rollback. The step closes when a restore from the backup has been completed and its data checked against the source.
Run Vault and OpenBao in parallel
Point a limited set of non-critical clients at OpenBao while Vault remains the system of record for production writes, and watch authentication, lease renewal and token handling in both systems. Update client code and CI variables for the new token format and confirm that secret reads, writes and revocations return the same results. Keep audit logging enabled on both sides so each request can be traced. The parallel run is complete when every migrated client has run through a full renewal cycle without manual intervention.
Cut over node by node
Following the documented node-by-node in-place upgrade, move cluster members one at a time, confirm each node is healthy and unsealed before continuing, and keep a rollback point ready at every stage. Do the cutover in a maintenance window agreed with the application owners, and check that leader election and Raft replication are stable after each node. The cutover is done when all nodes run OpenBao, every migrated client authenticates successfully, and the monitoring baseline matches the pre-change values.
Decommission Vault after a final backup
Once OpenBao has run in production through an agreed observation period, take a final encrypted backup of the retired Vault data, store it under the same retention and access rules as other secrets backups, and then shut down and remove Vault nodes. Revoke Vault-specific credentials, update runbooks, and remove Vault references from pipelines and documentation. The step is complete when the final backup has been restored at least once, the retention owner has signed off, and no client still points to the old endpoint.
Which Vault alternative fits your situation
When secrets must stay inside a specific country, data center or disconnected network, the question is whether the platform can run entirely under your control with no external service dependency. OpenBao is self-hosted software, so it runs in your own cloud accounts, data centers or isolated networks. Its licensing under MPL 2.0 does not require a vendor-hosted control plane, which makes it a natural candidate for these environments. The migration guide describes an in-place, node-by-node upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, so teams on that exact configuration have a documented starting point.
- Deployment footprint: Confirm that every component, including the unseal process, audit devices and backups, runs inside the boundary you must enforce.
- Upgrade path scope: The guide was tested only against Vault Community 1.14.1. Confirm your current version and storage backend match before planning an in-place upgrade.
- Plugin gaps: Mounts that use plugins OpenBao does not ship are skipped during migration, so inventory every mount first.
- Token format: New tokens use a shorter OpenBao format. Check any system that parses or validates token strings.
- Offline updates: Confirm how you will obtain and verify new releases, such as the v2.7.1 security release, inside a disconnected network.
Confirm the exact deployment boundary and the upgrade starting point with your own engineers before you commit.
Cost comparisons often pit a commercial subscription against a free download, but the free option still has costs. Vault Community is free to use, while Vault Enterprise and HCP Vault Dedicated are priced by quote according to HashiCorp's pricing page. Moving to OpenBao removes the license line item but adds recurring operating effort: patching, monitoring, backups, capacity planning and on-call support for the cluster. The trade-off depends on how much of that effort your team already carries and how many staff hours a cluster would consume.
- Subscription costs: Ask the vendor for a written quote covering the edition, node or usage basis, support tier and renewal terms.
- Operating effort: Estimate the ongoing hours for upgrades, certificate rotation, unseal procedures and incident response across environments.
- One-time costs: Migration planning, testing, parallel running and cutover are one-time, and they vary with the number of mounts and integrations.
- Support model: Open-source support comes from the community or a paid provider. Ask any provider for a written scope and response commitments.
- Usage growth: Consider how cost and effort change as the number of clusters, secrets and applications grows.
Build a side-by-side model that includes staff time and ask each option for its full cost terms in writing before comparing totals.
Teams that rely on custom secret engines, auth methods, or internal integrations need to know how much of their code will carry over and how much they will maintain themselves. OpenBao is a community fork of Vault, so existing plugin compatibility is the first question. Some Vault plugins will not be shipped with OpenBao, and the migration guide notes that mounts using those plugins are skipped. Any customization you build becomes part of your own maintenance burden, including tracking upstream changes from the fork and retesting after each release.
- Fork maintenance: Decide who will track OpenBao releases, review changes and apply security fixes to any patches you carry.
- Plugin inventory: List every custom or third-party plugin and confirm whether OpenBao ships an equivalent or whether you must port it.
- Policy and API compatibility: Test existing policies, API calls and client libraries against a non-production OpenBao cluster.
- Kubernetes packaging: The OpenBao Helm chart requires Helm 3.6 or later, so confirm your cluster tooling meets that minimum.
- Vendor features: Some capabilities that were Enterprise only in Vault may behave differently or be absent in OpenBao, so verify each one you use.
Write down every customization and plugin dependency, then confirm compatibility with the OpenBao maintainers' documentation or a test cluster before estimating the porting effort.
In regulated sectors, the secrets manager is one part of a control set that auditors will evaluate. Any platform can support evidence collection for access control, audit logging, key management and change records, but no software product makes an organization compliant on its own. Auditors and certification bodies decide whether controls are sufficient. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications. The decision therefore centers on whether your current evidence model can be reproduced on the new platform with equal or better traceability.
- Access controls: Map how identity-based policies, authentication methods and least-privilege roles will be defined and reviewed.
- Audit logging: Confirm which audit devices are available, where logs are stored, and how long they are retained.
- Key and seal management: Document how unseal keys or recovery material are split, stored and rotated, and who holds them.
- Change evidence: Keep records of upgrades, configuration changes and security fixes, such as the v2.7.1 release.
- Auditor alignment: Ask your assessor early whether the proposed architecture and evidence set meet your scope.
Bring your assessor and your security team into the evaluation before selecting a platform, because their acceptance determines whether the option works for your program.
Questions teams ask before moving off HashiCorp Vault
What drives the cost of moving off HashiCorp Vault?
The cost is driven mostly by effort, not by software, because the OpenBao code is licensed under MPL 2.0 and carries no per-seat or per-secret fee. Costs fall into four groups: planning and inventory of mounts, policies and integrations; the migration itself; the infrastructure to run the cluster, including storage, load balancing, backups and monitoring; and ongoing operations. The one-time work scales with how many mounts, plugins, auth methods and consuming applications you run. The recurring cost is your team's time for upgrades, patching and on-call. When requesting a quote, ask for the scope of mounts and integrations covered, who performs cutover testing, how rollback is handled, and whether backup and upgrade support is included after go-live.
How long does a move from HashiCorp Vault to OpenBao take?
No duration can be stated for every environment, because the timeline depends on scope. The main variables are the number of Vault clusters, the storage backend, the number of mounts that use plugins OpenBao does not ship, how many applications read secrets and how much each of them must change, and the change windows your organization allows. A single cluster with a few well-understood integrations is far simpler than a multi-region estate with custom plugins. Ask any provider, including DeployOpen, for a timeline in the written scope, which is agreed before work begins. DeployOpen delivers most engagements on a fixed scope with agreed deliverables and dates.
Can our own team migrate from HashiCorp Vault to OpenBao?
Yes, many teams can do it in-house, provided they have the skills and time. OpenBao publishes a migration guide that describes a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and it states that the path was tested only against that version. If your cluster matches that profile, your team can follow the documentation. If you run a different Vault version, a different storage backend, auto-unseal, Enterprise features or custom plugins, the work moves into engineering judgment and testing that the guide does not cover. A useful test is to run the procedure in a non-production copy first, then decide whether to proceed alone or with outside help.
What does the migration require from our team?
The work needs three things: access, skills and change windows. On access, you need administrative rights to the Vault clusters, the storage backend, the load balancers, the Kubernetes or VM platforms that run the nodes, and the identity systems that feed auth methods. On skills, the team needs experience with Vault policies, auth methods, secret engines, TLS, storage and the systems that consume secrets, such as CI runners and Kubernetes workloads. Plan for:
- Named owners for each application that reads secrets
- Maintenance windows for node-by-node upgrades and client reconfiguration
- A tested rollback and a current, verified backup before any node changes
Confirm these with your change advisory board early, because they often decide the calendar.
Is OpenBao ready for production use after the v2.7.1 release?
OpenBao publishes releases on its GitHub page, and v2.7.1 was released on October 1, 2026 with security fixes. Whether a version is production-ready for your use case is a decision you should base on your own testing, the project's release notes and your risk assessment, not on the release date alone. Check which features your deployment uses, confirm they are covered in the release notes and your test results, and set a patching process that tracks new security releases. Confirm with the project and with your provider which versions they support and how they handle security advisories before you commit.
What happens to Vault Enterprise features after moving to OpenBao?
HashiCorp sells certain capabilities only in Vault Enterprise and HCP Vault Dedicated, and pricing for those is available by quote. OpenBao is a fork of the Community code base under MPL 2.0, so features that exist only in Enterprise editions are not automatically available. Inventory every feature you depend on, including namespaces, replication, Sentinel policies, HSM or auto-unseal integrations, and enterprise audit or secrets engines. For each one, confirm whether OpenBao provides an equivalent, whether a plugin or configuration can replace it, or whether you must redesign the control. Plugins that OpenBao does not ship are skipped during migration, so list them early.
Does the 2023 license change force us to move off HashiCorp Vault?
No license change forces an immediate move, but it changes the terms under which future releases are available. HashiCorp announced on August 10, 2023 that future releases of its products would move from the Mozilla Public License 2.0 to the Business Source License 1.1, while its APIs, SDKs and most libraries stay under MPL 2.0. The main restriction targets vendors that offer competitive services built on HashiCorp products. Whether this affects you depends on how you use Vault and on your own legal review. Ask your counsel to read the license text and the HashiCorp announcement, and decide whether the change matters to your long-term procurement and lock-in strategy.
What does DeployOpen do during a move off HashiCorp Vault?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which covers an OpenBao deployment. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen also runs security testing and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope.
What changes for your applications, pipelines and operators
Most of the day-to-day surface of Vault stays in place when you move to OpenBao, but the changes that do land tend to break things in the places teams check last. The Vault API and SDKs were not relicensed in the 2023 change, since HashiCorp kept them under the Mozilla Public License 2.0, so client libraries that call the HTTP API generally keep working. The risk sits in what surrounds those calls: token parsing, the shorter token format OpenBao issues for new tokens, and any code that assumes a hvs. or s. prefix pattern or a fixed token length. Search your codebase, sidecars and secret-handling scripts for hard-coded token validation, and confirm with your library maintainers which versions handle OpenBao tokens correctly before you cut over.
Operators should expect the CLI, Kubernetes injection and CI jobs to need a closer look. The bao binary replaces vault for OpenBao, so scripts that call vault by name, environment variables such as VAULT_ADDR and VAULT_TOKEN, and wrappers that parse CLI output will each need a review. Check how your Kubernetes workloads receive secrets, whether through the Vault Agent Injector, the CSI provider or application-side SDK calls, and confirm the equivalent components and annotations with the OpenBao Helm chart documentation before you change a single deployment. For pipelines, list every job that authenticates with a Vault role and test one job end to end. Plugins that OpenBao does not ship are skipped during an in-place upgrade, so any mount you depend on must be listed and checked.
Build a compatibility test list before any cutover and freeze new Vault-only features while it runs. The list should cover authentication methods, each secret engine and dynamic secret role, policy evaluation for representative identities, lease renewal and revocation, audit log output, and every runbook step that names a Vault command or path. Mark any feature you used from Vault Enterprise, since those were not part of the Community edition and may have no direct OpenBao equivalent to confirm with the project. Freeze new Vault-only features, such as new Enterprise-only mounts or namespaces, until the test list passes on a staging cluster. Rewrite the runbooks with the operators who will use them during an incident, and record the outcome of each test so the cutover decision rests on evidence.
How DeployOpen scopes, migrates and supports your Vault replacement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Vault replacement, we start from your current Vault edition, storage backend, unseal method and the secrets engines and plugins you depend on, then agree the work in writing before any change begins.
How we scope
- Inventory your Vault version, storage backend, unseal method and every mounted secrets engine and plugin
- Identify which mounts OpenBao does not ship and agree how each one is rebuilt, replaced or retired
- Agree the scope, deliverables and timeline in writing, since most engagements are fixed-scope
How we build
- Rehearse the node-by-node in-place upgrade in a non-production copy before touching production
- Rewrite policies, auth methods and client configuration, and test token handling with the new shorter format
- Test the migrated platform against your own workloads, including Kubernetes and CI pipelines, with security testing where scoped
How we hand over
- Document the cluster design, unseal and recovery procedures, backup steps and access model for your team
- Deliver a record of tested migration steps, rollback points and known gaps so your auditors can review them
- Prepare the controls and evidence for your compliance assessment, while independent auditors issue any formal opinion
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover tracking of OpenBao releases and applying security fixes in your environment
- Ask any provider to state in the quote who performs upgrades, who holds on-call duty and how incidents are escalated
