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 | App Definition and Development › 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] -->|commit image tag| GIT
CI -->|push image| REG[(Container registry)]
USERS[Engineers] -->|UI, CLI, SSO| APISRV
subgraph ACD[Argo CD in the management cluster]
APISRV[API server<br/>UI, CLI, RBAC]
REPO[Repo server<br/>renders Helm and Kustomize]
CTRL[Application controller<br/>diff and sync]
CACHE[(Redis cache)]
APISRV -->|app requests| CTRL
REPO -->|manifests| CTRL
CTRL -.->|state cache| CACHE
end
GIT ==>|fetch manifests| REPO
CTRL ==>|apply and watch| C1[Cluster dev]
CTRL ==>|apply and watch| C2[Cluster prod]
C2 -->|progressive delivery| RO[Argo Rollouts<br/>canary or blue-green]
classDef actor fill:#eceff1,stroke:#455a64,stroke-width:1.5px,color:#1d1c1a
classDef core fill:#0f766e,stroke:#064e4a,stroke-width:2px,color:#ffffff
classDef ctrl fill:#ede7f6,stroke:#5e35b1,stroke-width:1.5px,color:#1d1c1a
classDef data fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#1d1c1a
classDef store fill:#fff3e0,stroke:#e65100,stroke-width:1.5px,color:#1d1c1a
classDef sec fill:#fce4ec,stroke:#ad1457,stroke-width:1.5px,color:#1d1c1a
classDef obs fill:#e8f5e9,stroke:#2e7d32,stroke-width:1.5px,color:#1d1c1a
class DEV,CI,USERS actor
class GIT,REG,CACHE store
class APISRV,REPO,CTRL core
class C1,C2 data
class RO ctrl
style ACD fill:#0f766e14,stroke:#0f766e,stroke-width:2px
Key: teal blocks are the project itself, blue are workloads and proxies, purple are control and configuration, amber are storage, red are security and identity, green are observability, grey are external actors. Thick arrows show the primary path, thin solid arrows other data flows, dashed arrows control, discovery and telemetry.
| 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:
- 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 - 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.
- 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 - 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.
- 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
replicasunder an HPA) should be listed inignoreDifferences, 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.mdfile 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