Argo CD or Jenkins: when to choose each for Kubernetes delivery
A platform team deciding how changes reach production has to choose where the deployment logic runs and who holds the keys to the cluster. Argo CD fits when the desired state of Kubernetes workloads should live in Git and a controller inside or near the cluster should keep the live state matching it. It watches repositories, shows drift between Git and the running objects, and can manage several clusters from one control plane with SSO over OIDC, OAuth2, LDAP or SAML 2.0 and its own RBAC. Jenkins fits better when the main job is broad build and test automation, when deployment targets are not Kubernetes (virtual machines, appliances, managed services reached through plugins), or when the organization already runs a large Jenkins estate with established plugins, shared libraries and operator knowledge. Jenkins is MIT licensed, so the decision is about operating model rather than license cost.
Argo CD is not a build system, and Jenkins is not a drift detector by default. Before committing, confirm which targets must be reached, since the Argo CD high availability documentation requires at least three nodes for its HA manifests and Jenkins deployments depend on how the controller and build agents are laid out, as described in the Jenkins scaling guide. Check whether the Jenkins estate already has a Kubernetes plugin path for agents and whether teams can move their deploy stages into Git-committed manifests without rewriting their tests. Also confirm which pipeline steps (approvals, environment promotion, secret injection) your auditors expect to see in a particular system, because those steps move with the choice.
The decision turns on three questions. First, where does the deployment target run? If it is a Kubernetes cluster, Argo CD's model fits closely; if it is mixed, Jenkins or another pipeline tool may still need to handle the non-cluster steps. Second, who may hold cluster credentials? In a push model, the CI system often holds credentials that can change the cluster, while in Argo CD the controller in the cluster pulls from Git, which narrows what CI needs. Confirm how Argo CD repository access is set up, since Argo CD 3.0 requires repositories to be defined as Kubernetes Secrets. Third, how much pipeline logic must stay in CI? The two are often complementary: Jenkins builds, tests and publishes artifacts, and Argo CD reconciles the manifests that reference them. That split is the common pattern, but it should be tested against your own change approval flow before you adopt it.
Which platform fits which scenario
This table maps common team situations to the platform that usually fits better and the condition under which the other one wins. Read each row against your own estate, since the right answer depends on where your workloads run and who must prove what changed.
| Scenario | Better fit | Reason and the condition under which the other option wins |
|---|---|---|
| Kubernetes-only delivery | Argo CD | Argo CD is a Kubernetes controller that reconciles clusters from Git, so deployment state is visible in one place. Jenkins wins if you still need a generic build runner that also pushes to non-Kubernetes targets. |
| Mixed VM and Kubernetes estate | Jenkins for deployment, or Argo CD with Jenkins for builds | Argo CD manages Kubernetes resources only, so VM changes need another tool. Jenkins can run playbooks and scripts against both, which makes it the simpler single tool if Kubernetes is a minority of targets. |
| Heavy build and test workloads | Jenkins | Jenkins distributes work to build agents across machines and has a large plugin ecosystem for test reporting. Argo CD does not build code, so it fits the deployment step after a separate CI system has produced artifacts. |
| Regulated change control with audit trails | Argo CD, if Git is the approved change record | Argo CD keeps desired state in Git and reports drift against it, which gives assessors a clear change history. Confirm with your auditors whether Kubernetes object history and Argo CD logs meet your evidence requirements, and whether Jenkins job logs would be the stronger record in your process. |
| Teams already invested in Jenkins plugins | Jenkins | Existing pipelines, shared libraries and plugin-based integrations carry real migration cost to replace. Argo CD becomes the better choice when those pipelines are being rebuilt anyway, or when only the Kubernetes deployment step needs to change. |
| Central access control for many teams | Argo CD | Argo CD integrates SSO over OIDC, OAuth2, LDAP and SAML 2.0 with RBAC, and manages multiple clusters from one controller. Jenkins can be scaled by adding controllers per team, which suits teams that want isolated administration. |
How Argo CD and Jenkins are built and deployed
Argo CD and Jenkins both automate delivery, but they sit in different places. Argo CD is a controller that runs inside a Kubernetes cluster and reconciles it against Git, while Jenkins is a controller with build agents that pushes work out to machines. The cards below show where each keeps its state and what that means for backup, high availability and day-two operations.
Argo CD as a Kubernetes controller
Argo CD runs inside the cluster it manages, with a web UI and an API server alongside the application controller. Its high availability manifests need at least three nodes because of pod anti-affinity rules, so a small cluster may need to run the non-HA install. Before you commit, confirm that your cluster has enough nodes to schedule the replicas and that you are not planning IPv6-only networking, which the documentation says is not supported.
Largely stateless with Kubernetes objects
Argo CD keeps its configuration and application state in Kubernetes objects, so the cluster's etcd becomes the place your recovery plan relies on. Redis is a disposable cache and can be rebuilt without data loss, while the application controller can be sharded across replicas. Your backup scope is therefore the cluster objects and the Git repositories, not a separate Argo CD database. Confirm how your team backs up and restores those objects.
Jenkins controller and build agents
Jenkins splits work between a controller, which handles HTTP requests and manages the build environment, and agents, which run the builds. The scaling guide recommends dedicated agents so the controller stays lightweight. Agents can run on separate machines or in Kubernetes through plugins, so the number of agents and their placement becomes an operating decision your team owns.
Jenkins state lives in JENKINS_HOME
Configuration, plugins and secrets for a Jenkins controller all live in $JENKINS_HOME on that controller. Losing the controller without a backup of that directory means losing job configuration, credentials and installed plugins. Jenkins Configuration as Code can move settings into YAML files, but its documentation states that it does not install plugins, so plugin provisioning must be handled separately through Docker images or the Helm chart.
Primary and backup controllers
The Jenkins scaling guide describes a primary and backup controller arrangement, where a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails. Failover of this kind is an architecture you build and test yourself, including keeping $JENKINS_HOME in step between the two controllers. Each additional team or project can also get its own controller, which multiplies the backup and upgrade work.
Operational consequences for each
Argo CD's operating burden centers on the cluster, its RBAC and the Git repositories it reads, while Jenkins's burden centers on controller state, agent fleets and plugin upkeep. Jenkins LTS 2.580.1 stopped bundling several plugins, so administrators who depend on them must install them through the plugin manager. Ask your team which of these two sets of tasks it already runs well before choosing.
Drift detection, credentials, rollback and identity compared
This table compares how Argo CD and Jenkins handle drift, credentials, rollback and sign-in, using only the researched facts. Where the facts do not settle a point, the cell says what to confirm in your own environment before you decide.
| Capability | Argo CD | Jenkins |
|---|---|---|
| Drift detection model | Continuously reconciles live Kubernetes objects against the desired state in Git, so differences from Git are surfaced by the controller itself. | Runs pipelines when triggered and does not keep reconciling deployed state. Confirm which plugins, if any, your team uses to detect drift after a deploy. |
| Where deployment credentials sit | The controller runs inside the target cluster and applies changes from Git, so CI systems do not need cluster credentials for routine sync. | Pipelines usually hold deployment credentials in the controller or agents. Confirm how your Jenkins credentials store and agent isolation are configured. |
| Repository configuration | Since Argo CD 3.0, repositories are defined as Kubernetes Secrets rather than in the argocd-cm ConfigMap. | Pipelines are defined in a Jenkinsfile committed to source control, with settings held under $JENKINS_HOME on the controller, which the scaling guide says must be backed up. |
| Rollback | Rollback is a Git-driven operation in the GitOps model. Confirm the exact steps your team will use (revert commit or previous sync) and test them in a non-production cluster. | Rollback depends on the deployment steps written in each pipeline. Confirm how your pipelines redeploy a prior artifact and whether that is automated. |
| RBAC changes in 3.0 | From 3.0, update and delete RBAC apply only to the application itself, and viewing logs needs an explicit logs, get permission. Review existing policies before upgrading from 2.14. | Authorization is managed through Jenkins security settings and plugins. Confirm the role model your Jenkins version and plugins provide for your teams. |
| SSO options | Uses the bundled Dex (SAML, LDAP, GitHub connectors) or connects directly to an existing OIDC provider such as Okta, Keycloak or Microsoft. | Identity integration depends on installed plugins. Confirm the SSO plugin, supported providers and version compatibility for your identity provider. |
| Built-in admin account | Guidance is to use the built-in admin user only for initial setup and disable it with admin.enabled set to false once local users or SSO are configured. | Confirm how the initial admin account is secured and whether it is retired after your identity integration is in place. |
| Configuration as code | Declarative manifests and Git are the source of truth for the application state, managed through the Argo CD resources. | The Configuration as Code plugin reads YAML from CASC_JENKINS_CONFIG (default $JENKINS_HOME/jenkins.yaml), but it does not install plugins, so plugins need Docker images or the Helm chart. |
| Extension ecosystem | Covers GitOps delivery for Kubernetes clusters, with integrations focused on that model. Confirm any non-Kubernetes targets you need. | More than 2,300 community plugins connect Jenkins to tools across the CI/CD toolchain. Confirm each plugin you need is maintained for your Jenkins LTS line. |
Licensing and paid options for Argo CD and Jenkins
Argo CD is released under the Apache License 2.0 (SPDX identifier Apache-2.0), and the project itself offers no paid edition. Licensing therefore adds no fee for the controller, but running it still requires staff time, cluster capacity and the work of keeping versions current. The CNCF moved Argo from Incubating to Graduated on December 6, 2022, which reflects project maturity under CNCF governance.
- Release cadence: A minor release ships four times a year, roughly every three months, so plan an upgrade window at least that often.
- Patch window: Only the three most recent minor versions receive patch releases. On October 12, 2026 the project published v3.5.5, v3.4.11 and v3.3.16, with v3.6.0 in release candidate.
- Upgrade effort: The 2.14 to 3.0 upgrade notes changed RBAC behavior and moved repository definitions into Kubernetes Secrets. Older installations carry migration work, which is an effort cost even though no license is involved.
- Commercial support: The project does not sell support. Any contract comes from a third party, so confirm the covered versions, scope and response terms in writing.
Check which minor version you run today and whether it is still among the three receiving patches before you schedule the next change window.
Jenkins is distributed under the MIT License, as stated in the LICENSE.txt file in the jenkinsci/jenkins repository, which credits Kohsuke Kawaguchi, Sun Microsystems, Inc. and other contributors. There is no license fee for the controller or the build agents. The ongoing cost sits with the people who maintain the controller, its plugins and the Java runtime, along with any plugin dependencies your teams add over time.
- LTS cadence: Jenkins picks a new LTS baseline every 12 weeks from a recent weekly release, then ships three LTS releases for that baseline in four-week cycles that contain only backported fixes. The Jenkins LTS release line documents this schedule.
- Java support: Java 21 has a planned end of support in September 2027, and Java 25 (first LTS 2.541.1 in January 2026) has a planned end of support in September 2029. The final LTS release for Java 17 was 2.541.3 in March 2026, so plan any runtime move before the next baseline arrives.
- Bundled plugins: LTS 2.580.1, released September 30, 2026, stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins. Administrators who depend on them must install them through the plugin manager, so review this before upgrading.
- Plugin ecosystem: The Jenkins homepage describes more than 2,300 community-contributed plugins. Each is maintained separately, so budget review time for the ones your pipelines depend on.
- Paid options: The supplied project information does not describe a paid Jenkins edition. Confirm any vendor support terms directly with the provider.
Map your controller's Java version and plugin list against the LTS release notes before scheduling the next LTS move.
Both tools are open source under permissive licenses, so the difference in cost comes mainly from labor, infrastructure and any support contract. Recurring costs include staff time for upgrades, monitoring, backups and plugin or dependency reviews. One-time costs include the initial setup, identity integration, pipeline migration and the documentation that auditors may request. The main cost drivers are the number of clusters, the number of pipelines, the plugin count and the evidence your compliance program requires.
- Who is paid: Your team pays for staff time and infrastructure. A vendor or DeployOpen may be paid under a written scope for implementation, hardening, upgrades or ongoing support.
- Recurring work: Argo CD minor upgrades arrive roughly quarterly, and Jenkins LTS baselines arrive every 12 weeks, alongside Java and plugin updates.
- One-time work: Controller setup, SSO wiring, pipeline conversion and the runbooks that operations staff will use after handover.
- Quote inputs: Ask which versions are covered, what the upgrade windows are, who handles plugin and Java updates and what evidence the engagement delivers.
- Operating scope: Check whether a quote covers only the build or also the operation of the platform after go-live.
Before comparing quotes, place both tools' upgrade calendars in one planning document so the labor estimate reflects your actual schedule.
What drives the running cost of each
Running cost for either tool comes from the same few places: the machines it runs on, the people who keep it current, and the upgrades it forces on a schedule. The cards below separate what Argo CD and Jenkins each ask you to fund, which costs happen once and which recur, and what to request in a written quote so the two options can be compared on equal terms.
Cluster capacity for Argo CD
Argo CD runs as controllers inside a Kubernetes cluster, so its cost sits mostly in the cluster that hosts it. The project's high availability documentation says the HA manifests need at least three nodes because of pod anti-affinity rules, so a production install implies a minimum node count before any workload runs. Ask the quote to price the cluster nodes Argo CD needs for HA, the Redis HA layout, and any controller sharding you expect, and separate that from capacity already paid for by existing platform teams.
Build agent capacity in Jenkins
In Jenkins, the largest recurring line is usually build capacity. The Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. Costs rise with build concurrency, peak hours, and the number of teams that get their own controllers. Ask for the agent model you are pricing (static, on-demand Kubernetes pods, or cloud VMs), the expected concurrent job count, and who pays for idle agent time between peaks.
Plugin maintenance and Jenkins backups
Jenkins keeps its configuration, plugins and secrets in $JENKINS_HOME on the controller, so backup and restore are recurring operational tasks. Plugin upkeep is a recurring cost of its own. The LTS changelog for 2.580.1 notes that several plugins, including the SSH server and JUnit plugins, are no longer bundled and must be installed through the plugin manager. Ask the quote to include plugin inventory, compatibility testing after each baseline change, and how configuration as code is handled if you adopt it.
Upgrade cadence on both sides
Both tools recur upgrade work on a fixed rhythm. Jenkins picks a new LTS baseline every 12 weeks and ships three LTS releases for each baseline, while Argo CD ships a minor release four times a year and patches only the three most recent minors. Each cycle costs testing time on pipelines or clusters. Ask the quote to state which versions are covered, whether a support window is included, and how many upgrade cycles per year are assumed in the price.
Skills in Kubernetes and Git workflows
Argo CD assumes staff who can operate Kubernetes, read sync state, and manage Git as the source of truth for deployments. Jenkins assumes staff who can write and maintain Jenkinsfiles and manage controllers, agents and plugins. The skill cost is often the largest line in the total, and it is paid as salary, training or consulting time. Ask the quote to name which roles are covered, whether knowledge transfer and runbooks are included, and how the work is split between your team and the implementation partner.
Credentials and access management
Where credentials live drives both security work and recurring effort. Jenkins pipelines often hold deployment credentials inside CI, so rotation and access review fall on the CI team. Argo CD's SSO and RBAC model moves much of the access decision into the cluster and identity provider, but it still needs setup and periodic review. Ask the quote to show who rotates credentials, how access reviews are scheduled, and whether the admin account is disabled after SSO is configured.
Moving deployment from Jenkins jobs to Argo CD
This sequence moves Kubernetes deployment out of Jenkins push stages and into Git-driven reconciliation by Argo CD, while Jenkins keeps building artifacts. Each step ends with a check you can verify before the next one starts.
Inventory Jenkins deploy stages and credentials
The platform team lists every Jenkins job that deploys to a cluster, the stages that run
kubectl,helmor cloud CLI commands, and each credential those stages read from the Jenkins credentials store or from environment variables. For each job, record the target cluster, namespace, approval step and who can trigger it. The output is a written inventory with one row per deploy path and a column for the credential it uses. Done means every deploy path has an owner and a target, and no credential is left unlisted. Confirm the inventory with the security team before any change, because the credentials found here are the ones Argo CD will replace or stop needing.Move deployment manifests into Git
Engineers move the Kubernetes manifests, Helm values or Kustomize overlays that Jenkins currently renders at deploy time into a dedicated Git repository, separate from application source where your team decides that is appropriate. Image tags are written as explicit values that a build pipeline updates by committing a change, so the desired state of each environment is readable in version history. The output is a repository where the main branch describes what each cluster should run. Done means a reviewer can reconstruct any running version from Git alone, without reading Jenkins job configuration.
Define repositories as Kubernetes Secrets
Platform engineers register each Git repository and Helm or OCI source that Argo CD reads as a Kubernetes Secret, not as an entry in the
argocd-cmConfigMap, because Argo CD 3.0 removed repository configuration from that ConfigMap. Read-only deploy keys or tokens are scoped to the minimum repositories each Application needs. The output is a set of repository Secrets applied through your normal cluster change process. Done means Argo CD reports each repository as connected and a test Application syncs without a stored Jenkins credential.Set up RBAC and SSO before first sync
The identity team connects Argo CD to your existing OIDC or SAML provider, either directly or through the bundled Dex connectors, and maps groups to Argo CD roles and Projects. Deployers get permission to sync only the Applications for their team, and the built-in admin user is limited to initial setup and then disabled with
admin.enabledset to false. Note that from the 2.14 to 3.0 upgrade, update and delete permissions apply only to the Application itself, and log access needs an explicitlogs, getpermission. The output is a role matrix reviewed by the team that owns access. Done means a test user in each group can see exactly the Applications their role allows, and the admin login no longer works.Run Argo CD alongside Jenkins
For one low-risk service, the team lets Argo CD manage the Kubernetes objects while the existing Jenkins deploy stage stays in place but is disabled for that service, or is run against a non-production namespace first. Argo CD's drift detection and sync status are compared against what Jenkins deployed for several release cycles. Teams should decide in advance who may sync manually and how a conflicting Jenkins run is prevented, because two controllers writing the same resources cause churn. The output is a dated comparison record showing the same image tag reaching the same cluster by both paths. Done means the service has run through normal releases and rollbacks under Argo CD with no unexplained drift.
Rebuild approval gates and audit links
Approvals that Jenkins handled with input steps or manual gates are rebuilt as pull request reviews on the Git repository, or as Argo CD sync windows and manual sync permissions where that fits your change policy. Each deployment is linked to its commit, build number and approver so an auditor can trace a running version back to its source. The output is an approval and evidence procedure that your compliance lead has reviewed. Done means a sample release can be traced from the running pod to the Git commit, the build artifact and the approval record without querying Jenkins. Confirm with your auditor which evidence they expect, since this page does not set those requirements.
Retire Jenkins deploy stages
Once each service has passed its parallel run, the team removes the deploy stages from its Jenkinsfile and deletes the Jenkins credentials that only those stages used, after confirming nothing else references them. The Jenkins job keeps its build, test and image publishing stages, which transfer with little change because they are plugin-based build logic rather than deployment logic. Remaining Jenkins plugins that were only used for deployment are removed after checking the plugin list against the stages that remain. The output is a Jenkinsfile that ends at a published artifact and an updated credentials inventory. Done means no Jenkins job holds a cluster credential and every production deploy goes through Argo CD.
Running Jenkins for builds with Argo CD for Kubernetes delivery
The common split works like this: Jenkins builds, runs tests and publishes the image, then commits a change to a Git manifest repository, usually an image tag bump in a Kustomize overlay or Helm values file. Argo CD never receives a push from Jenkins. It watches the manifest repository and reconciles the cluster to whatever Git says. The boundary sits at the commit: everything before it is CI's responsibility, everything after it is the controller's. Decide early which repository holds the manifests, who may merge to it, and whether promotion between environments happens by a further commit or by a pull request.
The credentials split is the main reason teams adopt this pattern. CI still holds two write-capable credentials: push access to the container registry and write access to the manifest repository, typically a deploy key or token scoped to that one repository. What leaves CI is the cluster credential. Argo CD runs inside the cluster and applies manifests with its own service account, so a compromised Jenkins agent cannot run kubectl against production. Confirm this in your own setup: check that no kubeconfig is mounted into Jenkins jobs, that Argo CD's repository definitions are stored as Kubernetes Secrets as the 3.0 upgrade notes require, and that the Argo CD admin user is disabled once SSO is configured.
The split adds moving parts that a single pipeline does not have. You now operate two systems with separate upgrade cycles, two sets of logs to correlate, and a manifest repository that becomes a deployment interface. Argo CD's high availability manifests need at least three nodes, and a small team with one cluster and one pipeline may find a direct deploy step with tight approvals easier to audit. The pattern pays off when several clusters, several teams or strict separation of duties make the cluster credential the thing you most want to keep out of CI. Before committing, ask your platform team to estimate the run effort for both systems and to confirm how a failed sync and a rollback will be traced end to end.
Questions teams ask before choosing or hiring help
How much effort does migrating from Jenkins deploy jobs to Argo CD take?
The effort depends on how many deploy jobs exist, how much logic sits inside them, and how many environments and clusters they touch. Each Jenkins deploy stage usually has to be split into two parts: the build still produces an image or chart, and the desired state moves into a Git repository that Argo CD reads. Teams with simple kubectl apply or Helm steps can often map these quickly. Jobs with custom approvals, database steps, smoke tests or cross-system calls need those steps redesigned, because Argo CD syncs manifests and does not run arbitrary scripts. Ask any provider for an inventory of jobs, a list of secrets they use, and a written plan for cutover and rollback before agreeing scope.
Can our own platform team run Argo CD without outside help?
Yes, many teams run Argo CD in-house once they have a Kubernetes platform and a clear Git layout. Argo CD is Apache-2.0 licensed with no paid edition from the project itself, so the cost is staff time and infrastructure rather than a license fee. The project documents an HA installation that needs at least three nodes because of pod anti-affinity rules, and it ships patch releases only for the three most recent minor versions, so someone must plan upgrades every three months. If your team already operates Kubernetes and can own upgrades, RBAC and backups of the Git repositories, in-house operation is realistic. If not, a fixed-scope engagement can cover the initial build and handover.
What skills does a team need to run Argo CD well?
Three skill areas matter most. Kubernetes skills cover namespaces, RBAC, resource limits, ingress and how the application controller reconciles objects. Git skills cover repository structure, branch protection, pull request review and how to roll back by reverting a commit. Identity skills cover OIDC, SAML or LDAP connectors and the RBAC rules that map groups to projects. The 3.0 upgrade notes also changed some details that operators must know, such as repositories moving into Kubernetes Secrets and Dex RBAC using the federated_claims.user_id claim. Build a skills matrix for your team and identify the gaps before choosing between in-house work and outside help.
How long do HA setup and SSO integration take?
Duration depends on scope, not a fixed number. HA setup depends on the number of clusters, whether Redis HA is required, how many controller shards are planned, and whether the three-node minimum can be met on existing hardware. SSO integration depends on whether you connect directly to an existing OIDC provider such as Okta, Microsoft, Keycloak or Google Workspace, or use the bundled Dex with SAML, LDAP or GitHub connectors. Group mapping and RBAC rules add review time, and disabling the built-in admin account after SSO is working is a required step in the documented hardening path. Ask for a written plan that lists each cluster, identity source and acceptance test before agreeing a timeline.
Can Jenkins stay in place for builds after we adopt Argo CD?
Yes, and this is a common pattern. Jenkins continues to run builds, tests and image creation, then commits a new image tag or Helm values change to a Git repository, and Argo CD applies that change to the cluster. Jenkins does not need cluster credentials for deployment in this model, which reduces the number of places where production access is held. Jenkins still needs to run on dedicated build agents, and its configuration, plugins and secrets live in $JENKINS_HOME on the controller, so backups remain your responsibility. Keep Jenkins for builds if your pipelines are mature, and move only the deployment stage to Git-driven delivery.
Does a fixed-scope engagement with DeployOpen cover Argo CD and Jenkins work?
A fixed-scope engagement covers the deliverables, scope and timeline agreed in writing before work starts. For this topic, that can include planning the migration from Jenkins deploy jobs, designing the Git repository layout, installing and hardening Argo CD inside your own infrastructure, integrating SSO, documenting runbooks and handing over to your team. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. Ongoing upgrades and support are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the list of deliverables and acceptance criteria in the proposal.
What does Argo CD cost compared with keeping Jenkins deploy jobs?
Argo CD has no paid edition from the project itself, and Jenkins is distributed under the MIT License, so neither product carries a license fee for the open-source build. The cost difference comes from staff time, infrastructure and the work to restructure pipelines. Argo CD adds Kubernetes control plane load and a Git repository to maintain, while Jenkins adds controller and agent capacity and plugin upkeep. Recurring costs include upgrades, patching, backups and on-call coverage for both tools. Ask any provider to separate one-time migration work from recurring operations, and to state which upgrades and support are included in a retainer.
Where Argo CD and Jenkins projects usually run long
Argo CD projects tend to slow down when repository layout and access decisions are made after the first applications are live. Settle the repository structure early, and plan for the 3.0 change that removed repository configuration from the argocd-cm ConfigMap, so repositories must be defined as Kubernetes Secrets. Map RBAC and SSO before go-live: Dex-based RBAC keys on the federated_claims.user_id claim, update and delete rules apply only to the application itself, and reading logs needs an explicit logs, get permission. Once SSO works, set admin.enabled to false. For high availability, the manifests need at least three nodes because of pod anti-affinity, and IPv6-only clusters are not supported, so confirm node count before sizing. Redis is a disposable cache, so recovery planning should focus on the Kubernetes objects. Decide on application controller sharding by measuring how many applications and clusters each shard will carry.
Jenkins projects usually run long on the controller. All configuration, plugins and secrets live in $JENKINS_HOME on the controller, so size it for the work you intend to keep there, and move builds to dedicated agents so the controller handles HTTP requests and manages the build environment. Inventory plugins before the next LTS upgrade. The 2.580.1 LTS stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins, so any pipeline that depends on them breaks unless they are installed through the plugin manager. Jenkinsfiles often call plugin steps directly, which makes each plugin part of the build contract. Check your Java version against the support policy too, since Java 21 has a planned end of support in September 2027.
Across both tools, projects slip where deployment logic lives outside version control. An undocumented deploy script run from a Jenkins job, or a manual cluster change, can bypass the Git state Argo CD reconciles, so inventory every script and decide which ones become manifests. Before committing to a design, ask your team to confirm which repositories and clusters each group may touch, how SSO groups map to Argo CD roles, whether the Jenkins plugin list is captured as code, and how that list will be installed, since the Configuration as Code plugin does not install plugins itself. Request a written inventory of both tools as the first deliverable in any scoped engagement.
How DeployOpen helps teams choose and implement
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a team weighing Argo CD against Jenkins, that means we can help you settle the delivery model before any pipeline is written: which systems hold deployment credentials, where the desired state lives, and who is allowed to change production. We work with either platform, or with both in the pattern where Jenkins builds artifacts and Argo CD applies them to Kubernetes. We do not favor one tool, and a recommendation from us should follow from your clusters, your change-control rules and your team's skills.
Engagements are fixed-scope. Before work starts, we agree the scope, deliverables and timelines in writing, and any quote follows from that written scope rather than from a published price list, because DeployOpen does not publish one. Useful items to put in the scope for this decision include the cluster count and layout, the SSO provider and RBAC mapping, where repository credentials will be stored, the Jenkins plugin set and agent design, the rollback runbook, and the documentation and handover your operations team will need. Ask any prospective partner, including us, to show how each of these items is priced and what is one-time versus recurring. Ongoing support, upgrades and continuous testing are available as a retainer, which is often the practical choice when Argo CD and Jenkins both need version tracking after go-live. Confirm current release and support windows directly with each project before you commit to a schedule.
