As someone who’s spent countless hours staring at kubectl describe pod and debugging strange deployment behavior, I’ll say this bluntly:
If you're using
:latestin production, you're asking for chaos.
It might feel harmless — even smart — during development. After all, why not always run the most recent version of your container image? Isn’t that the whole point of CI/CD?
No. Not in Kubernetes. Not if you care about stability, traceability, and sanity.
Here’s why pinning your image versions is not just a best practice — it’s a survival tactic.
Developers love :latest because it seems to guarantee freshness. But Kubernetes doesn’t know what “latest” means. Docker does — sometimes. And even that depends on your image cache.
If you run this:
image: my-app:latest
Then:
latest.Congratulations — your deployment is now running multiple, unknown versions of your app.
Let’s say your new release had a critical bug. You execute:
kubectl rollout undo deployment my-app
But... your pods still crash. Why?
Because :latest always refers to the newest pushed image — not the one that was running before. Kubernetes can’t revert to something it can’t identify.
With pinned tags (like my-app:2.4.1), rollback is deterministic. With :latest, it’s a guessing game.
Imagine you're investigating a production bug. Your logs show weird behavior, but your local tests pass. You ask:
If you used :latest, the answer is likely "We don't know."
Now contrast that with:
image: my-app:2.4.1
You immediately know:
And you can spin up a test pod that matches production byte-for-byte.
latest Gone WildAt one client, a staging environment used the Bitnami redis:latest image for testing. One morning, tests started failing. CI pipelines hung. Metrics were missing.
Turns out:
Staging was broken for two days while they investigated. The fix? Replace :latest with a pinned version like redis:6.2.6-debian-10-r33.
Lesson learned — the hard way.
Kubernetes embraces the idea of declarative infrastructure: your manifests should define the exact state you want. When you deploy my-app:2.4.1, you declare your intent precisely.
Using :latest breaks that contract. You’ve now handed control to Docker Hub (or whoever built your image) to decide what runs in your cluster.
In production systems, reproducibility is non-negotiable. Your audit logs, compliance checks, and postmortems depend on it.
Always tag images with immutable, unique versions, preferably derived from your Git commit or semantic versioning.
docker build -t my-app:2.4.1 . docker push my-app:2.4.1
Pin those tags in your Kubernetes manifests, Helm charts, or Kustomize overlays.
image: my-app:2.4.1
Avoid reusing tags like latest, stable, or release. Even v1 can be dangerous if overwritten.
Use image digests (@sha256:...) if you want to ensure absolute immutability.
The :latest tag is a tempting shortcut — but in Kubernetes, it becomes a liability. It undermines the very principles Kubernetes is built on: predictability, reproducibility, and control.
If you care about uptime, traceability, and your team’s sanity during incidents, pin your images.
Because in production, “we think it’s running the latest” is not good enough.