Kubernetes Argo CD Application Generator
Build an Argo CD Application with the options that are off by default turned on deliberately: pruning, self-healing, namespace creation and the finalizer that makes a delete actually delete. Each one is explained beside the output.
application.yaml
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Expecting sync to prune removed resources
Prune is off by default, so a resource deleted from Git stays in the cluster indefinitely and drifts silently.
Instead:Set syncPolicy.automated.prune: true once you trust the repository.
Leaving selfHeal off and wondering why drift persists
Without it, a manual kubectl edit stays applied and Argo reports OutOfSync forever without correcting it.
Instead:Enable selfHeal, and accept that manual edits will be reverted.
Pointing targetRevision at HEAD
Every commit to the branch deploys immediately, including ones that were not meant for this environment.
Instead:Pin a tag or a specific revision for production.
The Argo CD defaults that are the opposite of what people assume
An Application is a short manifest and most of its interesting behaviour is off unless you turn it on. Nothing warns you, because none of these are errors: they are a system doing exactly what it was configured to do, which happens not to be what anyone expected.
The Application lives in Argo CD's namespace
Not in the namespace it deploys to. Argo CD watches its own namespace for Application objects, and one created anywhere else is stored by the API server without complaint and never reconciled. There is no error, no event and no entry in the UI, because as far as Argo CD is concerned the object does not exist.
metadata:
name: api
namespace: argocd <- where Argo CD runs
spec:
destination:
namespace: production <- where the app goes
# these are different namespaces and the first one is
# the one that decides whether anything happens at all.prune is false, so deleting from git deletes nothing
Removing a manifest from the repository does not remove the resource from the cluster. It keeps running, and the Application still reports Synced, because Argo CD compares what git declares against what exists and a resource git no longer mentions is simply not compared. Orphaned Services, PVCs and LoadBalancers build up this way for months.
syncPolicy:
automated:
prune: true <- not the default
# without it:
# delete service.yaml from git
# -> Application: Synced, Healthy
# -> the Service, and its cloud load balancer,
# are still there and still billedselfHeal is false, so a manual edit sticks
Without it, a kubectl edit against a managed resource is not reverted. The Application reads OutOfSync, which on most dashboards is a colour rather than a page. So a fix applied by hand at 3am quietly becomes the running configuration until someone syncs, at which point it disappears with no warning and the incident repeats.
selfHeal: false (default)
kubectl edit deploy/api -> change persists
Application status -> OutOfSync
next manual sync -> silently reverted
selfHeal: true
the change is reverted within a couple of minutes,
which is the point, and it means emergency fixes
must go through git.Without the finalizer, deleting the Application orphans everything
Deleting an Application deletes the Application. Every Deployment, Service, PVC and cloud load balancer it created keeps running, unmanaged, with nothing pointing at them any more. The cascade only happens if the finalizer is present, and it has to be there before the delete, not added afterwards.
metadata:
finalizers:
- resources-finalizer.argocd.argoproj.io
# with it: delete the Application -> resources go
# without it: delete the Application -> resources stay,
# now owned by nobody and invisible to
# every GitOps dashboard you haveSynced is not Healthy, and alerting on the wrong one is common
Synced means the cluster matches git. That is all it means. A sync that applies perfectly is Synced even if every pod then crash-loops on startup, because the manifests were written successfully. Health is a separate status computed from the resources themselves, and a pipeline that gates on Synced reports a successful deploy for a completely broken release.
argocd app get api
Health Status: Degraded
Sync Status: Synced <- both are true
# Synced = the YAML in the cluster matches the YAML
# in git
# Healthy = the things that YAML created are working