How to Implement GitOps with ArgoCD

GitOps treats a Git repository as the authoritative source of truth for what should be running in a cluster — instead of applying changes with kubectl or helm directly, you commit changes to Git and let a controller reconcile the cluster to match. ArgoCD is one of the most widely used tools implementing this pattern.

Step 1: install ArgoCD into the cluster

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Step 2: access the ArgoCD UI

kubectl port-forward svc/argocd-server -n argocd 8080:443

Open https://localhost:8080 — the initial admin password is auto-generated and retrievable from a Kubernetes secret:

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

Step 3: prepare a Git repository describing your desired cluster state

myapp-gitops-repo/
  manifests/
    deployment.yaml
    service.yaml

This can be plain Kubernetes YAML, a Helm chart, or Kustomize overlays — ArgoCD supports all three as sources of truth.

Step 4: define an ArgoCD Application pointing at that repository

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/you/myapp-gitops-repo
    path: manifests
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: myapp
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

automated.selfHeal: true is the core of GitOps in practice: if someone manually changes something in the cluster directly (via kubectl edit, for instance), ArgoCD detects the drift from Git and automatically reverts it back to match what’s committed.

Step 5: apply the Application resource

kubectl apply -f myapp-application.yaml

Step 6: watch ArgoCD sync the cluster to match Git

ArgoCD UI → Applications → myapp → observe sync status

The UI shows a live diff between what’s currently running and what Git declares should be running, along with the sync status — healthy, out of sync, or actively syncing.

Step 7: deploy a change by committing to Git, not by running kubectl

# edit manifests/deployment.yaml, changing the image tag
git commit -am "bump myapp to v1.1.0"
git push

ArgoCD detects the new commit and automatically applies the change to the cluster (or waits for manual sync approval, if automated sync is disabled) — deployment becomes “merge this pull request,” not “someone runs a command against production.”

Step 8: roll back by reverting the Git commit

git revert HEAD
git push

Because the cluster’s state is defined entirely by what’s in Git, rolling back a bad deploy is exactly as simple as reverting the commit that caused it — ArgoCD’s self-healing sync then restores the previous state automatically.

Why “Git as source of truth” is a meaningfully different model, not just automation

Traditional CI/CD pipelines push changes to a cluster by running commands against it; GitOps inverts this — a controller running inside the cluster continuously pulls from Git and reconciles differences. This means every change to production has an inherent audit trail (Git history), rollback is a Git operation rather than a separate manual procedure, and drift — someone making an unreviewed manual change directly against the cluster — gets automatically detected and corrected rather than silently persisting until someone happens to notice.