CyberArk Conjur vs OpenBao: which to choose

Conjur or OpenBao: which fits your machine identity program

If CyberArk support, the Conjur policy model and your existing integrations matter most, stay on Conjur Open Source or CyberArk's commercial line. If open governance, MPL 2.0 licensing and a Vault-compatible ecosystem matter most, choose OpenBao. Both are credible answers, and the choice turns on what your team has already built, not on a feature checklist alone. Start with the sunk investment. Count the Conjur policy files, host identities, variable permissions and the Kubernetes or CI integrations that depend on them. Each of those must be rewritten for OpenBao, because a Conjur migration is a set of re-reads and policy translation, not an import. Next, examine how your workloads authenticate. OpenBao documents AppRole for servers, Kubernetes, JWT/OIDC, TLS certificates and several other methods, so confirm that each workload class you run has a supported path. Ask CyberArk and your own engineers which of your Conjur authenticators map cleanly, and which need custom work.

On storage and operations, OpenBao's high availability uses integrated storage (Raft) or PostgreSQL, and its documentation describes PostgreSQL as easier to operate safely than Raft. Check whether your platform team already runs PostgreSQL reliably, and whether it can own Raft snapshots, unseal procedures and node upgrades. Also confirm your upgrade path: OpenBao's migration guide for moving from Vault has been tested only against Vault Community 1.14.1 on Raft with Shamir unseal, so a Vault source version outside that must be validated in a lab first. Finally, review the vendor direction. CyberArk is now part of Palo Alto Networks, and the Idira rebrand affects product naming in your contracts, so ask in writing which product line, support terms and roadmap your renewal covers.

Which option fits which scenario

This table matches common buyer situations to the option that usually fits better, with the condition that drives each choice. Read each row against your own estate: the deciding factor is often an existing Conjur policy base, a Vault skill set or a hard requirement for air-gapped operation, not feature checklists alone.

Buyer scenario	Better fit	Condition that drives the choice
Existing Conjur policy estate	Conjur (stay put for now)	Policies, host identities and CI integrations already work and the team has no pressing trigger. Moving them is a project in its own right, so plan it on your timeline, not the vendor's.
CyberArk-standard enterprise	CyberArk Secrets Manager	Your PAM program, audit reporting and support contracts already center on CyberArk, and a single vendor relationship outweighs licensing cost concerns. Confirm the commercial terms with CyberArk directly.
Vault-experienced platform team	OpenBao	Your team already runs Vault policies, auth methods and Raft storage, and the migration guide covers in-place upgrades from Vault Community 1.14.1. Validate any other Vault version before relying on it.
Kubernetes-first teams	OpenBao (or Conjur, if already in use)	You want the Helm chart as the supported install path and Kubernetes auth for workloads. Check that your existing Conjur Kubernetes authenticator and sidecar patterns can be reproduced before choosing either.
Air-gapped or residency-bound environments	OpenBao or Conjur Open Source, self-run	You need every component, including unseal and storage, inside your network. Both can be self-hosted. Confirm offline update and vulnerability feed handling with each vendor, since neither should be assumed.
Teams requiring MPL 2.0 governance	OpenBao	Your procurement or legal review favors a community-governed project under the Linux Foundation's OpenSSF. OpenBao is MPL 2.0 and a Sandbox project, so review its maturity against your own risk criteria.

Where your secrets live and who controls the platform

Both options can keep secret material inside your own infrastructure, but the control boundary differs. Conjur Open Source and OpenBao are self-run, while CyberArk's commercial Secrets Manager adds a vendor-operated or vendor-supported layer whose terms you need to read closely. The cards below cover where data sits, what protects it, how identity and audit connect, and what evidence your own team must present.

Data location in your infrastructure

With self-hosted OpenBao, encrypted secrets are written to the storage backend you choose, such as integrated Raft storage or PostgreSQL, inside your cloud accounts, data centers or air-gapped network. Conjur Open Source likewise runs in your environment, but its data layer and deployment patterns differ from OpenBao's. For CyberArk's commercial offerings, confirm in writing where the control plane, backups and telemetry reside, and which of them leave your network. Ask for a data flow diagram that lists every system holding secret values or metadata.

Trust boundary around unseal material

OpenBao starts sealed and needs unseal material before it serves secrets. Under the Shamir method used by the migration path, key holders must be separated from the nodes and from each other, and you must decide who can reach the quorum. Auto-unseal through a cloud KMS moves that trust into the KMS provider's key policies. Confirm who holds unseal shares or KMS permissions, how they are rotated, and whether a single administrator can recover the cluster alone.

Hosting models compared

There are three realistic hosting models: self-managed Conjur Open Source, CyberArk's commercial Secrets Manager with its own deployment and support model, and self-hosted OpenBao that your team or DeployOpen operates. The first two keep the software under CyberArk's licensing and release cadence, while OpenBao is an MPL 2.0 project governed by its community. Ask CyberArk which model applies to your contract, who performs upgrades, and who has administrative access to the platform.

Identity and audit integration

Both platforms must authenticate workloads and record who read which secret. OpenBao documents auth methods including Kubernetes, JWT/OIDC, AppRole, TLS certificates and LDAP, and it supports login MFA for human users. Map each workload and human identity source to an auth method, then confirm that audit devices send logs to a system your security team monitors. Verify these integrations against the release you deploy, because method coverage changes across versions.

Compliance evidence the client must present

Regulators and auditors assess your controls, not the software vendor's brochure. DeployOpen can prepare configurations, access reviews, backup and restore tests, and evidence packs for your secrets platform, but DeployOpen does not issue audit reports, attestations or certifications. Your auditor, or a certification body where one applies, decides whether the controls meet the standard. Agree in writing which evidence artifacts are yours to retain, including key ceremony logs, policy exports and access review records.

Vendor direction and support terms

Ownership and roadmap affect long-term control. OpenBao is a Sandbox project of the OpenSSF under Linux Foundation stewardship, while CyberArk is now part of Palo Alto Networks, which also owns the Idira rebrand of its privileged access line. Ask CyberArk for written commitments on Conjur Open Source maintenance, end-of-life notices and the support path for self-hosted deployments. Record the answers so your exit plan rests on documented terms rather than on assumed continuity.

How vendor direction changes the risk of staying put

Staying on CyberArk Conjur is a decision about vendor direction, not only about features. CyberArk is now part of Palo Alto Networks, and its privileged access offering is presented as Idira. That combination may well suit your organization, but it changes who sets the roadmap, how packaging is decided and which licensing terms apply to a machine identity platform that sits under many of your pipelines and workloads. Conjur Open Source is licensed under the GNU LGPL v3.0, while the commercial Secrets Manager products are sold separately, so the boundary between what you run for free and what you pay for should be confirmed in writing rather than assumed.

The reason this matters is visible in the HashiCorp history that drives the OpenBao fork. 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 stayed under MPL 2.0. IBM completed its acquisition of HashiCorp on February 27, 2025. OpenBao forked Vault and is licensed under MPL 2.0 under the Linux Foundation's OpenSSF, so its license terms do not depend on the decisions of a single vendor. Read these events as a precedent for how licensing can change under a new owner, not as a statement about CyberArk.

Before you decide, request a written roadmap, support commitments and licensing commitments from CyberArk that cover the Conjur versions you run, the end-of-support dates for them and any change to license terms during your contract term. Then check your current contract for renewal terms, price-change clauses, assignment or change-of-control provisions and what happens to support if the product is repackaged. Compare those answers with the migration effort, which is covered in the migration section. If the written commitments are narrower than the risk you are carrying, plan the exit now while you still have leverage.

Operating effort for each option

Conjur Open Source is a server your team installs, patches and keeps available. Your internal team owns the Conjur deployment, its database and the TLS certificates clients trust, and it owns the policy files that declare hosts, layers, groups and the variables they can read. Policy is loaded as code, so changes to who can read which secret pass through your review process. Host identities need the same care: each workload's identity must be created, rotated and retired when the workload is decommissioned.

Server operation: Your team patches the Conjur server and its supporting database and monitors availability.
Policy loading: Policy changes are applied as files, so someone must own the repository, review process and load pipeline.
Host identities: Each workload identity needs an owner, a lifecycle and a removal step when the workload is retired.
Certificates: TLS certificates for the server and client trust chains must be renewed on your schedule.
Commercial scope: Ask CyberArk which features and support levels sit outside the open-source server before you plan staffing.

Confirm with CyberArk which support and upgrade commitments apply to your chosen edition before you assign these tasks.

What drives the total cost of each option

Licence fees are only one line in the comparison. The total depends on what each side charges for, what runs on your infrastructure, and who carries the operating work. The cards below separate one-time migration effort from recurring costs so you can build a like-for-like quote request.

Commercial licences and subscriptions

CyberArk Secrets Manager and Conjur commercial offerings are sold through commercial agreements, and the price depends on the scope you negotiate, such as the number of machine identities and the deployment model. Ask for the price in writing, covering the metric it is billed on, the renewal terms and what counts as a billable identity. This is a recurring cost. OpenBao is licensed under MPL 2.0 with no licence fee, so its recurring cost is the infrastructure and people needed to run it.

Infrastructure and high availability nodes

OpenBao runs as a cluster, and the active node plus standbys need compute, networking and load balancing in your own environment. Each additional node in a highly available layout adds a recurring hosting cost, and so does a separate disaster recovery site. Check whether CyberArk's self-hosted deployment needs appliances or specific hardware, because that shifts capital cost to the first year. Compare node counts and regions in both quotes, not only the licence line.

Storage and backend operations

OpenBao stores encrypted data in integrated storage (Raft), PostgreSQL, PebbleDB or in memory. Integrated storage keeps the cluster self-contained, while PostgreSQL moves backup, replication and patching work to a database team that may already run the service. Storage sizing is usually small for secrets, but backup retention and snapshot frequency drive recurring cost. Confirm whether the Conjur or CyberArk setup includes equivalent backups and where those backups are kept.

Unseal keys, KMS and key custody

OpenBao uses Shamir unseal by default, and many teams move to an auto-unseal mechanism backed by a cloud KMS or hardware security module. A KMS adds a per-request charge from the cloud provider and a dependency that must be highly available. Your team carries the procedures for key ceremonies, custody and rotation. Ask CyberArk which key management pieces are included in its quote and which you would still build yourself.

Staff time and operational support

Running a secrets platform takes platform engineering time for upgrades, monitoring, access reviews and incident response. OpenBao support comes from your own staff, from a contracted partner or from a paid retainer, and each option is a recurring line. CyberArk support is usually bundled into the subscription at a tier you select. Estimate the hours per month for each model, and state which tasks each side covers in writing.

One-time migration project

Moving from Conjur to OpenBao is a one-time project. It covers re-reading secrets, translating Conjur policy into OpenBao policies and auth methods, reconnecting Kubernetes, CI and cloud workloads, and running both systems in parallel during cutover. Because the OpenBao migration guide targets in-place upgrades from Vault Community 1.14.1 on Raft, a Conjur move is a re-platforming, so plan for more discovery than a version upgrade. Define the scope and acceptance criteria in writing before any work starts.

Pay-per-use reference models

Managed services such as AWS Secrets Manager bill per secret per month and per 10,000 API calls, with no upfront costs or long-term contracts. Cost therefore rises with the number of secrets and the call volume of your workloads, which can grow quickly in CI pipelines and autoscaling fleets. A self-hosted OpenBao cluster has a more predictable infrastructure bill that does not scale with each call, but it adds the operating work above. Use this model to compare growth curves, not to predict a fixed total.

What moving from Conjur to OpenBao involves

The sequence moves machine secrets, host identities and policy from Conjur into an OpenBao design you own, and ends with Conjur retired after both platforms have run in parallel. Each step produces a written artifact that the next step depends on.

Inventory policies, hosts and consumers
Export the Conjur policy files, list every host, group and variable, and map each one to the workload that reads it, such as a Kubernetes namespace, a CI pipeline or a cloud function. Include the consumers that authenticate with the Conjur API directly and those that use a Conjur-aware sidecar or integration. The output is a register that ties each secret path to an owner, a consumer and the identity that retrieves it. Confirm the register with the application owners before any design work starts, because gaps found later are expensive to close.
Design namespaces, auth methods and policies
Decide how OpenBao namespaces will separate teams or environments, then map each Conjur host identity to an OpenBao auth method. Kubernetes and JWT/OIDC cover most cluster and CI workloads, AppRole fits long-running servers, and Userpass is suited to developer machines, according to OpenBao's guidance. Translate each Conjur policy into OpenBao policies written as least-privilege path rules, and record the mapping in version control. The output is a reviewed design document that shows every identity, its auth method and the paths it can read.
Stand up high-availability storage
Build the OpenBao cluster on the storage backend your operations team can run safely. Integrated storage (Raft) and PostgreSQL are the officially supported high-availability backends, and OpenBao's storage documentation describes PostgreSQL as easier to operate safely than Raft. Decide how unseal will work, whether manual Shamir keys or auto-unseal through a key management service in your own environment, and document the key custody process. The step is complete when a failover test on a non-production cluster keeps the active node's secrets available through a standby.
Install OpenBao on Kubernetes with Helm
If OpenBao runs on Kubernetes, install it with the OpenBao Helm chart, which OpenBao recommends and which requires Helm 3.6 or later. Pin the chart and OpenBao image versions in your deployment repository so upgrades are deliberate. Configure TLS, storage, audit devices and resource limits to match the design from the earlier step. The output is a running cluster in a non-production environment with a documented configuration and a recorded upgrade path.
Re-create secrets instead of importing the archive
Do not import the output of conjurctl export. Re-read each secret from Conjur using an identity that has read access, then write it to the matching OpenBao path, or better, replace static values with dynamic secrets where the target system supports them. Where the source secret is a database password or an API key, rotate it during the move so the old value no longer works. The output is a checklist, marked off path by path, that shows each secret was written and each consumer was pointed at the new path.
Reconnect Kubernetes, CI and cloud workloads
Change each consumer to authenticate to OpenBao with its new auth method and read from the new paths. Start with a low-impact workload in each category, such as a non-production pipeline or a single deployment, and confirm that the lease, token and policy behavior matches the design. Replace Conjur client libraries or sidecars with the OpenBao equivalents, and remove any copies of Conjur credentials from pipeline settings. The step closes when each workload category has run successfully against OpenBao and its Conjur dependency has been removed.
Run both platforms in parallel
Keep Conjur serving existing consumers while migrated workloads read from OpenBao, and compare access logs and error rates for each cutover group over a period your change board agrees. Confirm that audit logging is enabled in OpenBao and that the logs reach the same monitoring stack used for Conjur. Keep a documented rollback for each workload that points back to Conjur. The output is a sign-off record per group that shows the workload has been stable on OpenBao.
Cut over and retire Conjur
When every consumer in the inventory reads from OpenBao and the parallel period has closed without open issues, revoke the Conjur host identities, remove the Conjur variables that have been replaced, and decommission the Conjur servers. Archive the final policy files, the design document and the cutover records, and store them with your change and access evidence. Confirm with your compliance team which records they need to retain. The step is complete when Conjur no longer receives any authentication requests and the decommissioning record is signed off.

Questions buyers ask before choosing OpenBao over Conjur

How much does moving from Conjur to OpenBao cost?

No supplied figure covers a migration price, so the answer depends on scope. Costs fall into three groups: the internal staff time to inventory secrets and host identities, the engineering time to translate Conjur policies into OpenBao policies and auth methods and reconnect workloads, and the infrastructure to run OpenBao in your own environment. Software licensing is not a line item because OpenBao is MPL 2.0 licensed. Ask any implementation partner for a fixed-scope quote built from your count of policies, hosts, pipelines and Kubernetes clusters. Ask CyberArk for written pricing if you are comparing against a commercial Secrets Manager subscription. The OpenBao migration guide describes the upgrade path from Vault, which is a different starting point from Conjur, so expect more translation work for Conjur estates.

How long does a Conjur to OpenBao migration take?

The timeline is set by the number of workloads that read secrets, how many policy branches need rewriting, and how many change windows your teams can accept. Workloads on Kubernetes, CI pipelines and cloud identities each need their own authentication setup in OpenBao, and each needs testing before cutover. Running Conjur and OpenBao side by side for a period usually lowers risk, but it adds an operating burden. Confirm the duration in a written scope with your implementation partner, and do not rely on a generic estimate. Your own inventory is the most reliable input, so start there.

What does our internal team need to provide?

Your team owns the business decisions that a migration cannot make for you. You need an inventory of secrets and the applications that read them, named owners for each application, the change windows you can accept, and access to the Kubernetes clusters, CI systems and cloud accounts involved. Security needs to approve the target key-management approach, such as Shamir unseal or cloud KMS auto-unseal, and the audit logging design. Someone must also own OpenBao after go-live, including upgrades, backups and on-call response. Make these responsibilities explicit in the scope so that gaps appear before work begins.

Can our own engineers migrate from Conjur to OpenBao without a partner?

Yes, a capable platform team can do it, provided they have time and experience with policy design, Kubernetes and identity federation. The official documentation covers installation, auth methods such as AppRole, JWT/OIDC and Kubernetes, and storage choices. The harder parts are translating Conjur's resource-based policy model into OpenBao's path-based policies, verifying that each workload receives only the secrets it needs, and designing high availability and backups. A partner is most useful when the team lacks that experience or cannot spare staff during cutover. Compare a self-run plan with a written, fixed-scope proposal before deciding.

Can OpenBao policies replace Conjur policies one for one?

No, not directly. Conjur policies are written in YAML and define resources, roles and permissions in its own model. OpenBao uses HCL policies that grant capabilities on paths, and identities get access through auth methods and entity or group bindings. Each Conjur policy therefore needs to be redesigned, not copied. Start by listing which hosts read which variables, then map those relationships to OpenBao paths and roles. Test each mapping with a non-production workload before cutover, and confirm the exact behavior of your Conjur version against the OpenBao auth methods documentation.

How does OpenBao handle high availability compared with Conjur?

OpenBao runs an active node that holds a lock in the data store, while standby nodes forward or redirect requests. Its officially supported HA backends are integrated storage (Raft) and PostgreSQL. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended that to PostgreSQL for read scaling. The storage documentation notes that PostgreSQL is easier to operate safely than Raft. Confirm your required failover behavior, backup approach and unseal method against the OpenBao high availability docs and your own test results, because the design of the Conjur deployment you are leaving will shape the target.

Do we need a commercial support contract for OpenBao?

OpenBao is open source, so the software itself does not require a subscription. A support contract is optional and depends on your internal capacity, your uptime requirements and whether your auditors expect a named support path. Support can come from an implementation partner on a retainer, which covers upgrades, backups and monitoring, or from your own staff who track the OpenBao releases and apply security fixes. Decide this before cutover, because the operating model determines who responds when a node fails at night.

Where to confirm capabilities and licensing before you decide

Before you commit to a move, confirm each capability and licence claim against primary sources rather than against this page or a sales conversation. Start with the Conjur GitHub repository, which documents the license split: the Conjur Open Source server code is under the GNU LGPL v3.0, while API clients and extensions are under Apache 2.0. Check the repository's current README and release notes for the features that ship in the open-source build, and compare them with what CyberArk documents for its commercial Secrets Manager products. Then read the OpenBao authentication methods documentation and the high availability documentation to map each Conjur workload identity and HA setup to a documented OpenBao equivalent. Where the docs are silent, treat the gap as open until a test in your own environment proves otherwise.

Use the OpenBao releases page to confirm the version you would deploy and its security fix history, and the HashiCorp Vault pricing page for context on how Vault Community, Enterprise and HCP Vault Dedicated are packaged. That pricing page is useful for understanding the Vault landscape, but it does not describe Conjur, so do not use it as a Conjur benchmark. Ask CyberArk in writing which features are included in your current edition, what support terms apply to self-hosted and SaaS deployments, and whether its migration guide covers your deployment model. Request the support and end-of-life dates for the version you run today.

Confirm your own constraints before any vendor conversation. List the identity providers that workloads and people use, the cloud accounts and Kubernetes clusters that need secret access, and the CI systems that read secrets. Check which data residency and key custody rules apply, because they determine where the OpenBao cluster and its unseal or key management must run. Record how your audit team expects secret access to be logged. These answers will shape the scope of any migration and the quote you request, and they are the inputs an implementation partner will need before estimating effort.

How DeployOpen helps you evaluate and move to OpenBao

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so an OpenBao move can be scoped against your Conjur policies, workloads and audit obligations. We start from written scope and keep the work inside your cloud accounts, data centers or air-gapped networks.

How we scope

Inventory Conjur policies, host identities, variables and the workloads that read them before any design work starts.
Agree in writing which Kubernetes clusters, CI pipelines and cloud workloads are in scope for the OpenBao move.
Confirm storage backend, high availability design and unseal approach with your security and platform teams in the written scope.

How we build

Translate Conjur policy and host identities into OpenBao policies and auth methods such as Kubernetes, JWT/OIDC and AppRole.
Deploy OpenBao with the Helm chart or your chosen method, and test secret reads, dynamic secrets and revocation in a staging environment.
Run security testing against the new secrets path and check each workload reconnects before cutover begins.

How we hand over

Document architecture, policy mapping, runbooks for unseal, backup and upgrades, and the cutover record for your teams.
Walk through the migration evidence so your compliance leads can review controls with their independent auditors.
Hand over administration access and operating procedures with the scope closed out in writing.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
Track OpenBao release notes and security fixes, and plan upgrades inside your own change control process.
Ask for a quote based on the written scope, which sets the deliverables, timeline and support terms before work begins.

CyberArk Conjur vs OpenBao