Images, Tags, Digests and Registries
Know how images are built from manifests, configs and layers, why tags move and digests don't, and how multi-platform images, registries and base-image choices behave in production.
Key points
- 1
An image is a manifest that references a config blob and ordered layer blobs, all by SHA-256 digest. Identical content always has the same digest, which is how layers are shared and deduplicated.
- 2
Tags are mutable pointers. Deploy immutable per-build tags or, better, pin
name@sha256:…; when a reference has both a tag and a digest, the digest wins. - 3
Multi-platform tags point to an image index. Each host picks its own platform;
--platformoverrides that, and an index digest pins every platform at once. - 4
Short names normalise to
docker.io/library/NAME:latest. A first component containing.or:, orlocalhost, names a registry host. - 5
docker save/loadkeep layers, config and tags;docker export/importproduce one flat layer with no config.docker runpulls only when the image is missing locally. - 6
Docker Hub limits pulls per 6 hours, counting anonymous pulls per IP and multi-arch pulls per architecture. Authenticate, use a mirror or pull-through cache, or copy base images into your own registry.
- 7
Base image choice is a trade-off: Alpine is tiny but uses musl; debian-slim and distroless use glibc; distroless and scratch drop the shell entirely.
Common traps
latestis just a tag name. It is neither the newest image nor guaranteed to stay the same.Deleting a tag or manifest doesn't free registry storage until garbage collection runs, and lifecycle rules can delete untagged manifests your deploys still pin.
A glibc binary on Alpine fails with "no such file or directory" even though the file exists: the missing file is the dynamic loader.
Read the source
Test yourself on Images, Tags, Digests and Registries
Ten questions, with the answer and explanation after each one.