Flux vs Argo CD
The two CNCF-graduated GitOps engines for Kubernetes. Same core contract — declarative desired state in Git, pulled and continuously reconciled into the cluster, drift reverted — opposite shapes: Argo CD is an integrated platform (API server + repo server + application controller + web UI as one system, centralized hub), Flux is a modular toolkit (composable controllers — source/kustomize/helm/notification — living inside each cluster, no mandatory UI). The decision is where you put control and trust: hub-and-spoke vs distributed agents.
Architecture (from the repos, both captured)
- argo-cd (OSS) (24.3k★, Go, Apache-2.0) — application-centric: a first-class
ApplicationCRD grouping resources into one deployable unit; sync policies (manual/automated/self-heal/prune); AppProjects for RBAC and multi-tenant scoping; one hub can manage many clusters. Runs in ~60% of k8s clusters (2025 CNCF end-user survey, cited by Akuity). - flux2 (OSS) (8.4k★, Go, Apache-2.0) — “built from the ground up to use Kubernetes’ API extension system”: the GitOps Toolkit is a set of CRDs + controllers, controller-per-responsibility, multi-tenancy and many-repo sync. Clusters are autonomous — each pulls its own Git; no central API to reach (air-gap friendly). Integrates with Prometheus.
The comparison axes (grounded in captured sources)
| Axis | Argo CD | Flux |
|---|---|---|
| Control plane | Centralized hub, manages many clusters | Per-cluster controllers, autonomous |
| UX | Web UI (topology, sync status, health, actions) + SSO | CLI-first; dashboards via Weave/Grafana integration |
| Abstraction | Application CRD, AppProjects, ApplicationSets (guardrails) | Raw CRDs: GitRepository/Kustomization/HelmRelease |
| Secrets | External (plugins: helm-secrets, etc.) | Native SOPS support; OCI sources |
| Image automation | Pair with Kargo (promotion, verification gates) | Built-in image reflector/automation updates Git |
| Progressive delivery | Argo Rollouts (canary/blue-green) | Flagger |
| Multi-cluster | Single pane of glass | One Flux per cluster (fleet = Git structure) |
| Footprint | Heavier (the platform price) | Lightweight; edge/resource-constrained friendly |
| RBAC model | Own RBAC layer, separate from k8s RBAC (tedious at scale) | Kubernetes RBAC is the model |
| Adoption | ~60% of clusters, 23-24k★ | ~8.4k★; Weaveworks lineage, cloud-provider integrations |
Sources: Akuity comparison (by Argo’s creators — pro-Argo bias acknowledged) clippings/akuity-io-blog-argo-cd-flux-comparison.md · Plural clippings/plural-sh-blog-argo-cd-vs-flux.md · Northflank clippings/northflank-com-blog-flux-vs-argo-cd.md (their “Argo = CNCF incubating” is wrong — graduated since 2022; corrected here).
The decision (Akuity’s five dimensions, compressed)
- Team structure — central platform team serving many app teams → Argo CD’s UI + multi-tenant RBAC; autonomous teams closer to their repos → Flux
- UI vs CLI culture — visibility for non-terminal users → Argo; kubectl+Git natives → Flux
- K8s maturity — opinionated guardrails for newer teams → Argo; composability rewarding fluency → Flux
- Multi-cluster/security — single pane across a fleet → Argo; air-gapped/high-security (no central API egress) → Flux
- Ecosystem — promotion/verification across environments → Argo+Kargo; image-automation-to-Git and SOPS out of the box → Flux
Homelab read (doombox + Pi fleet, k3s)
Flux is the natural fit: k3s targets are resource-constrained, clusters are (or will be) autonomous per site, the workflow is already CLI+git (pi-cluster (OSS) — the captured mixed-ARM K3s reference homelab — runs Flux CD), and there’s no platform team needing a shared UI. Argo CD wins when a single human wants visual oversight of many apps on one strong node — the “single pane” for a fleet you watch rather than a fleet that fends for itself. Both are graduated, production-grade; the pi-cluster (OSS) precedent settles it for this homelab lane.
Related: Infrastructure as Code · Golden repo (GitOps is its deployment arm) · pi-cluster (OSS) · Homelabs
The layer above: Sveltos (addendum, 2026-10-05)
sveltos (OSS) (145★, CNCF sandbox) — the multi-cluster dispatcher that sits on top of Flux/Argo rather than competing with them (it integrates with both): run it on a management cluster, label your clusters, write a ClusterProfile (“deploy this to every cluster with that label”) — new clusters with the right label converge automatically, removed ones get cleaned up. syncMode: Continuous reconciles drift on managed clusters (management cluster stays the source of truth); supports Helm/raw YAML/Kustomize/Carvel ytt/Jsonnet; pull mode for edge/firewalled clusters where hub-initiated reach is impossible (the regulated-industry gap most GitOps tools leave). Honest caveats from the captured walkthrough (clippings/medium-com-markof128-local-platform-engineering-…): complexity jumps past plain ClusterProfiles once templateResourceRefs/Event Framework enter; and the management cluster is a single point of control — down = nothing deploys, compromised = it owns every cluster (pull mode mitigates the credential half). Lab topology: vind multi-cluster on laptop → Argo CD on mgmt → Sveltos fans out to labeled dev/staging.