ArgoCD: GitOps with a Dashboard You Might Actually Use

I came to GitOps grudgingly. The pitch — “Git is the single source of truth, the cluster reconciles itself to match” — sounded like the kind of slogan that survives precisely one production incident. Then I tried to debug a drifting Kubernetes cluster the old way, kubectl apply-ing manifests by hand and trying to remember which of three engineers had hotfixed what, and I came round. ArgoCD is the tool that converted me, mostly because of one thing the others don’t do nearly as well: it shows you the state of the world.

1 What ArgoCD does

ArgoCD is a Kubernetes controller that continuously compares the live state of your cluster against the desired state declared in a Git repo. When they differ, it tells you the resources are OutOfSync, and — depending on your policy — either waits for you to click “Sync” or reconciles automatically. The desired state can be plain YAML, Helm charts, Kustomize overlays, or Jsonnet. You point it at a repo and a path, and it owns that slice of the cluster.

You declare an application as a custom resource, which is itself something you can keep in Git (the “app of apps” pattern):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web-frontend
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/infra.git
    targetRevision: main
    path: apps/web-frontend
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated:
      prune: true        # delete resources removed from Git
      selfHeal: true     # revert manual kubectl changes
    syncOptions:
      - CreateNamespace=true

selfHeal: true is the line that earns its keep. Someone kubectl edits a deployment at 2am to “just try something”? ArgoCD notices the drift and reverts it to match Git within seconds. Your cluster becomes genuinely declarative instead of a pile of accumulated manual changes nobody can reproduce.

2 The dashboard is the actual feature

Plenty of tools do reconciliation. Flux does it well and lives more comfortably in a pure-CLI workflow. What sets ArgoCD apart is that its dashboard is good — not the usual enterprise afterthought of a UI, but the primary way most people use it. You get a live tree view of every Application: the parent app, its deployments, the replica sets beneath them, the pods beneath those, all colour-coded by sync and health status. A red node anywhere in that tree tells you exactly where a rollout went wrong, and clicking it drops you straight into the events and logs.

When a sync is in flight you watch it happen — resources going from Progressing to Healthy in real time, sync waves applying in order, hooks firing. For anyone who’s ever stared at kubectl get pods hammering the up-arrow to refresh, this is a revelation. It also makes GitOps teachable; you can sit a sceptical colleague in front of it and the model becomes obvious in about ninety seconds.

You can drive the same thing from the CLI when you want automation:

$ argocd app sync web-frontend
TIMESTAMP   GROUP        KIND   NAMESPACE  NAME          STATUS    HEALTH
2025-08-11  apps   Deployment   web        web-frontend  Synced    Healthy
2025-08-11              Service  web        web-frontend  Synced    Healthy

$ argocd app get web-frontend
Health Status:  Healthy
Sync Status:    Synced to main (a3f9c21)

3 Sync waves, hooks, and the bits that bite

Real applications need ordering — run the database migration before the new app version, not after. ArgoCD handles this with sync waves, an annotation that groups resources into ordered phases:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"     # higher waves apply later
    argocd.argoproj.io/hook: PreSync       # run as a migration job

This works, but it’s the area where teams trip up most: get a wave number wrong and your app starts before its dependencies, fails its health check, and you’re back in the dashboard working out why. The other classic gotcha is prune: true with a misconfigured path — remove a directory carelessly and ArgoCD will dutifully delete the corresponding live resources because that’s exactly what you told it Git wanted. Respect the prune flag.

4 Verdict

Is ArgoCD worth it? If you’re running multiple environments or a team where more than one person touches the cluster, yes — the combination of self-healing, an auditable Git history of every change, and that genuinely useful dashboard is hard to give up once you have it. For a single-node homelab that one person manages, it’s arguably overkill; plain kubectl apply from a repo plus a cron job gets you most of the way with none of the controller to operate. The honest dividing line is team size and blast radius. The moment “who changed this and why” becomes a question you can’t answer from memory, ArgoCD pays for itself. The dashboard is the bit you’ll miss first if you ever leave.