Docker sold us on one promise: if it works on your machine, it works in production. That promise breaks the moment you use :latest.
Here’s exactly how it happened during a routine server reboot. A container was defined as image: mysql:latest. Ran perfectly for months. A security patch triggered an infrastructure restart. During docker compose up, Docker noticed the :latest pointer had changed upstream. It pulled MySQL 8.x and tried to map it over existing MySQL 5.7 data volumes.
The engine couldn’t read the tables. The app went down. A routine reboot turned into a recovery operation because of one mutable tag.
The reality is that using :latest is a gamble, not a versioning strategy. It’s a convenience for local testing and nothing more than a pointer that someone else controls. When you use it (or omit the tag, which defaults to it), you’re telling your infrastructure to accept whatever code happens to be newest at the exact millisecond you pull. You forfeit determinism. Your production environment becomes a function of when you last ran docker compose up, not of what you actually tested.
To avoid this, you need to pin everything. Every image in your Dockerfiles and Compose files should use an immutable SHA hash or a strictly pinned semantic version.
Instead of node:18, use node:18.17.1-alpine3.18. Instead of postgres:16, use postgres:16.4-bookworm. Yes, it means you have to manually bump versions and track CVEs. You can automate that with Renovate or Dependabot, but the update is still a deliberate decision, reviewed and applied by an engineer.
The principle is simple: updating an environment should be a conscious choice, not a surprise executed by a daemon during a reboot. Treat infrastructure dependencies as rigidly as you treat application dependencies. If you’d never run npm install --production without a lockfile, don’t run docker compose pull without pinned tags.