By Vicente Arteaga Gomez
MisLinux · Last updated: April 20, 2026
This article is part 14 of my MisLinux series on Kubernetes on Hetzner. It reflects my own production experience with a self-hosted registry. I am not affiliated with Docker or any vendor mentioned here.
There is a version of latest that is harmless: the local development convenience tag you use while building or testing. That is not the version I am talking about.
The version I mean is latest as an operational contract in a real self-hosted registry, where storage pressure, cleanup policy, multi-architecture manifests, cached images, and historical provenance all matter.
In that world, latest is not a deployment strategy. It is a label sitting on top of a set of assumptions. If those assumptions are weak, the label becomes misleading very quickly.
What latest hides
The problem with latest is not that it points to a recent image. The problem is that it hides the answer to the question operators actually need:
> Which exact image, built from which exact inputs, is this workload supposed to be running?
That matters even more in a self-hosted registry because the registry itself is part of your operational surface. A tag is not an abstract truth. It is a mutable pointer living inside a system you also maintain.
When I depend too heavily on latest, I lose clarity around:
- provenance
- promotion order
- rollback path
- multi-arch descriptor protection
- what is actually safe to clean up
Why self-hosting makes this worse
Managed registries already make tag discipline important. Self-hosting raises the stakes because the registry can have its own incidents:
- storage pressure
- cleanup mistakes
- missing child manifests under multi-arch tags
- cached-vs-pullable mismatches
- broken rebuilds that do not become visible until the next node restart
If all of that sits behind a single mutable latest, the operator story gets weak fast.
What I use latest for now
I still use latest, but I treat it as a convenience pointer, not as the authoritative identity of the image.
The authoritative identity is one of:
- an immutable commit-derived tag
- a specific digest
- a clearly named staged/runtime promotion tag
latest can exist on top of that, but it should not be the only thing you know.
Why immutable tags matter more than pretty tags
In my environment, some build tags are ugly. They encode the source commits that went into the image. Operationally, that ugliness is a feature.
An immutable provenance tag answers questions latest cannot:
- what source state produced this image?
- is this the same thing I built yesterday or just something also called
latest? - can I rebuild or compare it safely?
- is this the tag I should preserve because a live workload still depends on its digest?
Pretty tags are easier to read. Immutable tags are easier to trust.
The promotion model I find safer
I prefer a layered tagging model:
| Tag type | Role |
|---|---|
| Immutable build tag | Exact provenance of one build |
| Stage/runtime tag | Operational promotion step with a concrete meaning |
latest | Convenience alias, never the only truth |
That structure lets me separate build identity from human-friendly promotion state.
It also makes rollback better. If a runtime tag is bad, I can see what it used to point to. If latest is the only visible identity, rollback becomes a memory exercise.
Why this matters even when Kubernetes pins digests
It is fair to say: if workloads are pinned by digest, why care about latest at all?
Because the operator still has to do all of this:
- inspect what new builds produced
- compare live digests to current tags
- rebuild missing pull paths
- clean up old manifests safely
- explain to another human what "the right image" means
Digest pinning helps. It does not replace a sane promotion vocabulary.
The cleanup angle most people miss
The registry cleanup story is another reason latest is not enough.
If a cleanup policy says "keep latest and the newest N tags," that sounds reasonable until you realize:
latestmay point to a multi-arch manifest list- child manifests may still need direct protection
- live workloads may still be running older digests
- the immutable provenance tag may be the only safe direct reference left
That is why I prefer cleanup logic based on reachability and deployment usage instead of only on visible tag names.
What changed in how I deploy
I think of image deployment in three questions now:
- what exact immutable build did I produce?
- what exact build did I promote to the intended runtime tag?
- what exact digest is the workload actually using?
If I cannot answer all three, then I am not really operating the image path deliberately. I am mostly trusting conventions to hold.
Final thought
latest is convenient, and convenience has its place. But convenience is not the same thing as a deployment strategy.
A deployment strategy needs provenance, promotion, rollback, and cleanup safety. In a self-hosted registry, those requirements are too important to hide behind one mutable tag and a hopeful mental model.
That is why I still keep latest around, but I no longer let it pretend to be more than it is.
