Kubernetes GitOps: Argo CD vs Flux 2026

Two GitOps controllers, two mental models. Repo layout, drift detection, multi-cluster fan-out, and which one fits the way your team actually works.

Why GitOps wins

The non-GitOps pattern: a CI pipeline runs kubectl apply; the cluster state ends up wherever the most recent apply landed it; drift between repo and cluster is invisible. The audit log is the CI log; the source of truth is “whatever’s in the cluster right now.”

The GitOps pattern: a controller in the cluster watches a git repo; whatever the repo says, the cluster becomes. Manual edits revert. The source of truth is the repo; the cluster is a projection of it. The audit log is the git log.

The benefits compound. Reviews on PRs gate every change. Rollback is git revert. Drift becomes a CI alarm. Multi-cluster fan-out is a directory structure. The whole story shifts from “run kubectl carefully” to “merge the PR.”

Two tools dominate: Argo CD (CNCF graduated, application-centric UI, big ecosystem) and Flux (CNCF graduated, controller toolkit, lower UI surface, more composable). The choice between them is mostly about how your team thinks.

Argo CD, the application-centric model

Argo CD’s core abstraction is the Application, a pointer that says “sync this directory in this git repo to this namespace in this cluster.” You define applications; Argo CD reconciles them; the UI shows you each application’s sync status, its diff against git, its health, its history.

The strengths. The UI is the killer feature. You can see every application across every cluster, click into any one, see the manifests, see the diff between desired and actual, force a sync, force a refresh, roll back. For platform teams supporting many app teams, the UI cuts triage time dramatically.

The strengths cont. ApplicationSet for fan-out: a single resource that templates many Applications, one per cluster, one per branch, one per directory in the repo. Lets you scale to hundreds of applications without writing them by hand.

The weak spot. Argo CD is a single pane of glass; that pane is opinionated. The Application resource is the only abstraction; everything fits into it or fights against it. Helm releases, Kustomize overlays, plain manifests, all expressed as Applications.

Where it shines. Platform teams that support many app teams; multi-cluster deployments where the UI helps; companies that want a self-service GitOps surface for non-ops engineers.

Flux, the controller-toolkit model

Flux is a different shape. Instead of one big controller with one resource, Flux is several independent controllers, each with its own CRD: source-controller (fetches git/helm/oci), kustomize-controller (applies kustomizations), helm-controller (manages helm releases), notification-controller (events out), image-automation-controller (updates manifests on new images).

The strengths. Composability. Each controller does one thing; you wire them together. If you need a piece of the puzzle and not the rest, run only that controller. The image-automation-controller in particular is a killer feature for teams that want continuous deployment driven by registry pushes.

The strengths cont. CLI-friendly. Most operations are kubectl-on-CRDs; the lack of a UI is a feature for ops-heavy teams who prefer Terminal-driven workflows. Lighter resource footprint than Argo CD’s server-plus-controller stack.

The weak spot. No UI by default. There’s a separate Weave GitOps UI, but it’s less mature than Argo’s. For teams that want self-service for non-ops users, Flux requires more work.

Where it shines. Platform teams that prefer composable building blocks; teams already invested in Helm; image-automation-driven CD pipelines; resource-constrained environments.

Repo layout patterns

Both tools support the same basic layouts; the patterns are language-agnostic.

Pattern 1: monorepo with environment overlays. One repo, directories like base/ + overlays/dev/ + overlays/staging/ + overlays/prod/. Kustomize patches per environment. Argo CD ApplicationSets fan out one Application per overlay; Flux Kustomizations do the same. Easy to start; couples all envs to one repo.

Pattern 2: app-of-apps. A “root” Application that points to a directory of more Applications. Lets you bootstrap a cluster with a single resource; the root pulls in everything else. Common in Argo CD; Flux can do something similar with Kustomization-of-Kustomizations.

Pattern 3: per-cluster repos. One repo per cluster (or per environment). Higher coupling between repo and cluster; cleaner blast radius for changes; harder to share manifests between environments.

The pattern most teams settle on. Monorepo with overlays for the platform layer (cluster add-ons, networking, observability), separate repos per app team for application code. Argo CD or Flux watches both; teams have their own scope; the platform team owns the platform repo.

Drift detection in practice

Drift is the gap between what git says and what the cluster shows. Both tools detect it; what they do about it differs.

Argo CD: shows drift in the UI as a yellow “OutOfSync” status. By default, it doesn’t auto-correct, you have to click sync (or enable auto-sync). Drift is visible; remediation is a choice.

Flux: by default, auto-corrects every reconcile interval (typically 5 minutes). A manual kubectl edit in production gets reverted on the next reconcile. The lack of UI means drift is mostly invisible unless you’re looking at controller logs or events.

The trade-off. Argo’s UI-driven drift detection lets you see and decide; Flux’s auto-correct is stricter but less visible. Pick based on how much your team needs to do live edits during incidents, Argo’s pause-and-decide is more incident-friendly.

The discipline. Either way, drift should be a graded thing. Drift in dev is fine; drift in prod is an alert. Set up Prometheus metrics on sync status and alert on prod-OutOfSync; you’ll catch the manual-edit-during-incident pattern fast.

Picking one

The decision boils down to your team’s relationship with UIs and abstractions.

Argo CD wins if you have many app teams sharing a platform; if non-ops engineers will interact with deployment status; if you want a clear “Application” abstraction; if image-automation isn’t critical to your CD story.

Flux wins if you’re a small ops-heavy team; if you want composable controllers and don’t mind the lack of UI; if image-automation is a central feature; if you’re running on resource-constrained edge clusters.

The cop-out answer that’s actually true: either works. Both are CNCF-graduated; both are production-tested; both have large communities. The cost of switching later is real but not catastrophic. Pick based on team taste; commit; move on.

What to do this week

Three moves. (1) If you’re not on GitOps yet, install Argo CD or Flux on your dev cluster and point it at a single application. The first “merge a PR, see it deploy” moment is what sells the team. (2) Pick the repo layout that matches your team structure, monorepo for small teams, per-app-repos for large ones. (3) Set up the drift-detection alerts: Prometheus metric on OutOfSync status in prod, page when it lasts >15 minutes. The alert catches the “quick kubectl edit during the incident” pattern that erodes GitOps over time.