The container changed by itself: what the "latest" tag actually promises

You updated nothing. You restarted the container and now it behaves differently: a setting is gone, an interface changed, an add-on stopped working. This is not a fault. latest is not a version, it is a pointer, and you do not decide what it points at.

What the tag actually promises

latest does not mean "the newest stable release". It means "whatever the publisher pushed last". Some publishers put the stable release there, others put a development build. You cannot tell the difference from the tag.

Three consequences follow, and you meet all three in daily life.

Same file, different result. Two machines can hold an identical configuration file and run different versions, because they pulled at different times. That is usually where "works on mine" comes from.

You do not choose when the change happens. The container updates whenever it is recreated. On the night you restarted it because a disk filled up, you may have skipped a version without noticing.

When it breaks, you cannot go back. This is the heaviest one. If you do not know where you came from, you cannot return there. All you are left with is the sentence "it worked yesterday".

The point is not the new version, it is being able to return

Pinning a version is not "being cautious". Pinning creates a point to return to. In a pinned setup an upgrade is a decision you made, and every decision you make can be undone.

The cost is plain: now you have to do the update yourself. That was the whole idea.

A tag can be moved, a fingerprint cannot

A tag can be moved to something else by the publisher. So what you pulled as 1.2 yesterday could in theory differ from what you pull as 1.2 today. If you truly mean "exactly this", pin the image's fingerprint rather than the tag. It looks long and ugly, but it is the only mark that cannot be moved.

For most setups, pinning to a version number is enough. The fingerprint is for the cases where you must reproduce the very same thing years later.

The honest counter-argument

"If I pin, I will miss security fixes." True, if you pin and forget. Pinning is not a strategy on its own, it is half of a habit; the other half is reading release notes regularly. Pinning and forgetting is worse than staying on latest, because you fall behind and do not know that you have.

The test is simple: ask yourself when you last upgraded this container. If you have no answer, the problem is not pinning, it is your calendar.

The safety net on the Proxmox side

The container sits inside a virtual machine or a container. That gives you something the container world does not: taking a snapshot before the upgrade. If the upgrade goes badly, you rewind not the container but the machine underneath it.

This does not replace pinning, but it also covers the things you did not pin. The order worth turning into a habit is: snapshot first, then upgrade, then check that it really works.

What Atlas does

When you paste a configuration file into Atlas, it reads the file before running it. Images without a pinned version, meaning those that say latest or carry no tag at all, are marked as a warning.

That is deliberately a warning, not a block. Pinning is a preference and the preference is yours; the product's job is not to make the decision but to make it visible. The genuinely dangerous ones, such as handing the server's own control socket to a container or mounting the server's root directory, are marked in a different colour and a different language.

One detail matters: this reading happens on the server side. So bypassing the interface and sending the file directly does not remove the warning. A warning that lives only on the screen is not a warning.