Which open-source option fits a CyberArk Conjur renewal or lock-in concern
If your concern is a CyberArk Conjur renewal, a licensing change, a residency requirement or lock-in, the two main self-hosted paths are staying on Conjur Open Source or moving to OpenBao. Conjur Open Source is a reasonable first check because its server code is licensed under the GNU LGPL v3.0, with API clients and extensions under Apache 2.0, so the decision is less about licensing the core and more about which operating model, policy language and integration surface your teams can keep running for the next several years. The pressure many teams feel comes from the wider market. 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, and IBM completed its acquisition of HashiCorp on February 27, 2025. Those events matter to a Conjur decision only if you also run Vault, or if your procurement team is comparing vendors in the same category. CyberArk sells separate commercial offerings and documents a migration guide to CyberArk Secrets Manager, Self-Hosted, which is a legitimate option for organizations that want vendor support.
Before you choose, confirm three things with your CyberArk account team and your own platform owners: which Conjur edition and version you run today, which features your policies depend on, and whether your renewal terms or residency rules actually require a change. If the answer is that you need to stay close to Conjur's policy model, Conjur Open Source keeps that model. If you want a different project with a governance structure that is not tied to one company, evaluate OpenBao, which is licensed under MPL 2.0 and described in the OpenBao website. Map every secret path, authentication method and consumer before you decide, because that inventory determines the migration effort in either direction.
Conjur Open Source or OpenBao: which self-hosted option to shortlist
Teams leaving CyberArk's commercial secrets products usually narrow the field to two self-hosted paths: stay on Conjur Open Source or move to OpenBao. The right choice depends on whether your policy model and integrations already run on Conjur, or whether you need a Vault-compatible ecosystem and the tooling that comes with it.
Conjur Open Source server
Conjur Open Source is the self-hosted server behind CyberArk's Conjur family. Its server code is licensed under the GNU LGPL v3.0, while API clients and extensions use Apache 2.0. This option fits teams whose Conjur policies, machine identities and application integrations already work, because staying put avoids rewriting the access model. Check which features you rely on, such as specific authenticators or policy tooling, and confirm with the project that they are maintained in the open-source edition. The main trade-off is that your roadmap follows a single vendor-backed project rather than a broader community ecosystem.
OpenBao under MPL 2.0
OpenBao is a community-driven fork of Vault, managed under the Linux Foundation's OpenSSF and licensed under MPL 2.0. It provides encrypted secret storage, dynamic secrets for databases and Kubernetes, encryption as a service, identity-based access control, and lease management with revocation. This option fits teams that want a Vault-compatible ecosystem, client tooling and operator knowledge. The main trade-off is that OpenBao is a fork, so you must track its releases and confirm that the plugins and features you use are shipped in it.
Documented migration covers one Vault version
The OpenBao migration guide describes a node-by-node, in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal. It was tested only against that version. If your Conjur estate is the starting point, this path does not apply directly, and you would need a separate migration plan that re-creates policies and identities. If you run Vault Community on a different version, confirm the upgrade steps with the OpenBao project before you schedule a change window. Mounts that use plugins OpenBao does not ship are skipped during migration, so inventory them first.
Policy and identity rewrite
Moving from Conjur to OpenBao is not a configuration change. Conjur policies, host and layer identities, and authenticator settings have to be translated into OpenBao policies, auth methods and entity roles. Plan this as a parallel run: map each application identity, test secret retrieval in a non-production namespace, and only then cut over. Ask your implementation partner to deliver the mapping as a written artifact so your security team can review the access model before any secret moves.
Kubernetes and CI reconnection
Kubernetes workloads and CI pipelines usually read secrets through sidecars, init containers, or CI variables tied to Conjur identities. Each of these integrations must be reconnected to the new store. The OpenBao Helm chart is the recommended way to install OpenBao on Kubernetes and requires Helm 3.6 or later. Confirm that your cluster meets that requirement, and list every pipeline and workload that reads secrets, so that no integration breaks silently during cutover.
Evidence for the shortlist decision
Before you pick a path, collect evidence from your own environment: the Conjur features in use, the number of policies and machine identities, the plugins behind your dynamic secrets, and the CI and Kubernetes integrations that depend on them. Ask each candidate for its supported feature list and release policy in writing. Compare the cost of operating each option: your staff time, infrastructure for the cluster, backup and upgrade work, and any paid support you choose to buy. A fixed-scope assessment can produce this evidence in a form your architecture board can review.
How Conjur capabilities map to open-source options
This table maps the main capabilities teams rely on in CyberArk Conjur to Conjur Open Source and OpenBao, with each cell marked as full, partial or needing confirmation in your environment. Read the Conjur Open Source column for what stays in the same product family and the OpenBao column for what a move would need to rebuild. The main takeaway is that the supplied facts confirm OpenBao's core secret engines and Kubernetes deployment path, while policy migration, machine identity and audit details must be checked against your own configuration.
| Capability | Conjur Open Source | OpenBao |
|---|---|---|
| Secret storage | Full: Conjur Open Source is the self-hosted server code under LGPL v3.0, so existing secret storage stays in place if you remain on it | Full: encrypted secret storage is a documented OpenBao feature, but moving secrets requires a planned export or migration |
| Policy-based access control | Confirm: review your current Conjur policy files against the version you deploy before assuming they carry over unchanged | Partial: identity-based access control is documented, but Conjur policy statements must be rewritten into OpenBao policies and roles |
| Machine identity | Confirm: check how your host and workload identities are defined and whether they map to your Kubernetes or CI identities | Confirm: plan how workload identities are recreated and tested, since identity models differ between the two products |
| Dynamic secrets | Confirm: verify which dynamic credential types your current setup uses before planning replacements | Full for databases and Kubernetes: documented OpenBao dynamic secrets cover these systems, with leases and revocation |
| Kubernetes authentication | Confirm: validate the authenticator and sidecar or init pattern your clusters use today | Full as a deployment path: the OpenBao Helm chart is the recommended install method and requires Helm 3.6 or later |
| CI integration | Confirm: confirm which CI runners and retrieval methods your pipelines use before changing them | Partial: authentication from CI must be rebuilt for each pipeline and tested end to end |
| Audit logging | Confirm: review log destinations and retention settings in your deployment, since your compliance evidence depends on them | Confirm: enable and test audit devices in your target environment and confirm they meet your evidence requirements |
| Rotation | Confirm: identify which rotation jobs exist and whether they are tied to Conjur features | Partial: lease management and revocation are documented, but scheduled rotation for each target must be built and tested |
| Encryption as a service | Confirm: check whether your applications call encryption features in Conjur Open Source | Full: encryption as a service is a documented OpenBao feature that needs client code changes |
How Conjur policies and machine identities move to OpenBao
Conjur policies and machine identities do not translate one-to-one into OpenBao, so the rewrite is the largest piece of work in a move off Conjur. Conjur organizes access around policy files that declare hosts, groups, layers and variables, and grants permissions on those objects. OpenBao expresses access differently: identities authenticate through auth methods, receive tokens tied to policies written in HCL, and reach secrets through mount paths. Before writing anything new, export your current Conjur policies and map each host, group and variable to the OpenBao concept that will replace it. Treat that mapping as a draft to check against the current documentation for both products, since the object models differ in ways that are easy to miss, such as how group membership is inherited and how nested layers are resolved.
Start the inventory with workloads, not policy files. For each host or application identity, record what it authenticates with today, which variables it reads, and whether it runs on Kubernetes, in a CI pipeline, or on a virtual machine. Then decide one identity per workload instead of reusing a shared host identity, since a shared identity makes it impossible to scope access or trace reads. For Kubernetes, plan roles bound to service accounts and namespaces through the Kubernetes auth method. For CI, plan roles bound to pipeline or runner identity claims from the platform's OIDC or JWT provider. Confirm which auth methods your OpenBao version offers for each platform, because the set you rely on in Conjur may need a different configuration.
Test least privilege before cutover. For each new role, write a policy that grants only the paths the workload read in the inventory, then run the workload against a non-production secret store and confirm that every request outside those paths is denied. Keep the denial tests in version control so they run again after each policy change. Plan for a period where Conjur and OpenBao serve the same secrets, and confirm with your security and compliance owners how audit records from each system will be retained and reviewed during that overlap. Ask your implementation partner or internal team to document the mapping, the decisions behind each identity, and the test results, because those records are what an auditor will ask to see.
What teams give up when they leave Conjur and the usual workarounds
Moving off CyberArk Conjur trades vendor-backed convenience for control over licensing, hosting and operations. The gaps below are the ones that tend to surprise teams, and each comes with a workaround that you should confirm against your own environment before committing to a plan.
Vendor support and SLAs
Under CyberArk's commercial offerings, support terms, response commitments and escalation paths come with a contract. Conjur Open Source is licensed under LGPL v3.0 and has no equivalent guarantee built in, so production incidents depend on your own staff or a third party. Ask any partner for written response times, severity definitions and on-call coverage before you cut over. A support contract with a self-hosting partner, scoped in writing, is the usual replacement, and it should name who patches the server and who answers at 2 a.m.
Conjur policy syntax and tooling
Conjur policies are written in its own YAML-based policy language, and teams often have years of policy files, roles and group memberships built around it. OpenBao uses a different access model based on policies in its own HCL format, so the existing files do not load as they are. Inventory every policy, map each Conjur role to an OpenBao policy and auth role, and test access for each workload before you retire the old policies. Expect the rewrite to take longer than the infrastructure move.
Integrations with other CyberArk products
Conjur is often one part of a wider CyberArk estate, feeding privileged access, credential rotation or audit tooling. Those integrations do not transfer to open source, so any workflow that depends on them needs a replacement or a manual step. List every system that reads from or writes to Conjur, including vendor connectors and custom scripts, and decide for each whether it moves to an OpenBao plugin, a direct API call or a retirement. Confirm which of these connectors you rely on today.
Plugin gaps in OpenBao mounts
The OpenBao migration guide says that mounts using plugins OpenBao does not ship are skipped during the in-place upgrade from Vault. If your secrets engines depend on a plugin that is not in OpenBao, those secrets will not carry over automatically. Audit every mount, flag any plugin without an OpenBao equivalent, and either build a custom plugin, move the secrets to a supported engine, or keep that workload on its current source until a replacement exists. Treat this inventory as a go or no-go input.
Token format changes
The migration guide notes that new tokens use a shorter OpenBao format. Any code, pipeline or sidecar that parses, stores or validates token strings, or that expects a specific prefix or length, will break after the move. Search your repositories and configuration for token handling, update those components, and test every client path before cutover. Plan for tokens issued before the migration to remain valid only as the documented process allows, and confirm that behavior in a staging copy.
In-house operating skills
A self-hosted secrets cluster needs people who can manage unseal procedures, Raft storage, backups, upgrades, certificate rotation and audit log retention. Those skills are a recurring cost whether you run the cluster yourself or buy support, and they are often concentrated in one or two engineers. Document the runbooks, cross-train at least two operators, and decide whether DeployOpen or another implementation partner will provide scoped upgrades, backups and support as a retainer. Ask for the cost of each role in a written quote rather than assuming it.
How to move off CyberArk Conjur in controlled phases
This sequence moves workloads from Conjur to a new secrets platform one application at a time, with inventory, parallel validation and audit evidence captured before the old cluster is retired. Each phase produces a checkpoint that the next phase depends on.
Inventory secrets, policies, identities and consumers
The platform or security team exports a complete picture of what Conjur holds: variables and their owners, the policy files that grant access, host, user and group identities, and every consumer that retrieves secrets, including Kubernetes service accounts, CI jobs, scripts and vendor integrations. Record which consumer uses which variable and how it authenticates. The step is done when every consumer is listed against a secret and an identity, and each unexplained entry has an owner who confirms it is still needed.
Map policies to target access models
Translate each Conjur policy into the equivalent in the target platform. Conjur uses declarative policy files with roles and resource permissions, while OpenBao uses paths, policies and auth methods such as Kubernetes or JWT. Decide where dynamic secrets can replace static variables for databases and Kubernetes, and where a static KV entry is still needed. The output is a written mapping document signed off by the application owners and the security reviewer. Confirm the exact capability coverage of your target platform against its current documentation before you commit to a design.
Export and re-create secrets with controlled access
Move secret values through an approved, logged channel, not an ad hoc file copy. Restrict the export to named operators, store intermediate material encrypted, and delete it once import is verified. Re-create the policy mapping and machine identities in the new platform, and confirm that no consumer can read a path it should not reach. Conjur and OpenBao do not share a migration path, so this is a re-platforming: plan for the new platform to be populated from source values rather than upgraded in place. The check is a reconciliation report that matches the count and hash of each imported secret to its source.
Pilot one non-critical application
Choose a single application with a low blast radius, a known owner and a rollback path. Point its configuration at the new platform in a test environment, rotate its credentials through the new identity, and run its normal functional tests. Note any change in startup behavior, latency or error handling. The pilot is complete when the application passes its tests, the rollback procedure has been rehearsed once, and the team agrees the identity model works for the next workloads.
Run both platforms in parallel with dual reads
For each migrated workload, read from the new platform while keeping the Conjur value available as a fallback, then compare results over a defined observation window agreed in advance. Log every mismatch and every fallback event, and treat any unexplained mismatch as a blocker. Keep write paths on Conjur until the reads are stable, so a single source of truth exists at each moment. The step closes when the comparison log shows no unexplained differences and the owners sign off on the observed behavior.
Cut over each workload in sequence
Switch one workload at a time to read and write only from the new platform, starting with lower-risk services and ending with those that have the largest number of consumers. Update CI pipelines and Kubernetes manifests, remove the Conjur authenticator from the workload, and revoke the old identity once the switch is verified. Each cutover should have a named owner, a change record and a documented rollback. The checkpoint for each workload is a passing health check, an empty fallback log and a closed change ticket.
Capture audit evidence before decommissioning
Before the old Conjur cluster is shut down, collect the evidence an auditor or assessor will ask for: the inventory, the policy mapping, reconciliation reports, cutover change records, access logs from both platforms, and the revocation record for old identities. Store these in a controlled repository with retention set by your compliance obligations. Ask your assessor which evidence formats they accept. The step is done when the evidence package is reviewed and accepted by the control owner.
Decommission the Conjur cluster and its backups
Once evidence is captured and no workload reads from Conjur, stop the cluster, remove its network access, and destroy its data stores and backups according to your retention and destruction policy. Confirm which Conjur backups, database snapshots and certificates must be retained for legal or audit reasons, and keep only those under restricted access. Record the decommission date and the person who approved it. The sequence is complete when no active consumer, network route or unmanaged copy of Conjur data remains.
Which option fits by situation
Teams that have already written Conjur policies, host identities and variable permissions often gain the most by staying put. Conjur Open Source server code is licensed under the GNU LGPL v3.0, so you can keep running it in your own network while you decide on the longer-term platform. This path avoids rewriting policies and retraining application owners on a new access model during a period when other work is already heavy.
- Lowest change load: Existing policy files, layers and host annotations keep working without a rewrite.
- Clear licensing boundary: Confirm with your legal team how the LGPL v3.0 terms and CyberArk's commercial offerings apply to your deployment and any modifications you make.
- Support is yours to arrange: Open-source use leaves patching, upgrades and incident response with your team or a partner you engage.
- Feature gap check: Compare the commercial features you actually rely on, such as enterprise integrations, with what the open-source build provides in your environment.
- Future option: Staying does not close the door on OpenBao later, but a second migration will cost effort.
Before committing, ask CyberArk and your own engineers which features your current contracts depend on and whether the open-source release covers them.
Teams that want a Vault-compatible ecosystem, or that run most workloads on Kubernetes, often find OpenBao a practical target. OpenBao is an MPL 2.0 fork of Vault that provides encrypted secret storage, dynamic secrets for databases and Kubernetes, encryption as a service and lease management with revocation. The OpenBao Helm chart is the recommended installation method on Kubernetes and requires Helm 3.6 or later, which makes the deployment repeatable across clusters.
- Vault-style clients: Many tools that already speak the Vault API can be pointed at OpenBao, but test each integration rather than assuming parity.
- Kubernetes-native install: Use the Helm chart and confirm the Helm version in your pipeline meets the 3.6 minimum.
- Policy rewrite required: Conjur policies must be translated into OpenBao policies and identity mappings, which is the largest part of the effort.
- Machine identity rework: Host, Kubernetes service account and CI identities need new authentication methods and role bindings.
- Version and plugin checks: Review the migration guide for the tested source version and any plugins OpenBao does not ship.
Ask your platform team to inventory every Conjur consumer, including CI jobs, before scoping the work.
Data residency requirements often decide the question before features do. When secrets must stay inside a specific data center, cloud account or air-gapped network, a self-hosted secrets platform gives you direct control over where storage, unseal material and audit logs live. Both Conjur and OpenBao can be deployed inside your own infrastructure, so the choice turns on which platform your team can run and evidence well.
- Storage location: Decide where the storage backend, backups and audit logs reside, and document each location.
- Unseal and key custody: Plan how unseal keys or auto-unseal keys are held and who can access them.
- Connectivity: Confirm which application and CI networks must reach the secrets service, and avoid routes that leave the approved boundary.
- Backup and restore: Test restores inside the same residency boundary, not only the initial install.
- Upgrade path: Choose a platform whose upgrades you can perform without sending data to external services.
Confirm residency obligations with your legal and privacy teams before you pick a target, because they may restrict hosting providers as well as data locations.
Regulated teams need to show an assessor how secrets are created, accessed, rotated and revoked, and that those controls operate. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors make that determination. Your choice between staying on Conjur and moving to OpenBao should account for how much evidence your existing tooling already produces and how much you will need to build.
- Audit logging: Confirm which access and administrative events are logged, where they are stored and how long they are retained.
- Access reviews: Define how policy or role assignments are reviewed and by whom, and produce those reports on a schedule.
- Change records: Keep policy and configuration changes in version control with approvals attached.
- Rotation and revocation evidence: Show that dynamic or rotated secrets expire as designed.
- Assessor scope: Agree the control set and evidence format with your assessor before migration so the cutover does not invalidate prior evidence.
Ask your assessor which control frameworks apply and which evidence they expect from a self-hosted secrets platform.
How much effort and cost does moving off CyberArk Conjur take?
What drives the total effort of moving off CyberArk Conjur?
The effort depends mostly on how many policies, machine identities and workloads read secrets from Conjur, and on whether you stay on Conjur Open Source or move to OpenBao. Each workload needs its authentication method and secret paths mapped to the new platform, and each policy needs to be rewritten or re-expressed. Teams with few applications and clean policies move quickly. Teams with many Kubernetes clusters, CI pipelines and legacy hosts that fetch secrets by hand spend most of their time on those integrations and on testing. Ask any provider to break the estimate down by workload type and by environment.
What does the cost of a Conjur exit include?
The cost has three parts: software, infrastructure and labor. Conjur Open Source and OpenBao carry no license fee for the server code, so your recurring costs are the compute, storage, backup and high availability you run yourself, plus the staff time to operate them. The one-time costs are design, policy migration, workload reconnection, testing and cutover. Commercial CyberArk offerings are priced separately and by quote, so compare your current contract against the full run cost of the self-hosted platform, not only the license line.
How long does it take to reach a pilot?
No researched timeline for this migration is available, so treat any duration you hear as unverified until the provider states it against a written scope. A pilot usually covers one environment, a small set of policies and a few representative workloads, which keeps the first milestone bounded. Ask the provider to name the pilot's entry criteria, the workloads included, the test evidence it will produce and the decision that follows it. A pilot that only proves the platform starts is less useful than one that proves a real application can read and rotate its secrets.
What does the migration need from our own team?
Your team needs an owner for the target platform, people who know the current Conjur policies and the applications that depend on them, and a security reviewer who can approve access models. Platform engineers handle the cluster, storage, unseal and backup design. Application owners confirm which secrets each service reads and when it can change its configuration. Plan time for change windows and for the staff who will run the platform after handover, because operating a self-hosted secrets service is an ongoing responsibility.
Can our own team do the migration without an outside provider?
Yes, a team with Kubernetes, secrets and identity experience can do this in-house, and the open-source licenses do not require an outside firm. The question is capacity and risk. Conjur policy translation, machine identity changes and cutover testing are work that usually stalls when the same engineers also run production. If you go in-house, write down the scope, assign owners, and agree on test and rollback steps before you start. An outside partner can take on defined pieces under a fixed scope, such as the target design, workload reconnection or security testing of the result.
How do I compare two migration quotes fairly?
Compare the written scope before comparing the totals. Each quote should list the platform version and deployment model, the number of policies and workloads in scope, the Kubernetes and CI integrations, the testing and cutover plan, the documentation and handover, and what happens after go-live. Ask whether the quote includes backup and restore testing, unseal and key handling, and training for your staff. Check exclusions carefully, since they often hide the largest costs. Ask for the assumptions behind any duration, and whether support or upgrades are priced separately as a retainer.
Does the OpenBao upgrade path apply to Conjur?
No. The documented OpenBao migration path starts from HashiCorp Vault Community 1.14.1 on Raft storage with Shamir unseal, and it was tested only against that version. It does not cover Conjur, which has its own data model, policy language and API. Conjur Open Source is licensed under the GNU LGPL v3.0, so staying on it is a valid option, and moving to OpenBao means a re-platforming project that rewrites policies and machine identities. Confirm with any provider how it will map Conjur policies to the target model and what it will test.
What happens to audit evidence during the migration?
Keep the existing Conjur audit logs and access records archived and readable until your retention obligations are met, because the new platform will start its own log trail. Document the cutover date, the policy mapping, and every identity that moved, so auditors can follow a secret from the old system to the new one. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Your auditor or certification body makes that determination, so confirm with them which evidence they will require before cutover.
How DeployOpen scopes, migrates and supports the replacement
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move away from CyberArk Conjur, the work starts with a written scope that separates staying on Conjur Open Source from moving to a different open-source platform, so each change is agreed before it is built.
How we scope
- Inventory every Conjur policy, host, layer and machine identity that applications and pipelines depend on today
- Record which workloads use Kubernetes authenticators, CI integrations and direct API calls
- Agree in writing whether the target is Conjur Open Source or OpenBao, with the reasons stated
- Engagements are fixed-scope, so deliverables and timelines are confirmed before work starts
How we build
- Rewrite policies and machine identities for the target platform, with each mapping documented
- Reconnect Kubernetes and CI workloads, then test secret retrieval and access denial in a non-production environment
- Run security testing against the new access paths and secret delivery methods before cutover
- Set up backup, monitoring and audit logging in the client's own cloud account or data center
How we hand over
- Deliver architecture records, policy files, runbooks and a per-workload migration log
- Walk through rollback steps for each workload group with the client's platform and security teams
- Provide evidence of configuration and access controls that the client can share with its own auditors
- DeployOpen prepares controls and evidence but does not issue audit reports or certifications
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover version upgrades, such as tracking OpenBao releases and their security fixes
- Confirm the response expectations and upgrade cadence in the written retainer scope
- Plan periodic reviews of machine identities and policies as applications change
