ArgoCD Explained: GitOps Continuous Delivery for Kubernetes

Managing Kubernetes deployments can quickly become complex, with configurations spiraling out of control across multiple environments. This challenge led to the rise of GitOps, a paradigm shift that places Git at the heart of your continuous delivery strategy. ArgoCD emerges as a leading open-source tool in this space, bringing declarative, Git-driven automation to Kubernetes applications.

This article will demystify ArgoCD, explaining its core principles, how it streamlines Kubernetes deployments, and its role in the broader DevOps ecosystem. We’ll then explore how Kestra, a unified orchestration platform, can extend ArgoCD’s capabilities, allowing you to build robust, end-to-end automation workflows that span your entire infrastructure, data, and AI operations.

Mastering Kubernetes Deployments with GitOps

The operational complexity of Kubernetes demands a structured and automated approach to application deployment. Traditional methods involving manual kubectl commands or imperative scripts are prone to error, difficult to audit, and scale poorly. GitOps provides a robust framework to solve these problems.

The Core Principles of GitOps and Declarative Configuration

GitOps is an operational model for cloud-native applications that uses Git as the single source of truth for both infrastructure and application configuration. Its core principles are:

1. Declarative: The entire desired state of the system is described declaratively in a Git repository.
2. Versioned and Immutable: The desired state is version-controlled in Git, providing a complete audit trail and easy rollbacks.
3. Pulled Automatically: Agents automatically pull the desired state from Git and apply it to the system.
4. Continuously Reconciled: Software agents continuously observe the actual system state and reconcile it with the desired state in Git.

This approach transforms operations into a version-controlled, auditable, and collaborative process, aligning it with modern software development practices.

How ArgoCD Automates Application State Synchronization

ArgoCD is a CNCF-graduated project that embodies these GitOps principles. It operates as a controller within your Kubernetes cluster, continuously monitoring two key things:

• The desired state: Defined in your Git repository as Kubernetes manifests, Helm charts, or Kustomize configurations.
• The actual state: The live applications running in your cluster.

When ArgoCD detects a discrepancy—or “drift”—between the desired state in Git and the actual state in the cluster, it takes action. It automatically synchronizes the cluster to match the state defined in Git. This continuous reconciliation loop ensures that your applications are always running the intended version, providing a self-healing mechanism for your deployments.

Why ArgoCD is a Continuous Delivery Tool, Not Just CI/CD

The terms Continuous Integration (CI) and Continuous Delivery (CD) are often used together, but they represent distinct stages.

• Continuous Integration (CI) focuses on the build and test phase. Developers frequently merge code changes into a central repository, after which automated builds and tests are run. The output is typically a container image or other artifact.
• Continuous Delivery (CD) focuses on releasing those artifacts to production.

ArgoCD is a pure CD tool. It doesn’t build code or run tests. Its sole responsibility is to ensure that the version of an application specified in Git is deployed and running correctly on Kubernetes. This specialization allows it to excel at declarative, pull-based deployments, which is a significant departure from older, push-based models.

ArgoCD in the Modern DevOps Landscape: Comparisons and Synergy

ArgoCD’s focused approach places it in a specific niche within the broader DevOps toolchain. Understanding its relationship with other tools is key to leveraging its full potential.

ArgoCD vs. Jenkins: Shifting from Scripted Pipelines to Declarative Sync

Jenkins is a versatile automation server that has long been a staple of CI/CD. However, its traditional approach differs fundamentally from ArgoCD’s:

• Model: Jenkins typically uses a push model. A pipeline script checks out code, builds an image, and then executes commands (e.g., kubectl apply) to push the changes to a Kubernetes cluster.
• Definition: Pipelines are often defined imperatively in a Jenkinsfile, specifying a sequence of steps to execute.
• Source of Truth: The state of the deployment is determined by the last successful pipeline run, not by a declarative manifest in Git.

ArgoCD, in contrast, uses a pull model. It doesn’t require an external system to push changes. Instead, it pulls the desired state from Git. This declarative approach provides a more transparent and reliable deployment mechanism, as the Git repository always reflects the intended state of the cluster.

Many teams use both tools together. Jenkins handles the CI part—building and testing code, publishing container images. Once an image is ready, a commit is made to a configuration repository, updating the image tag. ArgoCD then detects this change and handles the CD part, pulling the new configuration and deploying it to Kubernetes. This combination leverages the strengths of both, separating build concerns from deployment concerns. You can find more information about different CI/CD tools in our article about Tekton alternatives.

ArgoCD and Kubernetes: A Symbiotic Relationship

ArgoCD is not an alternative to Kubernetes; it’s a tool that runs on and manages applications within Kubernetes. It is Kubernetes-native by design:

• It runs as a controller inside the cluster.
• It uses Custom Resource Definitions (CRDs) like Application and AppProject to manage deployments.
• It interacts directly with the Kubernetes API to observe and modify the cluster state.

Kubernetes provides the platform for running containerized applications, while ArgoCD provides the automated, GitOps-driven mechanism for deploying and managing them. This symbiotic relationship simplifies the complex task of application lifecycle management on Kubernetes.

Key Advantages of Adopting ArgoCD for Your Deployments

Integrating ArgoCD into your Kubernetes workflow provides several significant benefits that address common operational challenges.

Enhanced Operational Efficiency and Reliability

By automating the deployment process, ArgoCD eliminates the need for manual interventions, which are a common source of errors. The continuous reconciliation loop acts as a self-healing mechanism; if a configuration is manually changed in the cluster, ArgoCD will detect the drift and automatically revert it to the state defined in Git. This ensures consistency across environments and significantly improves the reliability of your deployments.

Improved Security and Auditability with Git as the Source of Truth

With Git as the single source of truth, every change to your application’s configuration is recorded in the commit history. This provides a clear, auditable trail of who changed what, when, and why. Access controls can be managed through standard Git provider permissions (e.g., GitHub, GitLab), limiting direct access to the Kubernetes cluster. This model aligns with the principles of Everything as Code, enhancing security and compliance.

Streamlined Rollbacks and Disaster Recovery

Because every deployment state is a commit in Git, rolling back to a previous version is as simple as reverting a commit (git revert). ArgoCD will detect the change in the repository and automatically synchronize the cluster to the previous stable state. This same principle applies to disaster recovery. In the event of a cluster failure, a new cluster can be brought online, and ArgoCD can be pointed to the Git repository to redeploy all applications and restore the last known good state automatically.

Practical ArgoCD: Core Concepts and Configuration Examples

To use ArgoCD effectively, you need to understand its core resources: Applications and Projects.

Understanding ArgoCD Applications and Projects

• Application: An Application is a Kubernetes CRD that defines a deployable unit. It specifies the source of the configuration (the Git repository and path) and the destination (the Kubernetes cluster and namespace).
• AppProject: An AppProject is another CRD used to group applications. It provides a way to enforce restrictions on what applications can do, such as which repositories they can deploy from and which clusters or namespaces they can deploy to. Projects are the foundation for multi-tenancy and role-based access control (RBAC) in ArgoCD.

You can find more detailed instructions on how to deploy Kestra with ArgoCD in our documentation.

Declarative Workflow Example: Deploying a Simple Application

Here is a basic example of an ArgoCD Application manifest. This YAML file would be applied to the Kubernetes cluster where ArgoCD is running.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

This manifest tells ArgoCD to:

• Create an application named guestbook.
• Monitor the guestbook directory in the argocd-example-apps Git repository.
• Deploy the manifests found in that directory to the guestbook namespace in the local Kubernetes cluster.
• Keep the deployment synchronized automatically, pruning old resources and self-healing from drift.

Orchestrating ArgoCD with Kestra for End-to-End Automation

ArgoCD is excellent at continuous delivery for Kubernetes, but application deployment is often just one step in a much larger workflow. This is where a universal orchestration platform like Kestra becomes essential.

Beyond Deployment: Integrating ArgoCD into Broader Workflows

Real-world processes involve more than just syncing a Git repo. You might need to:

• Provision infrastructure with Terraform before deployment.
• Run Ansible playbooks to configure dependencies.
• Require manual approval for production releases.
• Update a ServiceNow ticket after a successful deployment.
• Run post-deployment validation checks.

ArgoCD alone cannot manage these cross-domain tasks. Kestra provides the orchestration control plane to connect all these steps into a single, cohesive workflow.

Event-Driven ArgoCD Syncs and Approval Gates with Kestra

With Kestra’s ArgoCD plugin, you can build sophisticated, event-driven workflows. For example, a webhook from your CI system can trigger a Kestra flow that first waits for a manager’s approval via Slack, then initiates an ArgoCD sync, and finally monitors the application’s health status before sending a completion notification.

This blueprint for managing an Argo CD Application shows how to apply a manifest, check status, trigger a sync, and verify the outcome.

Here is a Kestra flow that triggers an ArgoCD sync and waits for it to complete:

id: trigger-argocd-sync
namespace: company.team.devops

tasks:
  - id: sync-app
    type: io.kestra.plugin.argocd.apps.Sync
    url: "https://argocd.yourcompany.com"
    token: "{{ secrets.ARGOCD_TOKEN }}"
    appName: "my-production-app"
    wait: true
    timeout: "PT10M"

  - id: check-status
    type: io.kestra.plugin.argocd.apps.Status
    url: "https://argocd.yourcompany.com"
    token: "{{ secrets.ARGOCD_TOKEN }}"
    appName: "my-production-app"

Chaining ArgoCD with Infrastructure Provisioning and Configuration

Kestra’s power lies in its ability to orchestrate your entire stack. You can create a single workflow that chains multiple tools together. A common pattern is to provision infrastructure using the Terraform integration, configure it with Ansible, and then deploy the application with ArgoCD. The Terraform-Ansible-ArgoCD blueprint provides a ready-to-use example of this pattern. This unified approach provides end-to-end visibility and control over your entire delivery pipeline.

Real-World Impact: Unifying Ops with Kestra and ArgoCD

Leading organizations use Kestra to orchestrate complex infrastructure and operations at scale. For example, Crédit Agricole’s IT production arm (CAGIP) transformed its operations by scaling workflows across more than 100 clusters. Germany’s public-sector IT provider, Dataport, built a government-grade orchestration control plane for its private cloud. Similarly, a Fortune 500 industrial company replaced its legacy automation tools with Kestra to secure hybrid cloud automation across both IT and OT environments. These examples highlight the need for a unified platform that can orchestrate tools like ArgoCD as part of a broader, more integrated automation strategy, a core strength of Kestra’s API-first design.

The Future of GitOps and Unified Orchestration

ArgoCD has established itself as a standard for GitOps on Kubernetes. It solves the critical problem of continuous delivery in a declarative, reliable, and auditable way. However, as organizations mature, the need for orchestration extends beyond a single Kubernetes cluster.

The future lies in applying the same declarative principles to the entire IT landscape. A unified platform like Kestra provides a consistent, YAML-based control plane to orchestrate workflows across diverse domains—from infrastructure automation to data pipelines and AI systems. By integrating specialized tools like ArgoCD into this broader framework, you can achieve true end-to-end automation, breaking down silos and enabling your teams to operate with greater speed, reliability, and control.

Explore more infrastructure automation resources to see how declarative orchestration can transform your operations.