Argo: GitOps Delivery and Workflows Native to Kubernetes

Argo is a family of Kubernetes-native tools for delivering and running software: Argo CD for GitOps continuous delivery, Argo Rollouts for canary and blue-green releases, Argo Workflows for container-native pipelines and batch jobs, and Argo Events for event-driven triggers. Its best-known component, Argo CD, addresses a core weakness of push-based CI/CD: pipelines that hold cluster credentials and leave no reliable record of what is actually running. Argo CD instead runs inside the cluster, continuously compares the live state with the desired state declared in Git, and reconciles any difference. Argo was created at Applatix, which Intuit acquired in 2018, and Intuit has led its development since. It was accepted into the CNCF as an incubating project in March 2020 and graduated in December 2022.

CNCF daily · Sprint 1, day 1 · Continuous Integration & Delivery

At a glance

Category	Continuous Integration & Delivery
CNCF status	Graduated. Accepted March 26, 2020 (Incubating); graduated December 6, 2022
Written in	Go, with a React web UI
License	Apache 2.0
Sub-projects	Argo CD, Argo Rollouts, Argo Workflows, Argo Events
Deployment model	Pull-based: controllers run in the cluster and read from Git
Manifest sources	Plain YAML, Helm charts, Kustomize, Jsonnet and config management plugins

Architecture

The diagram focuses on Argo CD, the component most teams adopt first.

flowchart TB
  DEV[Developer] -->|pull request| GIT[Git repository<br/>desired state]
  CI[CI pipeline] -->|build and push image| REG[Container registry]
  CI -->|update image tag| GIT
  subgraph ACD[Argo CD in the management cluster]
    REPO[Repo server<br/>renders Helm, Kustomize]
    CTRL[Application controller<br/>diff and sync]
    APISRV[API server<br/>UI, CLI, SSO, RBAC]
    CACHE[(Redis cache)]
    REPO --> CTRL
    APISRV --> CTRL
    CTRL --> CACHE
  end
  GIT --> REPO
  CTRL -->|apply and watch| C1[Cluster dev]
  CTRL -->|apply and watch| C2[Cluster prod]
  C2 --> RO[Argo Rollouts<br/>canary or blue-green]
  USERS[Engineers] --> APISRV

Component	Responsibility
Application	A custom resource that maps a Git path and revision (or a Helm chart) to a destination cluster and namespace.
Repo server	Clones repositories and renders manifests from Helm, Kustomize, Jsonnet or plain YAML.
Application controller	Compares rendered manifests with live cluster state, reports drift and health, and syncs changes.
API server and UI	Serves the web UI, CLI and API, with SSO through OIDC and project-level RBAC.
ApplicationSet controller	Generates many Applications from templates, for example one per cluster, per directory or per pull request.
Argo Rollouts	Replaces a Deployment’s rolling update with canary or blue-green steps, analysis queries and automatic rollback.
Argo Workflows / Events	Run DAG-style job pipelines as pods, triggered by webhooks, queues, schedules and other events.

Design principle. Git is the single source of truth, and the cluster pulls changes rather than having CI push them. Every change is reviewed, versioned and reversible through Git history. Production credentials stay inside the cluster, and drift caused by manual kubectl changes is detected and, if enabled, corrected automatically.

Production reference design

A hub-and-spoke setup on EKS, GKE, AKS or on-premises clusters, with one Argo CD instance managing several workload clusters:

1. Install Argo CD in high-availability mode in a management cluster using the official Helm chart:

   helm repo add argo https://argoproj.github.io/argo-helm
   helm install argocd argo/argo-cd -n argocd --create-namespace \
     --set redis-ha.enabled=true --set controller.replicas=1 \
     --set server.replicas=2 --set repoServer.replicas=2

2. Structure Git into two kinds of repository: application source code (built by CI), and a GitOps repository holding Helm values or Kustomize overlays per environment. CI’s only write to the GitOps repository is the new image tag.
3. Declare each workload as an Application, with automated sync, pruning and self-healing:

   apiVersion: argoproj.io/v1alpha1
   kind: Application
   metadata:
     name: payments-prod
     namespace: argocd
   spec:
     project: payments
     source:
       repoURL: https://git.example.com/platform/gitops.git
       targetRevision: main
       path: apps/payments/overlays/prod
     destination:
       server: https://prod-cluster.example.com
       namespace: payments
     syncPolicy:
       automated:
         prune: true
         selfHeal: true
       syncOptions:
         - CreateNamespace=true

4. Scale out with ApplicationSets so each new cluster or service directory gets its Applications automatically, and use AppProjects to restrict which repositories, clusters and namespaces each team may deploy to.
5. Add Argo Rollouts for risky services: canary steps (for example 10%, 25%, 50%) gated by Prometheus analysis, with traffic split through the ingress controller or service mesh and automatic rollback on failed metrics.

Typical production uses include multi-cluster application delivery, bootstrapping platform add-ons on new clusters (“app of apps”), pull-request preview environments and progressive delivery for customer-facing services.

Operational considerations

• Size the controller for your fleet. The application controller holds a watch on every managed resource. Large estates (thousands of Applications or dozens of clusters) need controller sharding, higher memory limits and tuned reconciliation intervals.
• Secure the hub. The management cluster holds credentials for every target cluster, which makes it a high-value target. Enable SSO, disable the local admin account, apply AppProject restrictions and keep Argo CD patched; it has had several critical CVEs.
• Keep secrets out of Git. Use External Secrets Operator, Sealed Secrets or SOPS rather than committing plain Kubernetes Secrets.
• Sync order and hooks. Use sync waves and hooks for dependencies such as CRDs before custom resources, or database migrations before application rollout.
• Avoid fighting controllers. Fields changed by autoscalers or operators (for example replicas under an HPA) should be listed in ignoreDifferences, or self-heal will revert them in a loop.

Adoption

• Argo was created at Applatix and has been developed by Intuit since 2018, and Intuit runs it at scale internally.
• The Argo CD USERS.md file lists hundreds of organisations, including Adobe, Alibaba Group, BMW Group, Capital One, DigitalOcean, IBM, Intel, MongoDB and Mozilla.
• Commercial platforms are built on it, including Red Hat OpenShift GitOps, and Akuity, founded by Argo’s creators. The CNCF project page also lists a case study from Subaru.

Alternatives

Solution	Model	Best suited to
Flux (CNCF Graduated)	Pull-based GitOps toolkit of controllers, no built-in UI	Teams that prefer a modular, CLI-first approach
Jenkins / GitLab CI / GitHub Actions	Push-based pipelines that run kubectl or helm	Simple setups, or teams not yet ready for GitOps
Spinnaker	Multi-cloud continuous delivery platform	Large organisations deploying to VMs and Kubernetes together
Tekton (CNCF Incubating)	Kubernetes-native CI pipeline building blocks	Building CI pipelines; often paired with Argo CD for delivery
PipeCD (CNCF Sandbox)	GitOps CD for Kubernetes, serverless and VMs	Mixed platforms beyond Kubernetes

Strengths and limitations

Strengths	Limitations
Clear UI showing sync status, health and diffs per resource	The hub becomes a critical, high-privilege component
Drift detection and self-healing from Git as the source of truth	Performance tuning needed at large scale
Native Helm and Kustomize support; ApplicationSets for fleets	Secrets management requires separate tooling
Rollouts adds canary and blue-green with metric-based rollback	Workflows, Events and Rollouts each add components to operate
Large community, graduated status and commercial support options	Git-only promotion between environments needs extra conventions

Recommendation

Adopt Argo CD as the delivery layer for Kubernetes, with Helm or Kustomize for packaging and CI limited to building images and updating Git. Add Argo Rollouts for services where a bad release is costly, and treat the Argo CD hub as production infrastructure: highly available, behind SSO, patched promptly and restricted by AppProjects.

References: CNCF project page · Argo CD documentation · Argo Rollouts documentation · Argo CD users list · Argo Helm charts