Argo CD or Flux?

If you run Kubernetes and deploy with GitOps, you've almost certainly met this question. Argo CD and Flux are both graduated CNCF projects, both mature, both used by thousands of companies. Both will deploy your apps from Git reliably.

It's not about which one is better. It's about which one matches how your team works.

GitOps in one paragraph

GitOps means Git is the source of truth for what runs in your cluster. Instead of a pipeline pushing changes with kubectl apply, an agent inside the cluster pulls the desired state from Git and continuously makes the cluster match it. Every change is a commit. Every rollback is a revert. Drift gets corrected automatically. The OpenGitOps project sums it up in four principles: declarative, versioned and immutable, pulled automatically, continuously reconciled.

Argo CD in short

Argo CD is an application-centric GitOps tool with a strong web UI.

• The UI is a big selling point. You see every application, its resources, their health and their sync status as a live tree. Developers love being able to click into their app and see what's happening.
• Applications and ApplicationSets. An Application points at a Git path and a target cluster. ApplicationSets generate many Applications from templates: one per cluster, per environment, per pull request.
• Multi-cluster from a central instance. One Argo CD can manage many clusters.
• Projects and RBAC for multi-team setups, with SSO integration.
• Argo CD 3.x brought cleaner defaults and better performance, and the wider Argo family includes Argo Rollouts for progressive delivery and Argo Workflows.

Flux in short

Flux is a collection of Kubernetes controllers that work like native Kubernetes components.

• Everything is a CRD. GitRepository, OCIRepository, Kustomization, HelmRelease. You manage Flux the same way you manage everything else.
• No UI by default. Flux is CLI and API first. There are third-party UIs and integrations, but the experience is built around kubectl and the flux CLI.
• Strong Helm support through the Helm controller, with automated upgrades, tests and rollbacks.
• OCI artifacts as a source: you can push manifests to a container registry and have Flux pull from there.
• Image automation controllers can update image tags in Git automatically when new images are pushed.
• Lightweight, per-cluster model. Usually each cluster runs its own Flux and pulls its own config.

Argo CD shows you GitOps. Flux disappears into Kubernetes. Both are valid ways to love it.

Side by side

	Argo CD	Flux
Interface	Rich web UI plus CLI	CLI and CRDs, UI optional
Typical model	Central instance, many clusters	Agent per cluster
Multi-tenancy	Projects, RBAC, SSO in the UI	Kubernetes RBAC and namespaces
Helm	Renders charts into manifests	Native Helm releases via controller
Learning curve	Easy to start, UI helps	Very Kubernetes-native, steeper for beginners
Best fit	Teams wanting visibility and self-service	Platform teams wanting composable automation

How I structure the repos

Whichever tool you pick, repository structure matters more than the tool. A common layout:

platform-gitops/
  clusters/
    prod-eu/
    prod-us/
    staging/
  infrastructure/      # cert-manager, gateway, monitoring, policies
    base/
    overlays/
  apps/
    shop/
      base/
      overlays/
        staging/
        prod/

Some principles that help:

• Separate app code from deployment config. The app repo builds images; the GitOps repo says which version runs where.
• Use overlays (Kustomize) or values files (Helm) per environment, not copied folders.
• Keep secrets out of Git, or encrypted (SOPS) or referenced via External Secrets.

Moving changes through environments

The tricky part of GitOps isn't deploying. It's promotion: moving a version from dev to staging to production in a controlled way. Updating a YAML file in three places by hand gets old quickly.

Options:

• Pull requests per environment, opened by CI after each successful stage.
• Flux image automation or Argo CD Image Updater for automatic tag updates in lower environments.
• Kargo, a newer project from the Argo ecosystem team, built specifically for GitOps promotion across stages with verification steps in between.

So, which one?

If your developers will interact with deployments directly and value seeing what's going on, Argo CD. If your platform team wants composable, Kubernetes-native building blocks and is happy with CLIs, Flux. If you can't decide: try both on a test cluster for a week. The one your team reaches for naturally is the right one.

My take: the best GitOps tool is the one your team actually understands. Pick one, structure your repos well, and the rest follows.

— Desly