ArgoCD vs Flux — ApplicationSets and sync waves vs source-controller and Kustomization.

April 30, 2026 · Anton Grishko

ArgoCD or Flux — and why we picked ArgoCD

Both projects do GitOps well. After running both in production for years, here's the honest breakdown of where each one lands.

TL;DR — Both ArgoCD and FluxCD are production-grade GitOps controllers. We default to ArgoCD for ApplicationSets, sync waves, and the UI. Flux wins on image automation and multi-tenancy.

Both projects work

This is the part most comparison posts skip. ArgoCD and Flux are both production-grade CNCF projects. Either one will reconcile your Kubernetes manifests from Git and tell you when drift happens. If you already have one running and it's working, switching is rarely the right call.

That said — when starting fresh, we pick ArgoCD. Three concrete reasons:

1. ApplicationSets > Kustomization sets

The single biggest reason. ArgoCD's ApplicationSet generators (git, list, cluster, matrix) let one resource describe "every chart in helm/* of this repo, deployed to every cluster matching this label, with this values file pattern." Flux has Kustomization composition but no equivalent of the matrix generator. We use this exact pattern to bootstrap every customer's cluster:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
spec:
  generators:
    - git:
        directories:
          - path: helm/*
        repoURL: ...
  template:
    spec:
      source:
        path: 'helm/{{path.basename}}'
        helm:
          valueFiles:
            - ${env}.yaml

Adding a new chart is one git commit — no new Application object.

2. The UI is part of the operating model

People dismiss this as cosmetic. It's not. The ArgoCD UI is the mental model your on-call engineer reaches for at 3am — the resource tree, the diff, the sync wave timeline, the live logs. Flux is more CLI-native and that's a deliberate philosophical choice on their part. We just find the UI saves enough time on incident triage to justify ArgoCD.

3. Sync waves are clearer than depends-on chains

ArgoCD sync waves (argocd.argoproj.io/sync-wave: "10") are easier to reason about than Flux's dependsOn chains, especially as your platform grows. We deploy in waves: CRDs → operators → namespaces → workloads. One annotation per resource. Done.

What Flux does better

To be fair — Flux beats ArgoCD on:

Image automation — Flux's image-update controller is more cohesive than ArgoCD Image Updater. We work around this by having CodeBuild push the new tag into the values file directly.
Multi-tenancy isolation — Flux's per-tenant impersonation model is cleaner than ArgoCD's project model.
Smaller surface area — fewer CRDs, simpler operator footprint.

If you're a single-team shop and you don't need ApplicationSets, Flux is genuinely lighter and easier to reason about.

How we deploy ArgoCD

The chart at infrastructure/helm/<app> is the source of truth. ArgoCD's ApplicationSet watches helm/* directories on the env-matching branch (main for dev, prod for prod). Every chart picks up <env>.yaml automatically. CI bumps the image tag in that values file. ArgoCD reconciles within a couple of minutes.

That's it. No per-app Application objects to maintain. No hand-written Application YAML. Add a chart directory, push, ArgoCD owns it. The broader pattern — Helm charts in a single repo, env per branch — is the same one we ship to every customer in DevOps on autopilot.