Choosing between CyberArk Conjur and Infisical for secrets management
Choose Conjur or CyberArk's commercial Secrets Manager when the estate is already built around CyberArk and the cost of changing it outweighs the cost of renewal. That usually means existing policies, host identities and integrations across Kubernetes, CI pipelines and cloud workloads, plus audit and privileged access processes that already reference CyberArk. Infisical fits better when the driver is the renewal itself, a licensing change, or a wish to give developers a self-service workflow for secrets, and when the team is ready to run a new platform. Neither answer is permanent. Confirm with your CyberArk account team what your current subscription covers, how a Conjur Open Source deployment would be supported, and which features you would lose or gain if you move.
The decision turns on four questions. First, how deep is the existing CyberArk estate: how many Conjur policies, host identities and Kubernetes integrations depend on it, and how many of those would need to be rebuilt. Second, what developers need day to day: Infisical's dashboard per project and environment, secret syncs and CLI-driven access may suit teams that work outside platform engineering. Third, identity and access requirements: Infisical supports Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth machine identities, with RBAC, access requests and approval workflows, but SSO and gateways require an enterprise license under Infisical's self-hosting terms. Map every SSO and network-access requirement to a line item before you compare prices.
The fourth question is in-house capacity. Self-hosting Infisical means operating its container, Helm or Linux package deployment, the bundled PostgreSQL and Redis components, backups and upgrades, and the enterprise license if you need SSO or gateways. Conjur Open Source carries similar operating work, while a commercial subscription shifts some of it to the vendor. Ask your team who will own on-call, key handling and upgrades for the next three years, and get written scope from any implementation partner before you commit to either path.
Which option fits which scenario
This table maps common situations to the platform that usually fits best, with the reason and any point where Infisical's enterprise license matters. Read it against your own estate: the right choice depends on whether you already run CyberArk privileged access, how developers and pipelines consume secrets, and which features your identity and licensing rules require.
| Scenario | Better fit | Reason and license note |
|---|---|---|
| Existing CyberArk privileged access estate | Conjur or CyberArk Secrets Manager | Keeps machine secrets under the same vendor, audit tooling and operating model as your PAM suite. Confirm contract terms and support scope before any change. |
| Developer and CI secret syncing | Infisical | Dashboard per project and environment, plus syncs to platforms such as GitHub, Vercel and AWS, reduce custom pipeline code. Confirm which sync targets you need on the free tier. |
| Kubernetes workloads | Infisical for teams wanting an operator; Conjur for policy-driven host identities | Infisical's Kubernetes operator reloads deployments when secrets change. Conjur's Kubernetes authenticator suits teams already modeling workloads in its policy language. Test both against your cluster setup. |
| Dynamic database credentials | Conjur or CyberArk Secrets Manager for broad coverage; Infisical for PostgreSQL and MySQL | Infisical lists dynamic secrets for PostgreSQL and MySQL. Confirm which database engines and rotation patterns your Conjur or CyberArk version supports before choosing. |
| Single sign-on for administrators | Confirm before choosing Infisical | Self-hosted SSO in Infisical requires an enterprise license per its self-hosting documentation. Budget that license in the quote, or plan an external identity provider path. |
| Gateways into private networks | Confirm before choosing Infisical | Gateways are listed among enterprise features needing enterprise licensing. Compare with CyberArk's own network connectors if private reachability is a hard requirement. |
| Strict open-source licensing needs | Infisical core or Conjur Open Source, with care | Infisical core is MIT Expat outside ee directories, and Conjur server code is LGPL v3.0. Have counsel review the ee directory license and any enterprise features you plan to run. |
| Mixed PAM and developer teams | Both, split by use case | Many organizations keep privileged human access in their PAM suite and use Infisical for application and pipeline secrets. Define ownership and sync boundaries in writing first. |
What the open-core split means for SSO and gateways
The licensing question for Infisical is narrower than the word "open source" suggests. The core repository is published under the MIT Expat license, but content in any ee directory falls under a separate license in ee/LICENSE. Infisical's self-hosting documentation states that enterprise features such as SSO or gateways require enterprise licensing. In practice, a team that self-hosts the MIT-licensed core can run secrets, projects, RBAC and machine identity authentication without a commercial agreement, but it should not assume that single sign-on for staff or gateway features are included. Before committing, confirm with Infisical exactly which features sit inside the ee code, and read the license file for the terms that apply to them.
Conjur Open Source takes a different split. The server code is licensed under the GNU LGPL v3.0, and API clients and extensions are under Apache 2.0, so the open-source server is not gated behind a feature tier in the same way. CyberArk sells separate commercial offerings on top, and the commercial Secrets Manager products are where enterprise capabilities are positioned. The licensing model matters differently depending on your situation. If you need SSO for every engineer and operator who touches secrets, or you need gateway-style network controls across many environments, price the enterprise tier for Infisical or the commercial CyberArk product into your plan from the start. If you only need machine identity access for a bounded set of workloads, the open-source core may be enough, but confirm that with each vendor in writing.
The licensing model matters most when you plan to modify or redistribute the software. LGPL obligations apply to modifications to the covered library code and require you to make those changes available under its terms, while MIT Expat places few conditions on your code, but the ee content still carries its own license. Ask counsel to review both licenses against your intended use, including any internal forks, custom integrations, or plans to offer the platform to subsidiaries or partners. Document the decision, the feature list you rely on, and the license version you reviewed, so that a renewal or audit does not turn into a surprise.
Where secrets live and who controls the data
Both products can keep secrets inside your own network, but they differ in what you run, who operates the control plane and which features need a paid license. The cards below cover the deployment choices that decide where secret values, audit logs and encryption keys sit, and what your compliance evidence has to show.
Self-hosting Infisical on your infrastructure
Infisical's self-hosting documentation lists a single Docker container, Docker Compose, an official Helm chart, Linux packages and AWS or GCP reference deployments. Each option decides where the application, its database and its encryption keys run. Confirm which option fits your change process, and who holds the database backups, since those contain every secret your teams store. Ask the vendor which deployment patterns it tests and supports before you commit to one.
Bundled PostgreSQL and Redis in the Helm chart
The official Helm chart can deploy PostgreSQL and Redis alongside Infisical. That speeds up a pilot but also means your secret store depends on data services your platform team may not run to production standards. Decide whether to use the bundled databases or point the chart at managed or existing instances, and confirm backup, restore and high availability for each. Check who patches those services and how upgrades are sequenced.
Infisical Cloud as the hosted option
Infisical Cloud is the vendor's hosted service, and teams can sign up for it free. Using it means secret values, metadata and audit records are stored in the vendor's environment rather than yours. That may suit non-regulated workloads, but a data residency or sovereignty requirement will likely rule it out for production secrets. Ask where data is stored, how it is encrypted, and what the vendor's incident and access logging covers before you classify it.
Conjur deployment choices
Conjur Open Source is licensed under the GNU LGPL v3.0, and CyberArk sells separate commercial offerings with its own deployment models. Confirm which edition you run, what the license obliges you to publish if you modify the server code, and whether your support path depends on a commercial agreement. Map each Conjur component, including the database and any appliance, to a team that owns its patching and recovery.
Identity and compliance evidence
Where secrets live determines which controls an assessor will test: access control, encryption at rest and in transit, key custody, logging and change management. DeployOpen prepares systems, configuration and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors make those determinations. Before you choose, ask your assessor which evidence they expect from the secret store and the hosting model.
What running each option takes day to day
Self-hosting Infisical on Kubernetes puts upgrades, availability, backups and monitoring with your team. Infisical publishes a Helm chart that can bundle PostgreSQL and Redis, but a bundled database is a convenience for evaluation and is rarely the right production setup. Your platform team decides whether to use the bundled services or external managed databases, and then owns their sizing, patching and restore testing.
- Upgrades: Infisical ships tagged releases frequently. The release v0.166.8, published on October 15, 2026, shows the cadence to expect. Test each chart and image version in a non-production cluster, read the release notes for database migrations, and schedule the rollout in a window you control.
- High availability: Run more than one application replica behind a load balancer, and confirm the PostgreSQL and Redis topology you chose. Ask the chart maintainers which settings are supported for multi-replica operation.
- Backups: Back up PostgreSQL on a schedule and test restores. The encryption key that protects stored secrets must be backed up separately and stored securely, because a database restore without it does not recover secret values.
- Monitoring: Collect pod health, database metrics and application logs, and alert on failed syncs and authentication errors from workloads.
Before committing, confirm with Infisical's self-hosting documentation which features your edition covers, since SSO and gateways require an enterprise license.
Infisical Cloud is the vendor's hosted service, and teams can sign up for it free. The vendor operates the control plane, so upgrades, database operations and infrastructure availability move to Infisical. Your team still owns how it is configured: projects, environments, machine identities, access policies, secret syncs and rotation schedules. Those choices carry the security risk even when the infrastructure is managed.
- Upgrades: The vendor applies platform updates. Your team reviews release notes for changes to authentication methods, sync behavior or API endpoints that your pipelines depend on.
- High availability and recovery: Ask the vendor for its availability commitments, regional placement and recovery objectives in writing. These terms are not something this page can confirm.
- Backups: Confirm what the vendor backs up, how long backups are retained, and how you would recover a deleted project or secret version. Secret versioning gives you point-in-time recovery within the product, which your team should test.
- Monitoring: Use the audit logs the product exposes and forward them to your SIEM. Watch machine identity usage for unexpected workloads.
- Ownership: Name an owner for identity onboarding, offboarding and quarterly access reviews, since these stay with you under any hosting model.
If data residency is a requirement, confirm where the hosted data is stored before choosing this model.
Running Conjur Open Source or CyberArk's commercial Secrets Manager means operating a policy-driven secrets service with its own storage, authenticators and vendor support model. Conjur Open Source is licensed under the GNU LGPL v3.0, and CyberArk documents a migration path to its self-hosted commercial product. Your team owns the deployment, the database or storage layer, certificate handling and the policy repository, while commercial terms determine what support and upgrade assistance you receive.
- Upgrades: Plan upgrades against the Conjur release notes in the project's GitHub repository, and test policy loads in staging before production. For commercial editions, confirm the upgrade path and support windows with CyberArk.
- High availability: Confirm the supported standby and replication topology for your version, and rehearse failover, since Conjur's clustering model differs from Infisical's.
- Backups: Conjur's export tooling is designed for its own format, so plan backups of the underlying database and the encryption material as separate, tested items.
- Monitoring: Track authenticator errors, policy load failures and host authentication volume, and route these into your existing observability stack.
- Ownership: Policy changes are code, so assign reviewers from the security team and keep the policy repository under the same change control as infrastructure.
Ask CyberArk to state in writing which components and support tiers are included in your subscription before you size the team.
Day-to-day work splits across several roles, and the split changes with the deployment model. Security engineers usually own access policy, machine identity design and audit review. Platform engineers own the cluster, database, upgrades and backups for self-hosted options. Application owners own how their workloads request and consume secrets, including reload behavior after a rotation.
- Security team: Reviews access requests and approvals, rotation schedules and audit log exceptions.
- Platform team: Runs upgrades, capacity, restore tests and certificate renewals for self-hosted deployments.
- Application owners: Validate secret reloads, rotation handling and fallback behavior when a secret changes.
- Compliance and audit: Collects evidence of access reviews, change records and backup tests. DeployOpen prepares these controls and evidence, but independent auditors issue any assessment.
- Escalation path: Define who responds when a secrets service is down and whether workloads can keep running on cached values.
Before you choose a model, write this ownership map and confirm that your team has the skills and on-call coverage it requires.
What drives the cost of each option
Each option spreads cost differently across licenses, infrastructure, people and migration work. The cards below separate what you pay a vendor, what you pay a cloud or data center provider, what your own staff carry, and what is paid once during the move. Use them as a checklist when comparing a CyberArk quote with a self-hosted Infisical plan.
Commercial subscription or quote
CyberArk's commercial Secrets Manager terms and Infisical's enterprise terms are both sold by quote, and the Conjur Open Source server code carries no license fee of its own. Ask each vendor which features are included in the quoted tier, how machine identities are counted, and whether the price changes with the number of secrets, hosts or environments. Ask for the renewal and true-up terms in writing, since these recur every year and often drive total cost more than the first-year figure. The open-source Infisical software itself carries no license fee under its MIT Expat license, but features such as SSO or gateways need an enterprise license.
Infrastructure hosting
Self-hosted Infisical runs as a single Docker container, Docker Compose stack, or Helm chart on infrastructure you already pay for or provision. Recurring cost comes from compute, storage, backups and network in your cloud account or data center, and it grows with high availability replicas and separate environments for staging and production. Ask whether your cloud commitments or existing Kubernetes clusters can absorb the workload, and whether the design needs a second region for recovery.
Enterprise license for Infisical features
Infisical's self-hosting documentation states that enterprise features such as SSO or gateways require an enterprise license. If your rollout depends on SSO for operators or on gateways that reach private networks, that license becomes a recurring line item that sits outside the open-source core. Confirm exactly which features are behind the license before you design around them, and request the license terms and renewal conditions in writing so that the comparison with CyberArk's quote is like for like.
Database and Redis operation
The official Infisical Helm chart can deploy bundled PostgreSQL and Redis, but a production deployment usually moves these to managed or separately operated services. Those services carry backup schedules, patching, failover testing and storage growth, all of which recur. Decide early whether your team already runs PostgreSQL and Redis well enough to take on another stateful tier, because that choice shifts cost between a managed service fee and internal operating time.
Staff time for operations and access design
Most ongoing cost in a self-hosted secrets platform is people time: upgrades, certificate and key handling, access policy reviews, rotation tuning and on-call coverage. Estimate this as a share of named engineers, and record who owns each task. Ask the CyberArk side what support and professional services are included, and ask yourself whether the platform team can handle RBAC design, access request approvals and dynamic database secret configuration without outside help.
One-time migration project
Moving from Conjur to Infisical is a one-time project covering secret export, re-entry or sync, policy redesign, and reconnecting Kubernetes workloads, CI pipelines and cloud identities. Conjur policies do not map directly onto Infisical's project, environment and RBAC model, so budget time for design and testing before cutover. Ask any implementation partner for a fixed-scope written plan with deliverables and a timeline, and ask CyberArk for the same clarity on any migration tooling it offers.
What a move from Conjur to Infisical involves
The sequence turns Conjur policies, host identities and variables into Infisical projects, machine identities and access roles, then moves workloads over in stages so each environment can be checked and rolled back. The result is a tested Infisical deployment that serves every workload Conjur served before the old store is retired.
Inventory hosts, policies and variables
Your team lists every Conjur host, layer, group, policy and variable, and records which workloads read each one, including Kubernetes deployments, CI pipelines and cloud services. Conjur policy files and the variable list are the main inputs, and the inventory is complete when every secret has an owner, a consuming workload and a target location in Infisical. Gaps found here, such as secrets read by scripts nobody remembers, are much cheaper to fix before cutover.
Design the Infisical project and environment structure
Architects decide how Conjur policy branches map to Infisical projects, environments and folders, and which teams administer each one. Because Infisical organizes secrets by project and environment with a dashboard for each, this step turns the policy hierarchy into a layout that people can read. The output is a written structure agreed by security and platform owners, with naming rules for secret paths.
Map host identities to machine identities and roles
Each Conjur host identity is translated into an Infisical machine identity, and each permission grant is rebuilt as an RBAC role or access policy. Infisical supports Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine authentication, so the team chooses the method that matches each workload's platform and checks it against the original Conjur grant. Done means every identity has a documented method and a role that grants only the access it had before.
Re-read secrets through the API, not the export
Secret values are read from Conjur through its API and written to Infisical through its API or the CLI, under a controlled process with logging and restricted access. The conjurctl export archive is not used as an import file, because it is an encrypted archive with a separate key file that was designed for backup and restore within Conjur. The step is complete when a sample of values in Infisical matches Conjur for each project, verified by a method the security team agrees on.
Reconnect Kubernetes, CI and cloud workloads
Platform engineers point workloads at Infisical, using the Kubernetes operator where it fits, the agent for injection without code changes, or direct API and SDK calls for custom code. Each workload is switched in a non-production environment first, and its logs and application behavior are reviewed before production. The check is that every workload reads its secrets from Infisical and that no workload still depends on a Conjur endpoint.
Set up rotation and dynamic secrets
Teams configure rotation for secrets that need it and dynamic secrets for supported databases such as PostgreSQL and MySQL, replacing static database passwords that Conjur held as variables. Owners confirm which credentials the database and application can rotate without downtime, and test one rotation cycle before enabling it broadly. The output is a list of rotated and dynamic secrets, each with an owner and a documented recovery procedure.
Cut over in stages with a rollback path
Production workloads move in groups, with Conjur kept read-only and available until each group has run stably on Infisical for a period the change board sets. Rollback means pointing a workload back to Conjur, which works only while the Conjur values remain current, so updates are frozen or dual-written during the window. Cutover is closed when no production workload reads from Conjur, and the old store is retained under an agreed retention and access policy.
Document, audit and hand over operations
The team records the final inventory, identity mappings, role definitions, rotation schedules and runbooks, and checks how Infisical audit logs and access requests will feed existing monitoring. Ask any implementation partner to deliver this record in writing as part of the fixed scope. The step ends when operators can run Infisical independently and the evidence set is ready for internal or external assessors.
Questions buyers ask before switching from Conjur
How much does switching from Conjur to Infisical cost?
The cost is mostly people's time, plus whatever hosting you choose, and no supplied fact gives a figure for either. Infisical's self-hosted edition is open source under the MIT Expat license outside the ee directory, so the license fee is zero for the core features. The costs that remain are the infrastructure to run Infisical with PostgreSQL and Redis, the engineering work to re-point each workload, and any enterprise license you need for SSO or gateways. Recurring costs are infrastructure, upgrades and support. Ask any services partner for a fixed-scope quote built from your inventory of hosts, pipelines, policies and secrets, and ask Infisical for current enterprise licensing terms before you plan around them.
How long does a migration from Conjur to Infisical take?
Duration depends on estate size and on how much policy you must redesign, and no supplied fact gives a timeline. Plan for the number of workloads, pipelines and Conjur policies that reference secrets, the number of secrets and whether they are static or need rotation, and how many environments must run in parallel during cutover. A small estate with one Kubernetes cluster and a few pipelines will move far faster than a multi-cloud estate with many teams. Ask for a phased plan with a pilot workload, a parallel-run period and an agreed rollback point, and confirm each milestone in writing before work starts.
What does our team need to provide for the migration?
You need named owners for the workloads, the Conjur policy tree, the secret inventory and the cloud accounts or clusters that will authenticate to the new system. Your team should also decide who approves access requests in the new RBAC model and who holds the keys for the Infisical deployment. In practice, the team must supply read access to Conjur, a list of consumers, change windows for production workloads and test environments that mirror production. Without these inputs, the work stalls at the discovery stage, so confirm them before a scope is signed.
Can an internal team migrate from Conjur to Infisical alone?
An experienced internal team can do it, provided it has people who understand Conjur policy, Kubernetes or cloud identity, and the Infisical deployment model. The hard parts are translating Conjur host identities into Infisical machine identities, rewriting retrieval code, and proving that secrets rotate and sync correctly. Teams without that mix often choose a fixed-scope engagement for the design and cutover while keeping operational ownership in house. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, so you can split the work in whatever way fits your staff.
Does Infisical require an enterprise license for SSO?
Yes, according to Infisical's self-hosting documentation, enterprise features such as SSO and gateways require enterprise licensing. The core secrets features, machine identity authentication and the Kubernetes operator are part of the open-source edition under the MIT Expat license. Before you commit, confirm with Infisical exactly which features your identity provider integration and network gateway needs fall under, because feature boundaries can change between releases. Also check whether your SSO requirement can be met by another route in your environment.
Can we import the conjurctl export directly into Infisical?
No, a direct import is not the right approach. The conjurctl export produces an encrypted archive plus a separate key file, and it was designed for moving Conjur data between Conjur instances, not for loading secrets into another product. The practical path is to read each secret through an authorized process, recreate the structure in Infisical projects and environments, and translate Conjur policy into Infisical RBAC, roles and identities. Plan this as a migration project with verification, not an import, and confirm the export's scope with CyberArk documentation for your Conjur version.
What breaks during a Conjur to Infisical cutover?
The usual failures are workloads that still request secrets from Conjur after cutover, identities that authenticate but lack the right access, and rotation jobs that were never moved. Expect problems with pipeline variables, Kubernetes secrets reloaded by old manifests, and cloud roles that trust the wrong principal. Check each workload's authentication path, confirm that Kubernetes, AWS, GCP, Azure or OIDC identities map to a single Infisical role, and test rotation and dynamic database secrets in staging. Keep Conjur read-only during a parallel run so you can compare values and roll back a workload quickly.
When staying on Conjur still makes sense
Staying on Conjur or CyberArk Secrets Manager is the better choice when the secrets decision is already bound to a CyberArk privileged access estate. If your organization licenses CyberArk for privileged account management and session control, the machine secrets it issues often sit inside the same vault, approval flows and reporting that auditors already review. Moving those secrets to Infisical would split evidence across two systems, and the cost of that split usually outweighs the license difference. Before deciding, confirm with your CyberArk account team which modules are in your current contract and whether Conjur or Secrets Manager is covered under it.
Audit workflows are the second condition. If your control evidence for machine access is built around CyberArk reports, such as who retrieved a credential, which host identity requested it and how policy changes were approved, then the replacement must reproduce those records before cutover. Map each report your assessors rely on to a source in Infisical, including its audit log export and access request history, and confirm that retention and export formats meet your assessor's needs. Do not assume that the feature list alone answers an audit question.
The third condition is people. Teams that already write Conjur policy files, understand its role and host model, and run its existing pipelines can be productive faster than a team learning a new access model. Infisical's RBAC, temporary access and approval workflows are a different way to express the same intent, so a migration will require retraining and rewritten runbooks. If your platform team is small and the workload is narrow, keeping Conjur and tightening its operations may be the lower-risk path, provided the open-source server still meets your support and upgrade needs.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Conjur versus Infisical decision, we start by mapping which machine identities, workloads and access rules you actually depend on, then build and hand over the platform you choose.
How we scope
- We inventory your Conjur policies, host identities and the workloads that read secrets today.
- We define which workload authentication methods to support, such as Kubernetes, AWS, GCP, Azure or OIDC.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Infisical in your infrastructure using the Docker, Compose or Helm options you select.
- We configure RBAC, access requests and approval workflows to match your existing approval chains.
- We test rotation, dynamic database secrets and Kubernetes delivery in a staging environment before cutover.
How we hand over
- We document the architecture, authentication configuration, policies and runbooks for your operations team.
- We confirm with you which enterprise features, such as SSO or gateways, require a license before go-live.
- We deliver backup and restore procedures, and walk your team through the handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can apply new Infisical releases in your environment and retest integrations after each upgrade.
- We prepare systems and evidence for compliance assessments, while independent auditors issue any reports.
