Both Argo CD and Flux are CNCF-graduated GitOps controllers that pull the desired state of your Kubernetes clusters from Git and keep the clusters in line with it. They solve the same problem and both are production-grade; the difference is in how they model applications, how much they put in front of your developers, and how they fit a multi-team platform. Short version: Argo CD gives you an application-centric model with a first-party UI, SSO and RBAC out of the box — the better default when many teams will deploy through it and need to see what is happening. Flux is a set of composable controllers that feel like native Kubernetes resources — the better default for platform teams that want GitOps as infrastructure plumbing, with image automation built in and no UI to run. We used Argo CD for the EKS migration described in this case study; the reasons are at the end.
What they have in common
- Pull-based reconciliation. A controller inside the cluster watches Git (or an OCI registry) and applies what it finds; CI never needs cluster credentials.
- Helm and Kustomize as the main packaging formats, plus plain manifests.
- Drift detection and self-healing — if someone edits a resource by hand, the tool notices and, if you let it, reverts it.
- Multi-cluster from one control plane, and multi-tenancy controls so teams only touch their own namespaces.
- Health and sync status exposed as Kubernetes resources, so both work with the same alerting and dashboards you already have.
- Both are CNCF graduated projects with large communities and are packaged by the main Kubernetes vendors and cloud marketplaces.
If your requirement is "deploy from Git, safely, to EKS", either will do it. The choice is about the shape of the thing you operate afterwards.
Where they differ
| Argo CD | Flux | |
|---|---|---|
| Core model | Application (and ApplicationSet for fan-out across clusters/environments) in a central Argo CD instance | Composable controllers: GitRepository/OCIRepository sources, Kustomization and HelmRelease reconcilers, each a CRD |
| UI | First-party web UI: app topology, diffs, sync history, logs, manual sync/rollback | No first-party UI; CLI (flux) plus community dashboards |
| Access control | Built-in SSO (OIDC/SAML via Dex) and RBAC per project/app; useful when developers use the UI | Relies on Kubernetes RBAC and service-account impersonation per Kustomization; nothing extra to secure, but nothing to show developers either |
| Multi-tenancy | AppProject boundaries: allowed repos, clusters, namespaces, resource kinds | Namespace-scoped reconcilers with serviceAccountName; tenants get their own sources and reconcilers |
| Ordering & hooks | Sync waves and phases, resource hooks (pre/post-sync jobs) | dependsOn between Kustomizations/HelmReleases; Helm hooks via Helm itself |
| Image automation | Separate project (Argo CD Image Updater) | Built in: image-reflector and image-automation controllers write new tags back to Git |
| Progressive delivery | Argo Rollouts (same project family): canary, blue/green, analysis | Flagger (CNCF, Flux ecosystem): canary, A/B, blue/green with the usual service meshes and ingresses |
| Notifications | Argo CD Notifications (built in) | notification-controller: alerts and webhooks per resource |
| OCI | Helm charts from OCI registries; broader OCI artifact support arriving in recent versions — check your version | OCI artifacts as a first-class source (manifests, Kustomize, Helm) |
| Footprint | One control-plane install (API server, repo server, controller, Redis, UI); heavier, but one thing to run | Several small controllers; lighter per cluster, easy to install per cluster |
| Developer experience | "Open the UI, see the app, click sync/rollback" | "Read the YAML, run flux reconcile, read the events" |
The table is honest about the trade: Argo CD carries more components so that it can give people a console; Flux carries fewer so that it can disappear into the cluster.
When to choose Argo CD
- Several product teams will deploy through it and want to see state, diffs and history without learning the CLI or
kubectl. - You want SSO and per-team RBAC on the deployment tool itself, with an audit trail of who synced what.
- You run many environments and clusters from one place and
ApplicationSetgenerators (per cluster, per Git directory, per pull request) map directly onto how you work. - Canary or blue/green releases are on the roadmap and you would rather stay in one project family (Argo Rollouts).
When to choose Flux
- A small platform team treats GitOps as infrastructure plumbing and is comfortable in YAML and the CLI; nobody needs a console.
- You want image automation in the core: new image tags committed back to Git without an extra component.
- You deploy the same stack to many clusters and prefer a light per-cluster install over one central control plane.
- OCI artifacts (not just Helm charts) are already how you ship manifests.
- You are deep in the Flux ecosystem already — Flagger for canaries, Terraform-managed bootstrap, Weave-style multi-tenancy patterns.
What we chose for an EKS migration, and why
The engagement in our GitOps case study started from a legacy on-premises Kubernetes estate with Jenkins-based CI/CD, manual deployments, little visibility, and difficulty onboarding new teams into the pipeline. The target was AWS EKS provisioned with Terraform, GitHub Actions for CI, and GitOps for delivery.
We picked Argo CD with Helm, for reasons that follow directly from the table:
- Visibility was the pain. Manual deployments and "where is it running?" were the client's complaints; the Argo CD UI gave every team the same picture of dev, staging and production without a CLI lesson.
- Onboarding new teams was a stated goal. Argo CD projects with RBAC let us give each team its repos and namespaces and nothing else.
- Versioned environments. Applications were refactored into Helm charts and Argo CD synced them per environment with health checks, which is what made the phased migration — low-risk services first, mission-critical last — observable at every step.
- Jenkins was being replaced anyway. CI moved to GitHub Actions (matrix tests, Dockerised builds with cache, quality checks, artifact publishing); Argo CD only had to own the deployment side, which kept the two halves cleanly separated.
Outcomes, as published in the case study: deployment time down from hours to minutes, 100 % of deployments through GitOps, auditable releases, and a zero-downtime cutover for production services.
Would Flux have worked? Yes. For a single platform team with no appetite for a UI and a need for automated image bumps, we would have leaned the other way. The decision is not about which tool is "better"; it is about who will be looking at it on a Tuesday afternoon.
Moving from Jenkins-driven deployments to GitOps — what to expect
Whichever tool you pick, the migration pattern that worked for us:
- Separate CI from CD first. Build, test and publish artifacts in CI (GitHub Actions, GitLab CI, Jenkins — it doesn't matter); stop CI from running
kubectl apply. - Package applications as Helm charts or Kustomize overlays with one source of truth per environment.
- Bootstrap the GitOps controller on a fresh cluster (we provision EKS with Terraform and install the controller from the same repo) and point it at an empty environment.
- Migrate by risk, not by team: stateless, low-traffic services first; data-bearing and customer-facing services last, with a rollback path at every step.
- Make drift visible before you make it automatic. Run in "detect only" mode for a sprint, fix the sources of drift, then turn on self-heal.
- Give people the view they need — the UI for Argo CD, dashboards and alerts for Flux — before you switch off the old way.
If you want this done with you or for you — on EKS, with Terraform, GitHub Actions and either controller — that is the core of our DevOps practice and of DevOps as a Service.
Frequently asked questions
Can I run Argo CD and Flux together? Yes, and some platforms do during a migration or by team preference, but each controller must own distinct resources; two reconcilers fighting over the same Deployment is the classic failure. Pick one per cluster in the long run.
Which is more secure? Both pull from Git and keep cluster credentials out of CI, which is the main security win. Argo CD adds its own SSO/RBAC layer and API that you must secure and patch; Flux has no extra API surface and relies on Kubernetes RBAC. Neither is "more secure" in general — the Argo CD surface is a cost you pay for the console.
Does either work with EKS specifically? Both run on EKS without special handling. Use IAM roles for service accounts for any AWS access the controllers need (ECR, Secrets Manager, KMS) and keep the controllers' own credentials out of Git.
Do we need Argo Rollouts or Flagger from day one? No. Get plain sync-and-rollback working across environments first. Progressive delivery is the second step and both ecosystems add it without changing the base install.
Based on the projects' public documentation and on our own EKS delivery work. Argo CD and Flux are CNCF projects; feature details change between releases — verify against the versions you deploy.