Argo CD vs Flux: how do they differ?
Argo CD and Flux are both CNCF-graduated GitOps tools that keep Kubernetes clusters in sync with Git or OCI repositories. Argo CD is an application-centric server with a built-in web UI, its own RBAC and single sign-on, and one instance commonly manages many clusters. Flux is a set of independent Kubernetes controllers, the GitOps Toolkit, configured entirely through custom resources and Kubernetes RBAC, and it usually runs inside each cluster it manages.
Side-by-side comparison
| Argo CD | Flux | |
|---|---|---|
| Architecture | API server, repository server, application controller and web UI | Separate controllers for sources, Kustomize, Helm, notifications and image automation |
| Main resources | Application, ApplicationSet, AppProject |
GitRepository, OCIRepository, Kustomization, HelmRelease |
| User interface | Built-in web UI and CLI | CLI; a web UI is available through the separate Flux Operator project |
| Access control | Argo CD RBAC with SSO through OIDC or Dex | Kubernetes RBAC; each sync can impersonate a service account |
| Multi-tenancy | AppProject limits repositories, destination clusters, namespaces and resource kinds |
Tenants get namespaces and service accounts; the cluster’s RBAC limits what they can apply |
| Multi-cluster | One instance manages remote clusters with stored credentials; ApplicationSets generate apps per cluster | Usually one Flux installation per cluster; can also target remote clusters through a kubeconfig secret |
| Helm | Renders charts with helm template; Argo CD, not Helm, manages the lifecycle |
helm-controller installs real Helm releases, with hooks, tests and rollback |
| Image update automation | Separate Argo CD Image Updater project | Built-in image reflector and image automation controllers |
| Progressive delivery | Argo Rollouts (separate project) | Flagger (separate project) |
| CNCF status | Graduated December 6, 2022 | Graduated November 30, 2022 |
Dates come from the CNCF project pages for Argo and Flux.
Architecture and day-to-day use
Argo CD centers on the Application: a source path, a destination cluster and namespace, and a sync policy. Its web UI shows each application as a tree of resources with sync and health status, diffs against Git and buttons to sync, roll back or delete. Developers who do not use kubectl daily often find this the main reason to choose it.
Flux has no central server. Each controller reconciles its own resource type, and you inspect state with flux get, kubectl or whatever dashboards you already use. That makes Flux feel like part of Kubernetes rather than a product on top of it, and it composes well with other controllers. The Flux Operator web UI adds a status dashboard, but it comes from the separate Flux Operator project rather than from the Flux core components.
Multi-tenancy and access control
Argo CD runs with broad permissions in its own namespace and enforces tenant boundaries in its own layer. An AppProject restricts which repositories a team can deploy from and which clusters, namespaces and resource kinds they can target. Users log in to Argo CD through SSO, and Argo CD RBAC policies map their groups to projects.
Flux relies on Kubernetes itself. A Kustomization or HelmRelease can name a service account, and the controller applies resources with that account’s permissions. Tenant isolation then comes from namespaces and RBAC, which the article on Kubernetes multi-tenancy covers.
Helm handling
The difference matters if you depend on Helm features. The Argo CD documentation states that Helm “is only used to inflate charts with helm template” and that the lifecycle “is handled by Argo CD instead of Helm” (Argo CD Helm guide). As a result, helm list does not show those releases, and Helm hooks are mapped to Argo CD sync hooks. Flux’s helm-controller performs actual Helm installs and upgrades, so releases, hooks and helm rollback behave as they would from the Helm CLI.
Multi-cluster management
A single Argo CD instance with an ApplicationSet can roll the same application out to dozens of clusters from one place, which suits a central platform team. The trade-off is that the central instance holds credentials for every cluster and becomes a single point of failure for deployments. With Flux, each cluster pulls its own configuration, so no central system holds cluster credentials. The cost is that you need another tool to see the state of all clusters at once. The article on what GitOps is explains both models.
Project governance and hosted options
Argo started at Applatix, which Intuit acquired, and Intuit still contributes to it. Flux was created by Weaveworks, which shut down in February 2024. Core maintainers continued the project, and ControlPlane hired two of them to keep working on Flux. Both projects remain CNCF graduated projects under open governance.
Both tools are also available as managed or commercially supported products. For example, AWS runs Argo CD as an EKS capability, Red Hat ships Argo CD as OpenShift GitOps, and Microsoft offers Flux as the GitOps extension for AKS and Azure Arc. Other vendors sell support and hosted control planes for each.
How to choose
Neither tool is better in general. The deciding questions are practical:
- Do developers need a UI to see and trigger deployments? Argo CD’s UI is built in.
- Do you rely on Helm hooks, tests and
helm rollback? Flux keeps Helm’s release semantics. - Do you want one central control point for many clusters? Argo CD with ApplicationSets fits that model. A per-cluster pull model points to Flux.
- Do you want tenant isolation in Kubernetes RBAC alone? Flux uses it directly; Argo CD adds its own layer.
- What does your team or vendor already run? Both are mature, and migrating between them later mostly means rewriting the resources that point at your manifests, not the manifests themselves.
Running both is also possible, for example Flux for cluster add-ons and Argo CD for application teams, as long as each resource has exactly one owner. The CI/CD deploy guide shows where either tool fits after the build pipeline.