CoursesFluxIntermediate

Image automation

Auto-bump images back to Git.

Advanced14 min · lesson 7 of 12

Flux can automate image updates end to end with three image controllers. The image-reflector scans a registry and records the available tags. The image-policy selects the desired tag by a rule (semver range, numeric ordering, a regex/filter). The image-automation controller then writes the chosen tag back into your Git manifests as a commit. So a new image build results in a Git commit updating the deployment — the update stays a GitOps change, fully auditable and revertible.

IMAGE AUTOMATION PIPELINE
1image-reflector
scans registry, records available tags
2image-policy
selects tag by semver/filter rule
3image-automation
writes chosen tag into Git as a commit
4Flux reconciles
commit deploys the new image
The image bump lands as an auditable, revertible Git commit - not a direct cluster change.
imagepolicy + marker
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
spec:
imageRepositoryRef: { name: payments }
policy: { semver: { range: ">=1.4.0 <2.0.0" } }
---
# in the deployment manifest, a marker tells Flux what to update:
# image: registry.internal/payments:1.4.0 # {"$imagepolicy": "flux-system:payments"}

Update via commit, and its guardrails

Because the update is a commit to Git, everything downstream (review, verification, reconcile) still applies — you can require the automation to commit to a branch that a human merges, or let it commit straight to the deploy branch for hands-off delivery. Scope the policy tightly (a semver range that excludes majors, or only patch bumps) so automation never rolls a breaking version. It is the Flux answer to Argo CD Image Updater: keep image bumps declarative and in Git.

imageupdateautomation.yaml
spec:
interval: 30m
sourceRef: { kind: GitRepository, name: fleet }
git:
commit: { author: { name: fluxbot, email: flux@acme } }
push: { branch: image-updates } # commit to a branch a human merges (safer)
update: { path: ./apps, strategy: Setters }
A loose image policy auto-deploys whatever the registry serves
Image automation is only as safe as its policy and its push target: a wide semver range plus a push straight to the deploy branch means any new image the registry gets is auto-deployed to prod. Constrain policies (patch/minor, not majors), prefer pushing to a branch that is reviewed and merged, and combine with source verification and admission policy so an unexpected image still meets a gate before it runs.