Open-Source Wikis

/

Argo CD

/

Lore

argoproj/argo-cd

Lore

A narrative history of the Argo CD codebase, derived from git history, CHANGELOG.md, MAINTAINERS.md, and directory archaeology. Every era below is dated from the relevant commits.

The origin (Feb 2018 – early 2019)

Argo CD's first commit lands on 14 February 2018, three days before Valentine's Day. The early repository carries the structure of a single-binary Go project that already speaks the GitOps vocabulary of "Application", "Project", and "Sync". Within the first year, key shapes that survive to this day appear:

  • The unified cmd/main.go dispatcher that routes a single binary into multiple commands based on its name.
  • The Application and AppProject CRDs in pkg/apis/application/v1alpha1/.
  • The split between api server, application controller, and repo server — the three workhorses of every Argo CD install ever since.

Argo CD was an Intuit and Akuity-led project from the start (the founders Alex Matyushentsev and Jesse Suen later become CNCF maintainers and Akuity founders).

CNCF and v1.0 (mid-2019 – 2020)

Argo joins the CNCF Sandbox in 2020 and graduates to Incubation later. v1.0 stabilizes the API and CLI conventions. By this era the repo also carries:

  • The React/TypeScript UI in ui/, sharing the API server's binary via embed.go.
  • OIDC/SSO through the argocd-dex bridge.
  • Webhooks for GitHub/GitLab/Bitbucket so syncs respond instantly to pushes.
  • Notifications (still as a separate argocd-notifications project at this point — it gets merged into the main repo later).

ApplicationSet era (2020 – 2022)

The ApplicationSet controller is initially developed in the sibling argoproj-labs/applicationset repo and graduates into Argo CD itself. It introduces the generator abstraction in applicationset/generators/: List, Cluster, Git (file/directory), Matrix, Merge, SCM Provider, Pull Request, and (later) Plugin. ApplicationSets become the de-facto multi-cluster fan-out mechanism for platform teams.

The ApplicationSet controller binary is added under cmd/argocd-applicationset-controller/, and CRDs flow into pkg/apis/application/v1alpha1/applicationset_types.go.

Notifications absorbed (2022 – 2023)

The previously separate argocd-notifications controller is folded into the main repo. The runtime moves under notification_controller/, with the engine logic and triggers/templates living in util/notification/ and notifications_catalog/. The bundled argocd-notifications binary is added to the dispatch table in cmd/main.go and shares Redis with the rest of the stack.

v2 series and operational maturity (2022 – 2024)

The 2.x series brings most of the operational features that today's Argo CD users take for granted:

  • Sharding for the application controller so it can scale beyond one replica (controller/sharding/).
  • Server-side diff and apply for large or contentious resources.
  • Multi-source applications, supporting Git + Helm + OCI inputs to a single Application.
  • Cluster info updater and impersonation (util/clusterauth/, util/db/cluster.go).
  • Config Management Plugin v2 — sidecar plugins talking to the repo server over Unix sockets (cmpserver/, util/cmp/).

The CHANGELOG.md for these versions is hundreds of pages long; this era is when Argo CD becomes the de facto GitOps controller for production Kubernetes platforms.

OCI and Helm registries (2023 – 2024)

Helm-via-OCI and pure-OCI artifact sources arrive in util/oci/ and adjacent code paths. The repo server learns to log into Docker/OCI registries and to extract Helm charts from arbitrary registries, not just classic chart repos.

The manifest hydrator (2024 – 2025)

The manifest hydrator is one of the most architecturally significant additions in years. It introduces a brand-new binary, the commit server (commitserver/), and supporting libraries in util/hydrator/ and controller/hydrator/. The flow:

  1. The application controller renders manifests from the source revision.
  2. The commit server commits those rendered manifests to a "hydrated" branch in Git.
  3. The Application is then synced from the hydrated branch — giving auditors a Git diff view of every actual change applied to the cluster.

A separate install variant (manifests/install-with-hydrator.yaml, manifests/core-install-with-hydrator.yaml, manifests/cluster-install-with-hydrator/) ships the hydrator-enabled topology.

CNCF Graduated (2024)

Argo CD becomes a CNCF Graduated project, alongside Argo Workflows and the rest of the Argo family.

v3 (2025) and the long tail

The repo bumps its module path to github.com/argoproj/argo-cd/v3 and v3 ships with cleaned-up APIs, the manifest hydrator promoted from preview, and continued polish to the ApplicationSet generators. The v3.x line is the active series at the time of this wiki (see VERSION = 3.5.0).

Longest-standing surfaces

These pieces of the codebase have changed continuously but never been replaced:

  • pkg/apis/application/v1alpha1/types.go — the canonical Application and friends; expanded but never rewritten.
  • cmd/main.go dispatcher pattern — the same shape since 2018.
  • controller/appcontroller.go — the heart of reconciliation, growing in place.
  • server/application/application.go — the largest gRPC handler, present since the first API server release.

Deprecated / replaced bits

  • The legacy argocd-notifications standalone repo — replaced by the in-tree notification_controller/.
  • v1 and v2 Go module paths — replaced by v3 (current).
  • Various early sync algorithms — superseded by the gitops-engine sync plumbing pulled into gitops-engine/ (a vendored sub-tree under this repo).

For a more granular timeline, browse CHANGELOG.md — the file is ~150 KB and effectively a release-by-release diary of the project.

Built by Factory AutoWiki from public repository content. It is a generated preview for codebase exploration, not source-maintained documentation.

Lore – Argo CD wiki | Factory