Flux and Argo CD · Prasanta Kumar Behera

The two CNCF-graduated GitOps agents compared: how Flux (a set of controllers and CRDs) and Argo CD (an application-centric server with a UI) model the same ideas, their strengths, and how to choose, with the same app deployed by each.

Same idea, two designs

Both Flux and Argo CD are CNCF-graduated, pull-based GitOps agents. They differ in shape:

	Flux	Argo CD
Architecture	Independent controllers (source, kustomize, helm, notification, image automation)	API server + repo server + application controller (+ UI, Dex/SSO)
Main objects	`GitRepository`/`OCIRepository` → `Kustomization` / `HelmRelease`	`Application`, `AppProject`, `ApplicationSet`
UI	None built in (CLI + Kubernetes tooling; third-party UIs exist)	Rich web UI with diffs, history, health, logs
Access model	Kubernetes RBAC and service-account impersonation per tenant	Own RBAC (projects, roles, SSO groups) on top of Kubernetes
Helm	Native `HelmRelease` (real Helm releases, supports Helm hooks)	Renders charts to manifests and applies them (Helm hooks mapped to Argo CD hooks)
SOPS	Native decryption	Via plugins
Image automation	Built-in controllers write new tags to Git	Argo CD Image Updater (separate project)
Multi-cluster	Usually one Flux per cluster, bootstrapped from a shared repo	One Argo CD can manage many clusters (or one per cluster)

Two ways to run a kitchen. Flux is a set of specialist appliances that each do one job very well and talk to each other through the order tickets. Argo CD is a head chef's station with a big screen showing every dish, who ordered it and whether it came out right.

The same app, both ways

Flux:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata: { name: gitops-config, namespace: flux-system }
spec:
  url: https://github.com/acme/gitops-config
  ref: { branch: main }
  interval: 1m
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata: { name: orders-api-dev, namespace: flux-system }
spec:
  sourceRef: { kind: GitRepository, name: gitops-config }
  path: ./apps/orders-api/envs/dev
  targetNamespace: shop
  prune: true
  interval: 5m

Argo CD:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: orders-api-dev, namespace: argocd }
spec:
  project: shop
  source:
    repoURL: https://github.com/acme/gitops-config
    targetRevision: main
    path: apps/orders-api/envs/dev
  destination: { server: https://kubernetes.default.svc, namespace: shop }
  syncPolicy:
    automated: { prune: true, selfHeal: true }

How to choose

If you need...	Lean towards
A UI for developers, SSO, per-team projects, one pane for many clusters	Argo CD
Kubernetes-native building blocks, native Helm releases and SOPS, image automation built in, minimal footprint per cluster	Flux
Edge or air-gapped clusters each managing themselves	Either; Flux is often lighter per cluster
Platform add-ons managed by the platform team, apps by product teams	Both work; some organisations even use Flux for the platform and Argo CD for app teams

Pick one per layer and standardise; the principles, repository design and promotion model (lessons 01–05) stay the same either way. The "Argo CD — Level by Level" track goes deep on Argo CD.

Try it: one app, two agents

On one kind cluster, flux bootstrap against a test repo and deploy apps/orders-api/envs/dev with the Flux objects above.
On a second kind cluster, install Argo CD and deploy the same path with the Application above.
Change the replica count in Git; compare how each shows and applies the change (flux get kustomizations vs the Argo CD UI).
Write down which you'd pick for your team and why.

Recap

Flux: composable controllers and CRDs, native Helm and SOPS, image automation, light per cluster.
Argo CD: application-centric server with UI, SSO, projects and multi-cluster management.
Both are pull-based and follow the same GitOps principles; choose by UI needs, tenancy model and operating style.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.