Flux’s defaults differ from tools that wait for a manual sync. A Flux Kustomization applies on a schedule and corrects drift every time it runs. What you control is how often, what gets deleted, when to wait for health, and when to pause. This guide walks through each switch using the webapp Kustomization from the previous guide.

Intervals: how often Flux looks and applies

Two intervals control timing, and they are independent:

• The GitRepository interval decides how often Git is polled for new commits.
• The Kustomization interval decides how often the manifests are re-applied and drift is corrected, even if Git hasn’t changed.

spec:
  interval: 10m
  retryInterval: 2m

retryInterval is how long to wait before retrying after a failed reconciliation. To react immediately rather than wait, trigger a reconcile by hand while testing:

flux reconcile kustomization webapp --with-source

--with-source refreshes the Git source first and then applies it. For production, configure a webhook so Git pushes trigger a reconcile without frequent polling (see the notifications guide).

Add pruning

By default, Flux creates and updates resources but does not delete anything. If you rename or remove a manifest in Git, the old object stays in the cluster. Opt in to deletion:

spec:
  prune: true

To try it, rename the Deployment in apps/webapp/deployment.yaml from webapp to webapp-v2, commit, and reconcile. Flux creates the new Deployment and removes the old one. Flux tracks the objects it applied through an inventory, so it only ever deletes things it created. Pruning deletes real objects, so turn it on deliberately and be careful with resources that hold state.

To protect one object from pruning, annotate it in the manifest:

metadata:
  annotations:
    kustomize.toolkit.fluxcd.io/prune: disabled

Drift correction

Every time the Kustomization reconciles, it applies the desired state from Git again, so manual changes are reverted. Test it:

kubectl scale deployment webapp-v2 -n webapp --replicas=5
flux reconcile kustomization webapp
kubectl get pods -n webapp

Flux reverts the Deployment to the two replicas declared in Git. There is no separate “self-heal” switch to flip. That behavior is the default, and it is what keeps Git the only source of truth.

If you need to make a temporary change by hand, for example while debugging, pause Flux first (next section). If one object should be managed outside Flux, annotate it in Git:

metadata:
  annotations:
    kustomize.toolkit.fluxcd.io/reconcile: disabled

Recent Flux releases (2.9) also add server-side apply field ignore rules, which let you tell Flux to leave specific fields alone, such as a replica count managed by an autoscaler. See the Kustomization reference for the exact syntax for your version.

Wait for health and order your deployments

By default Flux reports success once the API server accepts the manifests. Setting wait: true makes it wait until the resources are ready, and timeout bounds the wait:

spec:
  wait: true
  timeout: 2m

Use dependsOn to make one Kustomization wait for another, for example to install an ingress controller before the applications that need it:

spec:
  dependsOn:
    - name: infrastructure

The dependency must be Ready before this Kustomization starts reconciling.

Suspend and resume

To pause reconciliation without deleting anything:

flux suspend kustomization webapp
# make manual changes, debug, then:
flux resume kustomization webapp

While suspended, Flux ignores the object, and manual changes stay in place. Resuming triggers a reconcile that brings the cluster back in line with Git, so don’t forget to resume. Suspending is the Flux equivalent of turning automation off for an environment.

Roll back safely

Flux has no rollback command for Kustomizations, because Git is the history. To undo a bad change:

git revert <bad-commit>
git push
flux reconcile kustomization webapp --with-source

Flux converges the cluster to the reverted state, and Git keeps an honest record of what happened. For emergencies where you need the cluster to stop moving first, suspend the Kustomization, fix things, push the revert, then resume.

Helm releases are different: the helm-controller can roll back a failed upgrade automatically, which the Helm guide covers.

Keeping production deliberate

Because automation is on by default, production gating happens in Git rather than in a “manual sync” button. Common patterns:

• Protect the production branch and require pull request approval.
• Point the production GitRepository at a tag or semver range (ref.tag or ref.semver) so production only changes when you cut a release.
• Use flux suspend during change freezes.