15. When to use Argo CD, and when not

Argo CD is very good at a specific job. This chapter is about whether that job is yours, and it argues both directions.

What it is genuinely good at

Continuous reconciliation of Kubernetes resources against git. Nothing else does this as well, and the “continuous” part — not deployment, but the constant comparison — is the durable value.

Multi-cluster deployment. One definition, many clusters, with the cluster generator making new clusters self-populating.

Visibility. The resource tree in the UI, showing an Application owning a Deployment owning a ReplicaSet owning pods with live health, is genuinely the best view of a Kubernetes application in any tool. This is underrated and it is a large part of why teams adopt Argo CD over alternatives that are technically equivalent.

Removing production credentials from CI. The security argument from chapter 1 is real and has only got stronger.

Cluster bootstrap. A new cluster plus one Application becomes a fully configured environment.

What it is bad at

Anything not a Kubernetes resource. No cloud infrastructure, no DNS, no database schemas — unless you have an operator that turns them into Kubernetes resources, which is what Crossplane does and which brings its own trade-offs.

Imperative sequences. “Drain the queue, then migrate, then deploy, then backfill” is a workflow, not a desired state. Sync waves and hooks approximate it and get uncomfortable quickly. That is Argo Workflows’ job, or a pipeline’s.

Fast feedback loops. A developer iterating on a service does not want a commit-and-wait cycle. They want skaffold dev or tilt. Argo CD in a developer inner loop is friction with no benefit.

Secrets. Deliberately (chapter 12).

Ephemeral, high-churn environments. The PR generator works, and hundreds of short-lived Applications churning is real load on the controller.

Argo CD versus Flux

The only serious alternative, also a CNCF graduated project, also good. The choice is more about shape than capability.

	Argo CD	Flux
Model	one controller, one CRD (Application)	several controllers, several CRDs (GitRepository, Kustomization, HelmRelease, ImagePolicy)
UI	excellent, built in	none official (Weave GitOps, or Headlamp)
Multi-tenancy	AppProjects + Argo RBAC	Kubernetes RBAC + namespaces
Multi-cluster	one instance, many clusters	typically one Flux per cluster
Helm	helm template only	real Helm releases, with rollback
Image automation	separate Image Updater	built in and better
Notifications	built in	built in
Composability	monolithic	modular — use only what you need
Learning curve	gentler	steeper; more concepts up front

The honest summary:

Choose Argo CD if you want a UI, if non-platform engineers will look at deployment state, if you are managing many clusters from one place, or if you want the smallest number of concepts to learn.

Choose Flux if you prefer Kubernetes-native composition over a bespoke RBAC system, if you want image automation as a first-class feature rather than a bolt-on, if you want real Helm releases, or if you want a controller-per-concern architecture you can adopt piecemeal.

The UI is a bigger factor than engineers expect. “The team can see what is deployed without asking anyone” changes how an organisation works, and it is the most common reason Argo CD is chosen over Flux even when Flux fits better technically. That is not a bad reason.

Using both is possible and pointless. Pick one.

Argo CD versus pushing from CI

The comparison from chapter 1, now with the counter-argument.

	CI pushes	Argo CD pulls
Cluster credentials	in CI	in the cluster
Drift detection	none	continuous
Rollback	re-run a pipeline	git revert
Deployment speed	fast, direct	commit → sync
New cluster	CI needs a route in	cluster pulls
Debugging a deploy	pipeline logs	Argo CD UI + logs
Conceptual overhead	low	a whole system to learn
Imperative steps	natural	awkward

Pushing from CI is fine, and the industry has been slightly unfair to it. For a single cluster, one team, straightforward deployments, and a CI system you trust, kubectl apply in a pipeline is a legitimate architecture that a lot of successful software ships with.

The case for switching gets strong when: more than one cluster, more than a few teams, audit requirements, or you have been bitten by drift. That last one is the usual trigger — someone changed something by hand, nobody knew, and an incident took three hours to diagnose.

Argo CD versus Terraform

They look like they overlap and mostly they do not.

	Terraform	Argo CD
Manages	cloud infrastructure	Kubernetes resources
Model	plan then apply	continuous reconciliation
State	an explicit state file	the cluster itself
Runs	when invoked	always
Drift	detected on the next plan	detected in seconds
Rollback	apply an older config	git revert

The clean division most teams settle on:

   TERRAFORM: the cloud account, VPC, the cluster
              itself, IAM, managed databases,
              DNS zones, and Argo CD's initial install

   ARGO CD:   everything inside the cluster

The boundary case is Kubernetes resources managed by Terraform’s kubernetes provider. Avoid it. Terraform’s state file is a second source of truth about the cluster, and its plan/apply model fits badly with a system whose controllers are continuously changing the objects — you get perpetual diffs and a state file that is wrong between runs. Use Terraform to create the cluster and install Argo CD; use Argo CD for what runs in it.

Crossplane inverts this — cloud infrastructure as Kubernetes resources, reconciled by Argo CD. It is genuinely interesting and it means your cloud infrastructure now depends on a Kubernetes cluster being healthy, which is a dependency direction worth thinking about carefully before adopting.

The honest costs of GitOps

Stated plainly, because the marketing does not.

Deployment is slower. Commit, push, wait for a sync. With a webhook that is seconds, but the process — a PR, a review — is where the time goes, and that is often deliberate.

Debugging has an extra layer. “Why is this not deployed?” now has three possible answers: the manifest is wrong, Argo CD has not seen it, or the sync failed. Chapter 14’s diagnosis order exists because this is genuinely more confusing than reading pipeline logs.

Emergency changes are harder. Self-heal reverts a manual fix. There is a procedure (chapter 14), and someone has to know it at 3 a.m.

You must learn a system. Applications, projects, waves, hooks, health, diffs, ApplicationSets. That is a real cost for a small team.

Secrets need a separate answer. Chapter 12, and it is not optional.

The image-tag question gets awkward. Something must write to git, and every option has a downside (chapter 12).

Argo CD becomes critical infrastructure. It holds credentials to every cluster it manages. It needs upgrades, monitoring, backups of a sort. You have added a system whose compromise is severe.

None of these is decisive. All of them are real, and a team of four running one cluster may reasonably decide the pipeline they have is fine.

The recommendation

   ONE cluster, ONE small team, no audit requirement?
     → CI pushing is fine. Revisit when it hurts.

   MULTIPLE clusters, or multiple teams, or you have
   been bitten by drift?
     → Argo CD (or Flux). This is the sweet spot.

   Want a UI, and non-platform people will look at it?
     → Argo CD.

   Prefer Kubernetes-native composition, want strong
   image automation, one Flux per cluster?
     → Flux.

   Managing cloud infrastructure?
     → Terraform. Not Argo CD, and not Terraform's
       kubernetes provider either.

   Need imperative multi-step orchestration?
     → a workflow engine. Argo CD's hooks are not it.

   Developer inner loop?
     → Skaffold or Tilt. Argo CD is friction here.

The argument in one paragraph

Argo CD’s real contribution is not deployment — plenty of things deploy. It is making “what is running” a question with a reliable answer, continuously, without anyone investigating. That property is worth more than it sounds, it compounds as an organisation grows, and it is difficult to get any other way. The cost is a system to learn and operate, a slower path from idea to production, and a new piece of critical infrastructure holding credentials to everything. For most organisations past the smallest scale, that is a good trade. For the smallest scale, honestly, it is not, and being told otherwise by every conference talk does not make it so.

What to take from this chapter

• Good at: continuous reconciliation, multi-cluster, visibility, removing production credentials from CI, cluster bootstrap.
• Bad at: non-Kubernetes resources, imperative sequences, developer inner loops, secrets, high-churn ephemeral environments.
• Flux is a genuine peer. Argo CD for a UI, one instance across many clusters, and a gentler learning curve; Flux for Kubernetes-native composition, real Helm releases, and better image automation. The UI is the most common deciding factor, and that is a legitimate reason.
• Pushing from CI is a legitimate architecture for one cluster and one team. Switch when you have multiple clusters, multiple teams, audit requirements, or a drift incident behind you.
• Terraform for the cluster, Argo CD for what runs in it. Avoid Terraform’s kubernetes provider — a second source of truth that is wrong between runs.
• The costs are real: slower deployment, an extra debugging layer, harder emergency changes, a system to learn, secrets needing a separate answer, and a new piece of critical infrastructure holding credentials to everything.
• The durable value is “what is running” becoming a question with a reliable answer, continuously, without investigation.

Next: the cheat sheet — commands, annotations, settings and procedures on one page.