ArgoCD

What is ArgoCD?

ArgoCD inverts traditional deployment. Instead of a CI pipeline pushing changes into Kubernetes with kubectl and cluster credentials, ArgoCD runs inside the cluster and continuously pulls: it watches a Git repository containing your manifests (or Helm/Kustomize definitions), diffs them against live cluster state, and syncs the difference. Git becomes the single source of truth; a deployment is a merged pull request.

Why pull-based GitOps won

Three properties teams discover they can’t live without. Drift detection: someone kubectl-edits production at 2 a.m., and ArgoCD flags (or auto-reverts) the divergence — silent drift is the root cause of “works in staging” mysteries. Auditable rollback: every deploy is a commit; rollback is git revert, and the release history is the Git log. Credential inversion: CI systems no longer hold cluster-admin secrets — a meaningful win, since CI is a top attack target.

The parts that bite

Sync isn’t sequencing: apps needing ordered rollout (migrations before app pods) require sync waves and hooks, which teams learn about mid-incident. Secrets don’t belong in Git, so you’ll adopt a companion (External Secrets, Sealed Secrets) on day one. And the app-of-apps pattern that scales ArgoCD to hundreds of services also concentrates blast radius — a bad change to the root app is a fleet-wide event.

What people get wrong

• Auto-sync everywhere immediately. Start with manual sync on production; graduate to auto-sync with pruning once drift alerts are boring.
• Treating ArgoCD as CI. It deploys what Git says; building, testing, and writing the new image tag into Git is still your CI/CD pipeline’s job.
• Ignoring its own availability — when the deploy tool lives in the cluster, cluster-wide outages can take your rollback path down with them; keep a documented kubectl escape hatch.

Primary source: ArgoCD official documentation