Argo CD

GitOps delivery for Kubernetes: a controller in the cluster keeps what’s running identical to the manifests in a Git repository.

What it is: CI/CD pipelines
Type: Open source
Made by: Cloud Native Computing Foundation (Argo project)
License: Apache 2.0
Facts checked: 5 October 2026

What it is

Most pipelines push: a CI job runs kubectl apply or helm upgrade against the cluster. Argo CD pulls instead. It runs inside Kubernetes, and each Application resource points it at a Git repository, a revision and a path. Its repo server renders the manifests there (plain YAML, Helm charts, Kustomize or Jsonnet), and its application controller compares them with the live objects in the cluster. Any difference marks the application OutOfSync.

Syncing applies the difference, either when someone clicks Sync or automatically. With automated sync, prune deletes objects that were removed from Git and selfHeal reverts changes made by hand in the cluster. Git therefore becomes the record of what is deployed, and a rollback is a git revert. One Argo CD can manage many clusters, and its web UI shows every resource’s health and sync status. Argo graduated from the CNCF in December 2022.

Why teams pick it

CI never needs credentials for the cluster: Argo CD runs inside it and pulls from Git
Drift is visible straight away, and selfHeal can undo manual kubectl edits
Works with plain YAML, Helm, Kustomize and Jsonnet, and manages many clusters from one place
A clear web UI with a live resource tree, diffs and sync history, plus SSO and RBAC

Watch out for

Kubernetes only; VMs, serverless functions and cloud resources need another tool such as Terraform
By default it checks Git every 2 to 3 minutes (120 s plus jitter), so deploys lag unless you add a Git webhook
It deploys what Git says; building images and updating tags in Git is still CI’s job
Secrets don’t belong in Git as plain text; its docs recommend an in-cluster tool such as Sealed Secrets or External Secrets Operator

Alternatives

What all ci/cd pipelines have in common →

GitHub ActionsCommercialCI/CD built into GitHub: YAML workflows in the repository run on GitHub’s VMs or your own machines whenever something happens in the repo.

How it fits with other technologies

What Argo CD uses

Argo CDruns inside and continuously deploys toKubernetesContainer orchestration

What uses Argo CD

Gitis the source of truth forArgo CDVersion control

An Application that keeps a namespace in sync with Git · yaml

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 }

See it in a real stack

No architecture uses Argo CD yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2017–2026

Argo began at Applatix, a startup whose engineers open-sourced Argo Workflows, a Kubernetes-native workflow engine, in 2017. In 2018 Intuit acquired Applatix, and the Argo team moved there; its manager, Hong Wang, went on to build the control plane Intuit used for hundreds of Kubernetes clusters. The team wanted every application’s definitions, configuration and environments to be declarative and version-controlled, with deployments that were automated and auditable.

The Argo team at Intuit, with Jesse Suen leading the design and Alexander Matyushentsev leading development, built Argo CD as a Kubernetes controller that follows the GitOps pattern: a Git repository is the source of truth, and software in the cluster continuously makes reality match it. The first commit landed on GitHub in February 2018 and version 0.1.0 was tagged that March.

Argo, made up of Argo CD, Workflows, Rollouts and Events, joined the CNCF as an incubating project in April 2020 and graduated in December 2022. Its three creators later left Intuit to found Akuity around it. Argo CD 3.0 followed in May 2025, turning settings that many users already chose into the defaults.

Why it’s built this way

A controller inside the cluster that pulls from Git: Running as a Kubernetes controller lets Argo CD compare the live state with Git continuously and mark any difference OutOfSync, instead of trusting that the last CI push still holds. CI also no longer needs credentials for the cluster.
Applications defined as Kubernetes resources: An Application is itself a custom resource, so Argo CD can be configured the same declarative way as everything it deploys, including from Git.
Bring your own manifest tool: Teams already wrote manifests as plain YAML, Helm charts, Kustomize or Jsonnet. Rendering all of them, plus custom plugins, let Argo CD adopt existing repositories instead of demanding a new format.

Timeline

2017
Applatix open-sources Argo Workflows
2018
Intuit acquires Applatix; Argo CD 0.1.0 tagged in March
2020
Argo joins the CNCF as an incubating project
2022
Argo graduates from the CNCF in December
2025
Argo CD 3.0 released in May
2026
Argo CD 3.3 adds PreDelete hooks and safer deletions

Sources8 · facts checked 5 October 2026

Improve this page on GitHub