# Argo CD vs Flux on EKS — decision matrix

Both are CNCF-graduated, pure-GitOps tools: Git is the single source of truth,
a controller continuously reconciles cluster state to the repo, and drift is
corrected automatically. AWS's own Prescriptive Guidance says both handle most
GitOps scenarios capably — so this is a fit decision, not a "which is better."

> Reflects the mid-2026 model and AWS Prescriptive Guidance "Argo CD and Flux
> use cases." Confirm current feature support in each project's upstream docs.

| Criterion | Lean **Argo CD** | Lean **Flux** |
|-----------|------------------|---------------|
| You want a **visual UI / app dashboard** | Yes (first-class app-of-apps UI) | No (CLI-first; UI via third parties) |
| **Application-centric** model (devs think in "apps") | Yes | Component/Kustomization-centric |
| **Multi-cluster** from one control plane | Strong (hub-and-spoke, ApplicationSets) | Possible, more assembly |
| **Enterprise RBAC / SSO** out of the box | Strong | Lighter; relies more on K8s RBAC |
| **Lightweight, CLI-driven, modular** | Heavier | Yes (composable controllers) |
| **Automated image updates** | Add-on | Built-in image automation controllers |
| **Multi-tenancy** by repo/namespace | Workable | Strong native story |
| **Helm + Kustomize** | Both | Both (Helm via HelmRelease) |
| Already standardized on one across teams | Use it | Use it |

## Quick read

- Pick **Argo CD** when you want a UI, an application-centric mental model,
  strong multi-cluster from a central control plane, and built-in RBAC/SSO for a
  larger org. EKS also exposes a native Argo CD capability with cluster
  registration and Application manifests.
- Pick **Flux** when you want a lightweight, CLI/GitOps-native, modular
  controller set with strong multi-tenancy and built-in image automation, and
  you don't need a bundled UI.
- **Don't run both** for the same workloads. Two reconcilers fighting over the
  same manifests is a drift incident waiting to happen.

## The decisions that actually bite (independent of tool)

1. **Secrets do not go in Git.** Use External Secrets Operator backed by AWS
   Secrets Manager (or SOPS + KMS, or Sealed Secrets). Plaintext secrets in the
   GitOps repo is the #1 mistake.
2. **Pod identity for AWS access.** Use EKS Pod Identity / IRSA so the GitOps
   controller and workloads get scoped IAM, not long-lived keys.
3. **App-of-Apps (or ApplicationSets) for fleet scale.** A root app that points
   at child apps is how you bootstrap many apps/clusters without click-ops. See
   `app-of-apps-example.yaml`.
4. **Decide repo topology up front.** Mono-repo vs per-team repos, and
   environment-per-branch vs environment-per-directory. Changing it later is
   painful.
5. **Reconcile vs CI boundary.** CI builds and pushes the image + opens a PR that
   bumps the tag; the GitOps controller deploys on merge. CI should not run
   `kubectl apply` — that defeats GitOps and reintroduces drift.

## When GitOps is the wrong call

- A single tiny cluster with one app and one operator: GitOps overhead may
  exceed its benefit. A reviewed Helm/CD pipeline is fine.
- Workloads needing imperative, ordered, human-in-the-loop runbook steps (some
  stateful migrations) don't map cleanly to pure reconcile loops — keep those on
  a controlled pipeline.