Jenkins and Argo CD with Kubernetes: CI/CD and GitOps Best Practices in 2026

Continuous Integration (CI) and Continuous Delivery or Deployment (CD) remain essential practices in modern software engineering. They help teams deliver software faster and more reliably by automating builds, tests, security checks, packaging, and deployment processes.

However, cloud-native delivery practices have evolved significantly. In 2026, organizations increasingly separate CI from CD rather than expecting one tool to manage the entire software delivery lifecycle.

CI systems such as Jenkins typically build and test software and produce immutable artifacts such as packages or container images. Kubernetes-native GitOps tools such as Argo CD then continuously reconcile the desired deployment state stored in Git with the actual state of Kubernetes clusters.

At Retesys, we have extensive experience with cloud migration, Kubernetes, software development, and DevOps solutions. In this article, we compare Jenkins and Argo CD from a practical perspective and explain how to decide where each tool fits into a modern CI/CD architecture.

An important point should be made from the start:

Jenkins and Argo CD are not necessarily competing tools.

Jenkins is primarily a general-purpose automation and CI platform. Argo CD is primarily a Kubernetes-native GitOps continuous delivery platform. For many organizations, using Jenkins for CI and Argo CD for Kubernetes CD is more effective than trying to select only one of them.

What is your current level of Kubernetes adoption?

• If Kubernetes is your primary application platform:

  Argo CD is a natural choice for continuous delivery.

  Argo CD is a Kubernetes-native GitOps controller that continuously compares the desired application state stored in Git with the actual resources running in Kubernetes. Depending on your configuration, it can detect drift, synchronize changes automatically, prune resources that should no longer exist, and restore resources that have been modified manually.

  Modern Argo CD 3.x installations can manage many applications and multiple Kubernetes clusters. ApplicationSet also makes it possible to generate Argo CD Applications from templates, which is particularly useful for multi-cluster, multi-tenant, or large microservice environments.

  This creates an important operational difference compared with traditional CI-driven deployment:

  Git becomes the source of truth for deployment state instead of the CI server.

• If you have both Kubernetes and traditional infrastructure:

  Jenkins remains useful because it is not limited to Kubernetes.

  Jenkins pipelines can build applications for virtual machines, physical servers, Kubernetes, Windows environments, mobile platforms, embedded systems, and many other targets.

  Jenkins itself can also run on Kubernetes. Using the Jenkins Kubernetes plugin, organizations can provision ephemeral build agents as Kubernetes pods, creating build environments only when they are required and removing them after the pipeline completes.

  This makes Jenkins suitable for organizations transitioning gradually from traditional infrastructure to containerized and Kubernetes-based environments.

Are you selecting a CI tool or a CD tool?

This is often a more useful question than asking whether Jenkins or Argo CD is "better."

• If your main requirement is building, testing, scanning, and packaging applications:

  Jenkins is the stronger fit.

  Jenkins supports Pipeline as Code through Jenkinsfile, allowing build logic to be stored and reviewed together with application source code. Pipelines can orchestrate compilation, automated testing, static analysis, vulnerability scanning, container builds, artifact publishing, and many other engineering tasks.

  Jenkins' large plugin ecosystem and ability to execute arbitrary build tools make it particularly useful for complex or heterogeneous CI environments.

• If your main requirement is deploying applications to Kubernetes:

  Argo CD is usually the stronger fit.

  Instead of giving the CI system administrative access to the Kubernetes API and running commands such as kubectl apply, GitOps separates the CI and deployment responsibilities.

  A typical workflow is:

  1. Jenkins builds and tests the application.
  2. Jenkins publishes an immutable container image or other artifact.
  3. The desired application version is updated in a GitOps repository.
  4. Argo CD detects that Git change.
  5. Argo CD reconciles the Kubernetes cluster with the desired state.

This pull-based model provides a clearer deployment history and reduces the need to expose Kubernetes credentials to CI jobs.

What kinds of applications does your organization build?

The distinction between Jenkins and Argo CD should not be based simply on "desktop versus backend" applications.

A more useful distinction is whether the workload needs general-purpose CI automation or Kubernetes-native deployment reconciliation.

• For mobile, desktop, legacy, embedded, or heterogeneous applications:

  Jenkins can be a good choice because its agents can run on different operating systems and infrastructure types.

  For example, one Jenkins installation can orchestrate Linux builds, Windows builds, container builds, and dedicated macOS agents when required.

  However, Jenkins is no longer the only option in this area. Teams already standardized on platforms such as GitHub, GitLab, or Azure DevOps may find their integrated CI services simpler for some projects.

• For applications deployed to Kubernetes:

  Argo CD provides significant benefits regardless of whether the application is a monolith, microservice, API, or web application.

  Kubernetes manifests, Helm charts, or Kustomize configurations can be stored in Git and reconciled by Argo CD.

  For a Kubernetes-focused organization, the architecture therefore often becomes:

The CI system produces artifacts. Git records the desired deployment state. Argo CD performs the deployment.

How complex are your deployment needs?

• For multi-cluster or multi-cloud Kubernetes environments:

  Argo CD is particularly well suited.

  Applications can be deployed consistently across many Kubernetes clusters while maintaining the desired configuration in Git. ApplicationSets can generate deployments dynamically for multiple clusters or environments.

  This approach also reduces configuration drift: when somebody changes a managed Kubernetes resource manually, Argo CD can identify the difference between Git and the live cluster.

• For a single Kubernetes cluster:

  GitOps can still be valuable.

  Multi-cluster scale should not be the only reason to adopt Argo CD. Even a single production Kubernetes cluster benefits from declarative deployment configuration, drift detection, auditable Git history, and separation between CI and deployment permissions.

• For non-Kubernetes deployment targets:

  Jenkins remains more flexible.

  Jenkins pipelines can invoke deployment tooling for VMs, cloud services, legacy application servers, databases, or other environments where Argo CD is not applicable.

What is your team's experience with Kubernetes and GitOps?

• If your team is comfortable with Kubernetes and declarative configuration:

  Argo CD fits naturally into the workflow.

  Teams should understand Kubernetes resources, Git workflows, Helm or Kustomize where applicable, and the implications of automated reconciliation.

  GitOps also changes operational habits. Instead of modifying production resources manually, engineers normally change the desired configuration in Git and allow the GitOps controller to reconcile the environment.

• If your organization has extensive Jenkins experience:

  You do not need to replace Jenkins simply because you are adopting Kubernetes.

  Jenkins can continue providing CI while Argo CD takes responsibility for Kubernetes delivery.

  This incremental architecture is often less disruptive than attempting to migrate CI and CD simultaneously.

Pipeline definitions should preferably be stored in source control using Declarative Pipeline and reusable scripts or Jenkins Shared Libraries rather than embedding large amounts of business logic directly into manually configured Jenkins jobs.

For Jenkins administration, Configuration as Code (JCasC) can also be used to manage Jenkins configuration declaratively.

What are your security and compliance requirements?

Security should influence the architecture of the entire software supply chain rather than just the choice between Jenkins and Argo CD.

• Argo CD security

  Argo CD supports role-based access control and integration with enterprise identity providers through SSO mechanisms such as OIDC and SAML.

  GitOps also creates a useful audit trail because changes to deployment configuration can pass through normal Git workflows, including pull requests, approvals, branch protection, and code review.

  Organizations should still apply least-privilege access to Argo CD itself and to the Kubernetes service accounts used to manage destination clusters.

• Jenkins security

  Jenkins provides extensive authentication, authorization, credential, and security integrations. However, its flexibility and large plugin ecosystem also mean that Jenkins installations require disciplined maintenance.

  Jenkins controllers and plugins should be kept up to date, unused plugins should be removed, and permissions should follow the principle of least privilege.

  Build jobs should use isolated agents whenever possible instead of executing builds directly on the Jenkins controller.

How should secrets be managed?

Secrets should not be stored directly in application repositories, Jenkinsfiles, Kubernetes manifests, or GitOps repositories as plain text.

At Retesys, we recommend integrating CI/CD systems with dedicated secrets-management platforms such as:

• Azure Key Vault
• AWS Secrets Manager
• HashiCorp Vault
• other organization-approved secret stores

Jenkins pipelines can retrieve credentials only when required for a particular pipeline step.

For Kubernetes environments managed with Argo CD, solutions such as External Secrets Operator, Sealed Secrets, or similar approaches can reference or safely manage secret material without placing clear-text credentials into Git.

Argo CD should deploy the references or encrypted resources — Git should not become a plain-text secrets database simply because GitOps is being used.

Whenever the cloud platform supports it, prefer workload identity or other short-lived authentication mechanisms over long-lived static cloud credentials.

Learn more in our guide to Kubernetes Security Best Practices.

How should security policies be enforced?

Modern CI/CD pipelines should include security controls before deployment, while Kubernetes should enforce critical policies again at admission time.

Typical CI checks include:

• unit and integration tests;
• static application security testing;
• dependency and container vulnerability scanning;
• Kubernetes manifest validation;
• Infrastructure as Code validation;
• policy checks.

Policy-as-Code tools such as Open Policy Agent (OPA), Gatekeeper, and Kyverno can enforce organizational requirements for Kubernetes workloads.

Examples include requiring resource limits, prohibiting privileged containers, restricting allowed registries, or enforcing security-related labels and configuration.

This creates defense in depth:

CI detects problems early, while Kubernetes admission policies prevent non-compliant workloads from entering the cluster.

What is your approach to Infrastructure as Code?

GitOps and Infrastructure as Code are related, but they should not be treated as identical concepts.

Argo CD is particularly effective for declaratively managing Kubernetes resources stored in Git, including raw manifests, Helm-based applications, and Kustomize configurations.

Tools such as Terraform, OpenTofu, and Ansible address a broader infrastructure scope, including cloud networks, managed databases, virtual machines, DNS, IAM, and other resources outside Kubernetes.

Jenkins can orchestrate Terraform or Ansible workflows as part of a pipeline. Dedicated infrastructure automation platforms can also be used.

A common architecture therefore separates concerns:

Regardless of the tool, infrastructure changes should be reviewed, version controlled, and validated by automated policy checks.

How should environments be promoted?

Environment promotion is one of the most important design decisions in a GitOps architecture.

A useful principle is:

Build once, promote the same artifact.

CI should produce an immutable artifact — for example, a container image — once. The same artifact should then move through development, staging, and production rather than being rebuilt for each environment.

Environment-specific Git configuration can reference the approved image version or digest.

For example:

Promotion can be performed through pull requests, automation, or dedicated GitOps promotion tooling.

This keeps deployment changes reviewable and prevents CI jobs from bypassing the GitOps process by directly modifying production clusters.

For organizations with many applications and environments, dedicated promotion tools can automate more of this process while retaining Git-based auditability.

Do you need canary or blue-green deployments?

Argo CD reconciles Kubernetes resources, but advanced rollout strategies are a separate concern.

For progressive delivery, Argo Rollouts can be used alongside Argo CD.

Argo Rollouts extends Kubernetes with deployment strategies such as:

• canary releases;
• blue-green deployments;
• controlled pauses;
• gradual traffic shifting;
• automated analysis of rollout health.

Argo CD deploys and reconciles the Rollout resource, while Argo Rollouts manages the actual progressive release.

For higher-risk production systems, progressive delivery can reduce the impact of a defective release compared with replacing all application replicas at once.

What does an Argo CD application look like?

A simplified Argo CD Application can look like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default

  source:
    repoURL: https://github.com/myorg/gitops.git
    targetRevision: main
    path: environments/production/my-app

  destination:
    server: https://kubernetes.default.svc
    namespace: production

  syncPolicy:
    automated:
      prune: true
      selfHeal: true

With automated synchronization enabled, Argo CD continuously compares the target Git configuration with the Kubernetes cluster.

selfHeal allows Argo CD to reconcile certain manual changes back toward the desired state, while prune allows resources removed from Git to also be removed from the target environment.

Whether those options should be enabled automatically in every environment depends on the organization's risk controls and approval process.

What does a modern Jenkins pipeline look like?

Modern Jenkins installations should use Pipeline as Code rather than relying primarily on manually configured jobs.

For example:

pipeline {
    agent { label 'kubernetes' }

    stages {
        stage('Build') {
            steps {
                sh './ci/build.sh'
            }
        }

        stage('Test') {
            steps {
                sh './ci/test.sh'
            }
        }

        stage('Security checks') {
            steps {
                sh './ci/security-checks.sh'
            }
        }

        stage('Publish artifact') {
            steps {
                sh './ci/publish.sh'
            }
        }
    }
}

The Jenkinsfile defines the pipeline structure, while reusable build and deployment logic remains in version-controlled scripts.

When Jenkins runs with Kubernetes-based agents, those build environments can be provisioned on demand and removed after execution.

This provides better isolation and more efficient infrastructure utilization than maintaining large numbers of permanently running build workers.

What is your organization's preference for operational complexity?

Neither Jenkins nor Argo CD is maintenance-free.

• Jenkins

  Jenkins offers exceptional flexibility, but organizations must maintain the controller, plugins, agents, credentials, integrations, and pipeline libraries.

  Configuration as Code can significantly improve reproducibility, and ephemeral agents reduce the amount of permanently running build infrastructure.

  Organizations should nevertheless budget time for Jenkins and plugin upgrades, security advisories, testing, backups, and capacity planning.

• Argo CD

  Argo CD generally has a smaller functional scope: it continuously reconciles Kubernetes applications.

  That narrower responsibility can reduce day-to-day delivery complexity, but production installations still require upgrades, backup and recovery planning, SSO/RBAC configuration, repository access management, observability, and scaling.

  Argo CD also has an active release lifecycle, so teams should maintain supported versions instead of allowing installations to remain unchanged indefinitely.

What is your budget for CI/CD?

Both Jenkins and Argo CD are open-source, so licensing cost alone is not a useful comparison.

Instead, calculate total cost of ownership.

For Jenkins, consider:

• controller infrastructure;
• build agents;
• Kubernetes or VM compute used by builds;
• artifact storage;
• plugin and platform maintenance;
• engineering time spent maintaining pipelines.

For Argo CD, consider:

• Kubernetes resources;
• operational management;
• repository and cluster scale;
• high-availability requirements;
• observability;
• engineering effort required to maintain GitOps repositories.

Jenkins running on Kubernetes can reduce infrastructure costs by starting ephemeral agents only when workloads require them.

Similarly, Argo CD does not perform expensive application compilation or testing: its primary responsibility is reconciliation, so its resource profile is fundamentally different from a CI platform.

The correct cost comparison is therefore not simply "Jenkins versus Argo CD." In many environments you will still need both a CI platform and a delivery platform.

How should CI/CD be monitored?

Pipeline automation should be observable just like production applications.

Jenkins and Argo CD can expose metrics that can be integrated with monitoring platforms such as Prometheus and Grafana.

Useful indicators include:

• pipeline success and failure rates;
• build duration;
• deployment frequency;
• deployment lead time;
• Argo CD synchronization status;
• application health;
• failed or degraded deployments;
• time required to recover from failed releases.

Organizations should also consider engineering delivery metrics such as DORA metrics to identify bottlenecks and measure whether automation is actually improving software delivery.

The objective is not simply to deploy more frequently. It is to deploy quickly, predictably, and safely.

Jenkins vs. Argo CD in 2026

Recommended Jenkins and Argo CD architecture

For organizations running Kubernetes, a strong 2026 architecture is:

In this architecture:

1. Developers commit source code.
2. Jenkins performs CI.
3. Tests and security controls must pass.
4. Jenkins publishes an immutable artifact.
5. The desired artifact version is recorded in Git.
6. Argo CD detects the Git change.
7. Argo CD reconciles Kubernetes.
8. Kubernetes policy controls provide an additional enforcement layer.
9. Monitoring verifies application and deployment health.

The major benefit is clear separation of responsibilities:

CI creates software. Git records desired deployment state. Argo CD reconciles Kubernetes.

Conclusion and Recommendations

Jenkins and Argo CD remain important tools in 2026, but comparing them as direct replacements can lead to the wrong architectural decision.

Jenkins is strongest as a flexible CI and automation platform.

It is particularly valuable for heterogeneous application portfolios, complex build pipelines, existing Jenkins environments, and organizations that require extensive integration with build and testing tools. When Kubernetes is available, Jenkins can use ephemeral Kubernetes agents to improve build isolation and scalability.

Argo CD is strongest as a Kubernetes-native GitOps continuous delivery platform.

It provides declarative deployment management, automated reconciliation, drift detection, multi-cluster support, and scalable application management through features such as ApplicationSet.

For Kubernetes environments, we recommend separating CI from CD rather than allowing the CI server to become the long-term source of deployment state.

A practical architecture is:

Jenkins → artifact registry → GitOps repository → Argo CD → Kubernetes

The same architecture can also use another CI platform — such as GitHub Actions, GitLab CI, Azure DevOps, Tekton, or Argo Workflows — depending on the organization's technology stack.

Our CI/CD recommendations for 2026

1. Keep pipelines and configuration in source control.

Use Jenkinsfiles, reusable scripts, Configuration as Code, and declarative Kubernetes configuration rather than relying on manually configured pipelines.

2. Build artifacts once and promote them.

Do not rebuild an application separately for development, staging, and production. Promote the same immutable artifact through environments.

3. Prefer GitOps for Kubernetes deployment state.

Use Git as the source of truth and allow Argo CD to reconcile Kubernetes instead of giving every CI job direct production-cluster access.

4. Use ephemeral CI agents where practical.

Kubernetes-based Jenkins agents improve isolation and allow build capacity to scale with demand.

5. Keep secrets outside source repositories.

Integrate Jenkins and Kubernetes with dedicated secrets-management systems and prefer short-lived credentials or workload identity where possible.

6. Add security and policy checks to the delivery process.

Combine vulnerability scanning and validation in CI with admission-time policy enforcement using tools such as OPA/Gatekeeper or Kyverno.

7. Use controlled environment promotion.

Represent changes to production deployment state through Git, preferably with reviews and approvals appropriate to the risk of the application.

8. Use progressive delivery for higher-risk applications.

Combine Argo CD with Argo Rollouts or equivalent tooling when canary or blue-green deployment strategies are required.

9. Monitor delivery performance.

Collect CI and CD metrics, deployment health information, and DORA-style engineering metrics so that pipeline reliability can be continuously improved.

10. Keep both Jenkins and Argo CD current.

CI/CD systems are part of the software supply chain and should receive the same security and lifecycle attention as production applications.

For organizations maintaining a combination of traditional infrastructure and Kubernetes applications, Jenkins and Argo CD therefore complement each other particularly well. Jenkins can provide consistent CI across the organization, while Argo CD provides a controlled GitOps delivery model for Kubernetes.

For additional cloud-native deployment guidance, see our article on 12-Factor Apps and Kubernetes.