A tag is a movable pointer to an image, and one image can carry many tags. docker tag adds one without copying anything. When you leave the tag out, Docker 514 assumes latest, a name with no special meaning to the registry:
docker tag l3-layers:1.0 l3-layers:1
docker tag l3-layers:1.0 l3-layers:sha-7e7c388
docker image ls l3-layers
docker run --rm l3-layersIMAGE ID DISK USAGE CONTENT SIZE EXTRA l3-layers:1 effc91e93bde 54.9MB 24.8MB l3-layers:1.0 effc91e93bde 54.9MB 24.8MB l3-layers:sha-7e7c388 effc91e93bde 54.9MB 24.8MB Unable to find image 'l3-layers:latest' locally docker: Error response from daemon: pull access denied for l3-layers, repository does not exist ...
All three tags share one ID. docker run l3-layers asked for l3-layers:latest, which nobody created. When latest does exist, it points wherever the last push left it: two servers pulling at different times get different software, and "the previous latest" cannot be rolled back to, as Chainguard 179,813 's move to Node.js 26 2,131 (Choosing a Base Image) shows.
A practical scheme for BookNest:
Semantic version tags at three precisions, 1.4.2, 1.4 and 1, so users choose how much change to accept.
An immutable build tag from the Git 1,932 commit, sha-7e7c388, never reused, which links a running container back to its source.
A digest (@sha256:...) in production manifests when you need a guarantee rather than a convention; Kubernetes 5,150 (Kubernetes) and signature checks (Verifying Signatures) both work best with digests.
Pin base images the same way. FROM node:24-slim follows Node.js 24's security patches automatically, which is usually what you want; FROM node:24.21.0-slim@sha256:... makes a build fully reproducible, at the cost of updating the pin yourself, a job tools such as Renovate 22,612 and Dependabot 29 automate.