Argo CD is a declarative continuous-delivery tool for Kubernetes built on the GitOps model. A Git repository holds the desired state of your cluster - the manifests, Helm charts, or Kustomize overlays that define what should run - and Argo CD runs inside the cluster continuously comparing that declared state against what's actually deployed, reconciling any difference. Instead of a pipeline pushing changes in, the cluster pulls its own configuration from Git.

GitOps: Git as the source of truth

The principle is that the repository, not a person or an ad-hoc kubectl apply, is the authoritative record of what runs. A deployment is a Git commit; a rollback is reverting to an earlier commit. This gives a full audit trail, makes environments reproducible, and means recovering a cluster is a matter of pointing Argo CD at the repo. It contrasts with push-based pipelines like GitLab CI/CD that run kubectl from outside.

Applications, sync, and drift

Argo CD models each deployable unit as an Application resource pointing at a repo path and a target cluster/namespace. It continuously detects drift - any divergence between Git and the live cluster - and can sync automatically or wait for manual approval. If someone changes a resource directly in the cluster, Argo CD flags it as out of sync and can revert it to match Git.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    repoURL: https://github.com/org/infra
    path: apps/etl
  destination:
    namespace: data
  syncPolicy:
    automated:
      selfHeal: true

Where it fits

Argo CD is the standard choice for delivering applications to Kubernetes the GitOps way, with a clear UI showing sync status and health per application. For data teams it's a clean way to deploy and version pipeline components, Spark operators, and services on a cluster. It pairs with CI tools that build images and update manifests in Git; Argo CD then handles the deploy. It's often run alongside Argo Workflows and Argo Rollouts for progressive delivery.

Frequently asked questions

How is GitOps different from a normal CI/CD deploy? A push pipeline runs commands against the cluster from outside; GitOps has an in-cluster controller pull the declared state from Git and converge to it, with continuous drift detection.

What does self-heal do? If the live cluster drifts from Git - a manual change, a deleted resource - Argo CD detects it and reverts the cluster to match the repository.

How do rollbacks work? Because Git is the source of truth, rolling back is reverting to a previous commit; Argo CD then syncs the cluster to that earlier declared state.