Where self-hosted OpenBao costs less than CyberArk Secrets Manager, and where it costs more
If a renewal or licensing change has put CyberArk Conjur or CyberArk Secrets Manager under review, the comparison depends on your own figures, because CyberArk prices by quote and no list price applies to every buyer. Self-hosted OpenBao removes the license line, but it does not remove cost. You take on the infrastructure, high availability, day-two operations, support and the migration project. Start by writing down what the current contract covers: the number of machine identities or secrets, the appliances or software nodes, the support tier, and any professional services already bought. Then price each replacement component against that list, not against the headline license fee.
The balance usually tips toward OpenBao when the commercial spend is dominated by licenses and renewals for a stable, mostly server-side workload set, and when your team already runs Kubernetes, managed databases or Raft-backed clusters well. It usually tips the other way when you have few platform engineers, no 24/7 on-call for security infrastructure, or a migration that must be scheduled around audit windows. Confirm with your own staff how many hours a month they can give to upgrades, backups, unseal procedures and incident response. Those hours, not the software, are the main recurring cost. OpenBao is licensed under MPL 2.0 and is free to run, so the recurring spend is people, hosting and support rather than a per-seat or per-appliance fee.
The Business Source License change that HashiCorp announced on August 10, 2023 for Vault is context for this decision, not a cost line. It matters because it shaped where the Vault code lineage is heading, and it is one reason OpenBao exists. Ask any open-source support provider, including DeployOpen, for a written scope with deliverables, hosting assumptions and a named list of what is excluded, and compare those written scopes with CyberArk's quote on equal terms. HashiCorp's licensing announcement gives the background on that change.
Cost components on each side and whether they are one-time or recurring
This table lists each cost component on the CyberArk side and the self-hosted OpenBao side, and marks whether it is one-time or recurring. CyberArk figures come from your written quote, and OpenBao software carries no license fee, so the comparison turns on who pays for infrastructure, operations and migration effort. Use the recurring rows to model annual run cost and the one-time rows to size the migration project.
| Cost component | CyberArk side (commercial) | Self-hosted OpenBao side | One-time or recurring |
|---|---|---|---|
| Software license or subscription | Subscription or license fees set by the CyberArk quote, which should be requested per product and per workload scope | No license fee for OpenBao, which is licensed under MPL 2.0 | Recurring on the CyberArk side; none on the OpenBao side |
| Appliances or hardware | Appliances or hardware only if your quote includes them; confirm this in writing | Servers or virtual machines for OpenBao nodes in your own data center or cloud account | One-time purchase or recurring cloud charges, depending on the model you choose |
| Professional services | Vendor or partner services for deployment, configuration and training, priced in the quote | Implementation partner or internal staff for planning, deployment and hardening, scoped in writing | Mostly one-time |
| Compute and storage | Usually included in the vendor's service model; confirm what your deployment must host | Compute, block storage and backup storage for the cluster, sized to secret volume and request rate | Recurring |
| KMS or unseal key management | Handled within the vendor's managed or self-managed design; confirm key custody and rotation responsibilities | Shamir unseal keys managed by your staff, or auto-unseal through a cloud KMS or HSM that you pay for separately | Cloud KMS or HSM fees are recurring; key ceremony and rotation effort recurs |
| HA nodes and load balancing | Confirm whether redundant nodes and load balancing are included or billed separately | Extra nodes for Raft or PostgreSQL storage, plus a load balancer, each billed as infrastructure | Recurring |
| Backup and disaster recovery | Confirm backup scope, retention and recovery testing responsibilities in the quote | Storage, snapshot tooling and a tested recovery runbook that your team or partner maintains | Setup is one-time; storage and periodic restore tests recur |
| Implementation and migration project | Vendor migration support, if included, is priced in the quote | Translating policies, auth methods and client integrations, plus cutover and rollback planning | One-time, with effort driven by the number of workloads and integrations |
| Support contracts | Vendor support tier stated in the subscription, with terms to confirm in the quote | Optional support from OpenBao maintainers' ecosystem or a services partner, contracted separately | Recurring if you buy support |
| Upgrades and patching | Included in the subscription terms; confirm upgrade windows and version support | Staff time for minor and security releases, such as the v2.7.1 security release | Recurring |
| Internal skills and on-call | Lower day-to-day operations load, though your team still administers policies and integrations | Staff trained on Vault-style administration, plus on-call coverage for the secrets service | Recurring; training is one-time |
What moves the comparison up or down
Six drivers decide whether a CyberArk Secrets Manager subscription or a self-hosted OpenBao cluster costs more over several years. Most of them scale the same way on both sides, so the comparison turns on which drivers dominate your estate and how much of the operating work your team can absorb.
Number of secrets and machine identities
Commercial secrets managers commonly price on the volume of secrets, identities or workloads under management, so a large estate of service accounts, pipelines and workloads pushes the subscription up. OpenBao does not charge per secret, so the same growth adds storage, backup and operator time rather than a license line. Ask CyberArk how its quote counts identities, and count your own machine identities, including short-lived workloads that appear and disappear.
Request volume and API call patterns
Read-heavy workloads such as containers that fetch secrets at every start, or pipelines that query many values at once, multiply API traffic. Metered offerings charge for this traffic, while self-hosted OpenBao spends it on compute and network capacity you already run. Measure peak read rates and burst behavior during deployments, and confirm with the vendor whether bulk reads or caching are counted differently.
Edition and feature needs
Dynamic secrets, high availability, replication, namespaces and enterprise authentication methods may sit in higher commercial tiers, which increases the subscription. OpenBao's documented features include dynamic secrets, leasing with revocation, several auth methods and high availability with Raft or PostgreSQL. Map each feature your teams need to a tier in the CyberArk quote and to a component you will build or support yourself.
Availability and disaster recovery targets
A higher availability target means more nodes, separate failure domains, tested unseal procedures and backups restored on a schedule. On a commercial service much of this is priced into the tier. Self-hosted, you pay for the extra nodes, load balancing, monitoring and the staff hours to rehearse recovery. Agree the recovery time and recovery point targets with your risk owners before comparing quotes.
Number of clusters and regions
Each additional cluster, data center or region multiplies the cost of hardware or cloud instances, replication setup and monitoring on the open-source side. Commercial quotes often vary with deployment footprint, so ask how additional regions, sandboxes and disaster recovery sites are priced. Fewer, larger clusters can reduce overhead, but they also widen the blast radius of a single failure.
Skills already in the team
Teams that already run Kubernetes, PostgreSQL or Vault-style operations absorb OpenBao with little new training, which lowers the recurring labor share. Teams without that experience will pay for training, an implementation partner or a retainer for upgrades and patching. Inventory who would own unseal keys, upgrades and incident response, and use that inventory to decide whether the internal labor line or an external support line is the larger cost.
How unseal method and HA design change the self-hosted bill
The unseal method you choose decides who carries the operational risk and which bills recur. With Shamir unseal, the OpenBao cluster starts sealed and operators must supply a threshold of key shares to unseal it, so no cloud or hardware line item is needed for the seal itself. The cost is people: your team must generate, distribute and safeguard the key shares, rehearse unseal after restarts, and keep a documented custody process that auditors can inspect. Auto-unseal through a cloud KMS or an HSM moves that burden into a recurring key-service or hardware charge and an IAM policy you must govern. Confirm the KMS or HSM price with your cloud provider or hardware vendor, and confirm the key-usage and request charges that apply to your region and volume. Price both options against your own on-call model before you decide.
High availability is the second driver of node count and storage spend. OpenBao's officially supported HA backends are integrated storage (Raft) and PostgreSQL. In either design, one active node holds a lock in the data store while standby nodes forward or redirect requests. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL, which can reduce load on the active node. Ask your architects whether read scaling changes the number of nodes you need, and whether a managed PostgreSQL service in your own agreements is cheaper to run and back up than a dedicated Raft cluster. The OpenBao high availability documentation sets out the failover and read behavior to test before you size anything.
Price node count, storage and the KMS from your own cloud or data center agreements, not from a generic estimate. Ask for the compute, block storage, backup retention and cross-zone traffic you will pay for at each node, and for the KMS or HSM rate you plan to use. Add the standing staff time for key custody or KMS policy review, which recurs for as long as the cluster runs. Illustrative example: a three-node Raft cluster with auto-unseal has fewer manual steps at restart but a KMS line item every month, while a Shamir design has no seal bill and a recurring ceremony cost. Model both for a full year before you choose.
How to build the comparison with your own numbers
This sequence turns a vague sense that OpenBao costs less into a like-for-like model you can defend to finance and security leadership. Each step produces a figure or a written document that feeds the three-to-five-year comparison.
Collect the current CyberArk order and quote terms
Ask your CyberArk account team or reseller for the current order form, subscription term, licensed units, appliance or software components, support tier, renewal date and any price-escalation or true-up clauses. Ask whether the licensing counts workloads, secrets, identities or something else, because that unit drives how the bill grows. Record every line item in one sheet, with the contract end date. You are done when someone in finance and someone in security can each point to the same line items and explain what each one buys.
Inventory workloads and secret categories
Work with platform, application and CI owners to list every system that reads secrets from the current vault. Group them by category, such as database credentials, cloud access keys, Kubernetes service accounts, certificates, API tokens and encryption keys, and note how each category authenticates today. Count workloads and secrets per category, and note which ones need dynamic credentials or rotation. You are done when the inventory accounts for every known consumer and each owner has signed off on their row.
Size the OpenBao footprint for HA and DR
Decide the target topology with your infrastructure team. OpenBao high availability relies on an active node and standby nodes sharing a data store, and the officially supported HA backends are integrated storage (Raft) and PostgreSQL, so the choice of backend changes the number of servers and the database skills you need. Decide how unseal will work, either with Shamir key shares operated by people or with an auto-unseal key management service in your cloud or data center, and list the cost of each option. Include backup, restore testing, monitoring and a second site if your recovery objectives require it. You are done when you have a diagram, a node list and a costed list of compute, storage, network and key management items for each environment.
Cost the migration from a fixed-scope written plan
Ask two or three implementers, including DeployOpen, to quote against the same written scope. The scope should name the workload categories from your inventory, the target OpenBao version, the auth methods you will use, the policy translation work, the cutover approach and the acceptance tests. Ask each quote to separate one-time items (design, build, migration, testing, documentation, training) from recurring items (support, upgrades, testing retainers). Confirm whether the OpenBao migration path from Vault Community 1.14.1 applies to your environment or whether a rebuild is needed, since the migration guide states it was tested against that version only. You are done when each quote covers the same workloads, the same environments and the same exit criteria.
Add support and internal time
Estimate the internal effort your own staff will spend on the project, on operating the platform and on responding to incidents. Name the roles (platform, security, application owners, compliance) and the share of time each role will contribute. Add support: decide whether you will buy a vendor support plan, rely on an implementation partner's retainer or staff the on-call rota yourself, and price each option from written quotes. Note what your current CyberArk support covers today so you can match it. You are done when every support and internal labor line has an owner and a source, whether that is a quote or an internal estimate you can explain.
Model three to five years with one-time and recurring lines
Build a spreadsheet with one column per year across a three- to five-year horizon. Keep one-time costs (migration, design, initial hardware, training) in their own section and recurring costs (CyberArk subscription, OpenBao infrastructure, key management, support, upgrades, internal operations) in another. Model the CyberArk renewal with any escalation terms from your order, and model OpenBao with the infrastructure and support lines from earlier steps. Run a sensitivity check on the drivers that move the result most, such as workload count, number of environments and the choice of unseal method. You are done when the model reproduces your current spend in year one and each assumption is traceable to a quote, an order term or an internal estimate.
Compare like-for-like scope and confirm the gaps
Before you draw a conclusion, check that both sides cover the same capabilities. Confirm with CyberArk and with OpenBao documentation which features each one provides for your use cases, such as dynamic database secrets, Kubernetes authentication, audit logging, high availability and support terms. Where OpenBao lacks something you rely on, price the gap as a line item, either as custom development, a third-party tool or a retained procedure. Record these gaps in the model so they appear next to the cost they affect. You are done when the comparison table lists identical workloads and capabilities on both sides and every difference has a cost or a decision attached.
What the migration project costs beyond the software
The largest cost in moving off CyberArk Secrets Manager or Conjur is usually the migration project, not the OpenBao software, and it scales with the number of host identities, policies and workloads that read secrets. Start by inventorying every machine identity, every policy and every consumer (Kubernetes deployments, CI pipelines, cloud workloads). Each one needs a target OpenBao auth method, policy and secret path, and each one needs its own cutover step. Ask your implementation partner to price the work from that inventory, not from a flat estimate.
If you are coming from HashiCorp Vault, the documented in-place path is narrower than it looks. OpenBao's migration guide describes a node-by-node upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and it was tested only against that version. Mounts that use plugins OpenBao does not ship are skipped, and new tokens use a shorter format, so client code that parses tokens needs review. Confirm your exact Vault version, storage backend and unseal method before you plan. Anything else, including Vault Enterprise features, Conjur or a different storage backend, needs a planned path: a fresh OpenBao cluster, re-reading secrets through the API and translating policies by hand. Budget for that as new engineering work.
Plan for parallel running. Keep the source system live while OpenBao serves a growing subset of workloads, so that a failed cutover can roll back one identity at a time. Reconnecting Kubernetes workloads is typically the largest share of that work. The OpenBao Helm chart is the recommended install method and requires Helm 3.6 or later, so confirm your cluster tooling meets that version before you start. CI pipelines, cloud workloads and scripts with hard-coded tokens need the same per-identity treatment. Cutover testing should cover secret reads, rotation, lease revocation and audit logging for each identity, and a named owner should sign off each one. Ask any quote to list these steps, the identities in scope and what is excluded.
Cost and effort questions buyers ask before hiring help
Is self-hosting OpenBao cheaper than a CyberArk Secrets Manager subscription?
It depends on what you already run and what you count. Self-hosting removes the subscription line, but it moves the cost to infrastructure, staff time and support. OpenBao itself is open source under MPL 2.0, so there is no license fee for the software. The recurring costs you need to model are the compute and storage for at least three nodes if you use integrated Raft storage, the unseal method you choose (manual Shamir keys, or a KMS service you already pay for), backups, monitoring, and the engineering hours to patch and upgrade. CyberArk prices its commercial products by quote, and DeployOpen does not publish prices, so ask CyberArk for a written quote covering the same workload count, appliances or professional services, and support tier. Then build a side-by-side model with the same workloads, the same growth and the same staffing assumptions.
How long does a migration from CyberArk take, and what drives the timeline?
No duration is fixed in advance, so treat any single number with caution and ask for it in writing. The timeline is driven by the number of secrets, the number of workloads and identities that read them, how many Kubernetes clusters, CI pipelines and cloud accounts need reconnecting, and how much of your current access model must be translated into OpenBao policies and auth methods. Teams with many dynamic or rotated credentials need more testing windows than teams with static values. The OpenBao migration guide describes an in-place upgrade path from Vault Community 1.14.1 on Raft storage with Shamir unseal, but it was tested only against that version and skips mounts that use plugins OpenBao does not ship. Source-level differences from a CyberArk or Conjur deployment mean a re-platforming project, not an upgrade, so plan for re-reading secrets and translating policy. Confirm the timeline against an inventory of your own environment.
Can our internal team run the OpenBao migration without outside help?
Many teams with experienced platform and security engineers can, particularly if the scope is limited to a few applications and a single cluster. The skills needed are Kubernetes or VM administration, TLS and PKI, identity federation, policy design, and a tested rollback plan. The harder parts are usually the workload authentication changes and the audit evidence that must show the old and new controls. Ask yourself whether your team has time to run a parallel period, document decisions and absorb incidents during cutover. An outside implementer changes the mix of cost, not only the amount: you pay for defined deliverables, while your staff keeps ownership of the platform afterward. Compare the internal effort, with the people it takes from other work, against a written scope from an implementer.
What does a fixed-scope OpenBao engagement actually include?
A fixed-scope engagement is agreed in writing before work starts, with defined scope, deliverables and timelines. 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 an OpenBao move, that normally means agreeing which secrets, auth methods, policies, workloads and environments are in scope, how high availability and unsealing will be built, how backups are tested, how workloads are reconnected, and what the cutover and rollback steps are. Items outside the written scope, such as unrelated identity redesign or new application development, should be listed as exclusions. Ask for the deliverables list, the acceptance criteria and the change process for scope additions.
What recurring work remains after OpenBao goes live?
Recurring work is what most cost models underestimate. OpenBao publishes releases on GitHub, and the v2.7.1 release of October 1, 2026 included security fixes, so you will need a repeatable process to test and apply patches. Other recurring tasks include renewing TLS certificates, rotating root and unseal material, testing restores, reviewing audit logs, managing auth method changes as teams and clusters change, and monitoring the cluster. If you use integrated Raft storage, you also need to plan node replacement and quorum health, while PostgreSQL storage shifts effort toward database operations. Retainers for ongoing support, upgrades and continuous testing are available from DeployOpen, and you can also staff these tasks internally. Decide who owns each task before go-live.
How should we compare quotes from CyberArk and implementation partners?
Put every quote on the same basis before you compare totals. Ask each vendor or partner to list one-time items separately from recurring items, and to state the assumptions behind them. For CyberArk, that means subscription terms, the deployment model, appliances or infrastructure it requires, professional services, training and support level. For an implementer, it means the written scope, the environments covered, the number of workloads and secrets in scope, testing and cutover assumptions, documentation, and post-handover support. Ask what is excluded, who pays for infrastructure and licenses you still need, what happens if scope grows, and how long the offer remains valid. A lower quote with fewer deliverables may cost more after handover.
Which licensing and vendor changes should we factor into the decision?
Two changes affect the long-term cost picture. HashiCorp announced on August 10, 2023 that future releases would move from MPL 2.0 to the Business Source License 1.1, which means the Vault codebase is no longer open source for new releases, and the main restriction targets vendors offering competing services. IBM completed its acquisition of HashiCorp on February 27, 2025, so the commercial direction of Vault now sits within IBM. OpenBao, licensed under MPL 2.0 and governed under the Linux Foundation's OpenSSF, is a separate project that avoids that licensing path. Conjur Open Source is licensed under LGPL v3.0, but CyberArk's commercial offerings and their roadmap are separate, and the company is now part of Palo Alto Networks. Confirm contract terms, renewal dates and support commitments in writing with each vendor.
How DeployOpen scopes a fixed-price OpenBao implementation
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a CyberArk Secrets Manager replacement, we start with a written scope that prices the OpenBao work separately from the subscription and appliance costs you are retiring.
How we scope
- Inventory of CyberArk Secrets Manager subscriptions, appliances, connected workloads and the professional services currently in use
- Target OpenBao design covering storage backend, unseal approach (Shamir keys or KMS) and high availability layout
- Written scope, deliverables and timeline agreed before any work starts, with a quote following from that scope
How we build
- Deploy OpenBao in your cloud accounts, data centers or air-gapped network, including the Helm chart path where Kubernetes is used
- Configure auth methods, policies and dynamic secrets for each workload class, tested against a staging copy first
- Run security testing on the deployment and document the controls and evidence that your assessors will ask for
How we hand over
- Runbooks for unsealing, backup and restore, upgrades and node replacement, written for your operations team
- Knowledge transfer sessions with the engineers who will own OpenBao after handover
- Documentation of the architecture, configuration and cost drivers so the ongoing run cost stays visible to your team
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Upgrade planning against each OpenBao release, including reviewing security fixes before you apply them
- Support scope agreed in writing, so recurring costs are known in advance and can be compared with your current renewal
