Argo CD’s defaults are conservative: it detects differences but won’t change your cluster on its own. Each behavior that makes it fully automatic is an explicit opt-in, which lets you choose different levels of automation per environment. This guide walks through each switch using the webapp-dev application from the previous guide.

Manual vs automated sync

An Application with no syncPolicy.automated block is manual. Argo CD compares Git against the cluster and marks the application OutOfSync when they differ, but nothing is applied until someone clicks Sync in the UI or runs argocd app sync.

Many teams use automated sync for dev and test environments and keep production manual, so a person approves each production rollout until the team trusts the pipeline.

Turn on automated sync

Add an automated block to the application’s syncPolicy:

spec:
  syncPolicy:
    automated: {}

With this, any new commit that changes the desired state is applied without a click. Two details about timing:

• Argo CD detects new commits by polling the repository, every three minutes by default. This is independent of sync policy. The policy only decides whether a detected difference gets applied.
• To react immediately, configure a webhook from your Git host to Argo CD’s /api/webhook endpoint, or press Refresh in the UI while testing.

Add pruning

By default, automated sync will create and update resources but will not delete anything. If you rename or remove a manifest in Git, the old object stays in the cluster and the application shows OutOfSync because of the leftover. Opt in to deletion:

spec:
  syncPolicy:
    automated:
      prune: true

To try it, rename the Deployment in dev/deployment.yaml from webapp to webapp-v2 and commit. Argo CD creates the new Deployment and removes the old one. For a manual sync, you can prune once with argocd app sync webapp-dev --prune, or tick Prune in the sync dialog. Pruning deletes real objects, so turn it on deliberately, and be careful with resources that hold state.

Add self-heal

Automated sync reacts to changes in Git. Self-heal also reacts to changes in the cluster:

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Test it by making a manual change that Git doesn’t know about:

kubectl scale deployment webapp-v2 -n webapp --replicas=5
kubectl get pods -n webapp -w

Extra Pods start, then Argo CD reverts the Deployment to the two replicas declared in Git. That’s the point: Git stays the only source of truth. If your team isn’t ready for manual changes to be reverted automatically, leave selfHeal off. Argo CD will still show the application as OutOfSync, so the drift stays visible. Add notifications if you want to be told.

Roll back safely

To get back to an earlier deployed state, open the application’s History and Rollback view, pick a previous revision, and roll back. The CLI equivalents are:

argocd app history webapp-dev
argocd app rollback webapp-dev <ID>

Rollback requires automated sync to be off. Otherwise Argo CD would immediately re-sync the app to the newest commit and undo the rollback. Disable it first with argocd app set webapp-dev --sync-policy none. After a rollback the application is OutOfSync, because Git is ahead of what’s running. Treat rollback as an emergency lever, not the fix. The durable fix is to git revert the bad commit, push it, and then re-enable automated sync so Git and the cluster agree again.