A routine pull can revive stale production code

Teams often talk about latest as though it were a version.

It is not.

It is only a naming convention around a deployment policy.

That policy may be safe, disciplined, and current.

It may also be months behind reality.

Treating the tag itself as trustworthy is how a routine pull turns into a rollback nobody intended.

We have seen the shape of that failure clearly enough to stop calling it theoretical.

One production service regained an older registry image during a routine pull while CI publishing was down, and features that had already been working in production quietly disappeared for hours.

Nothing about the tag warned the operator.

The damage came from trusting a label that described freshness socially, not cryptographically.

A familiar tag can hide stale state #

Operators like short names because release windows are already carrying enough moving parts.

latest feels practical.

It suggests the most recent build, the image the team probably means, the state that should be safe to refresh onto another machine.

That suggestion is the trap.

The tag only tells you what some earlier process wrote to the registry.

If the publishing path is paused, billing-blocked, broken, or pointed at the wrong repository, the tag can remain unchanged while local production builds keep moving ahead.

At that point the label is still called latest, but the operational meaning has drifted.

It no longer means current production candidate.

It means whatever image was last pushed successfully, which may be old enough to reintroduce bugs, remove fixes, or erase new release behavior that never existed in the registry copy.

This is why the word latest causes so much confusion.

It sounds like a fact about version order when it is really a statement about publishing discipline.

When the discipline breaks, the word keeps lying with a straight face.

Pulling can be a rollback in disguise #

Many operators still think of docker compose pull as a refresh command.

Get the newest image.

Stay current.

Reduce drift.

That logic only holds if the registry is the source of truth for the service you are about to restart.

If production has been running a locally built image that is newer than the registry copy, a pull is not a refresh.

It is a rollback.

The danger is that it does not announce itself as one.

The command succeeds.

Containers restart.

Health checks may even pass.

Only later does someone notice that recent behavior vanished, because the image you just trusted was older than the machine state you replaced.

That is a painful category of incident because the action feels routine and the regression can look mysterious.

People start hunting for bad merges, bad cache state, or environmental drift when the simpler explanation is that the deployment path silently chose an older artifact.

The fix is not only procedural caution.

It is a clearer understanding that pull behavior depends entirely on where trusted provenance lives.

Provenance should beat convenience #

A strong deployment process answers one narrow question before any restart begins: what exact artifact are we about to trust.

Not what tag feels familiar.

Not what command the team normally runs.

What artifact, built from what source, published through what path, with what proof that it is the image we intend to run now.

There are several acceptable ways to answer that question.

Use immutable digests.

Build directly on the target host from synced source.

Record a source identity beside the deploy.

Keep rollback instructions tied to the previously running image.

What matters is not which mechanism you choose.

What matters is that the mechanism defeats the ambiguity that tags introduce.

Convenience commands become dangerous when they hide the trust decision.

The operator thinks they are doing maintenance.

In reality they are choosing an artifact.

Once you see that clearly, image provenance stops looking like a fussy platform concern and starts looking like ordinary release safety.

Recovery gets easier when source identity stays visible #

The hardest part of a stale-image incident is often not the repair.

It is the confusion during the first investigation.

Why did this feature disappear.

Which artifact is actually running.

Did the deployment path rebuild from local source, restart an existing local image, or replace it with a registry copy.

Those questions get answered much faster when the deploy record keeps the source identity visible.

Commit, path scope, artifact hash, and rollback target are not paperwork.

They are the difference between a ten-minute diagnosis and hours of false theories.

This is why we care about deployment receipts as much as deployment commands.

If the system can say source identity was this, running image is this, previous image was that, and rollback command is here, recovery becomes narrower and calmer.

If the system only says deployed latest successfully, it has preserved the least trustworthy part of the story.

The label is not the guarantee #

At Stack Dispatch we care about this because deployment reliability depends on naming the real trust boundary.

Latest can still exist as a convenience tag.

What it cannot safely be is the only answer to what version is running.

The guarantee must come from provenance: source identity, artifact identity, and a deployment path the team actually understands.

The moment an operator treats latest as a version rather than a policy, the system becomes easier to roll back by accident.

That is the wrong kind of simplicity.

Use the short tag if you want.

Just do not confuse it for evidence.