In a Dockerfile's FROM instruction, what is the difference between referencing a base image by tag (for example ubuntu:24.04) and by digest (image@sha256:...), and when does each matter?

## Tags are pointers, not versions In an OCI registry, a repository holds content-addressed blobs and manifests. A tag is a mutable name that points at one manifest digest. Pushing again with the same tag simply repoints it. This is not an abuse of the system; it is how distributions ship patches: ubuntu:24.04 is rebuilt regularly so that consumers pulling that tag get current security fixes. :latest carries no special meaning to the registry at all; it is merely the tag used when none is specified. The consequence is that FROM ubuntu:24.04 is not a reproducible instruction. The same Dockerfile, the same source tree, and the same build command can produce two different images on two different days, because the base moved. That is usually good (you inherit fixes) and occasionally terrible (a base change breaks your build or silently alters behaviour, and you cannot reconstruct the image that shipped last Tuesday). ## Digests are content addresses A digest reference is repository@sha256:<hex>, where the hex is the SHA-256 of the image manifest bytes. The manifest in turn lists the config blob and layer blobs by their own digests. Because the hash covers the manifest, and the manifest covers everything else, a digest uniquely and verifiably identifies exact image content. The client recomputes the hash on pull, so a registry cannot serve you different bytes under that digest without detection. Docker also supports the combined form FROM ubuntu:24.04@sha256:abc..., which is the best of both: the tag documents intent for a human reader, and the digest is what actually resolves. Multi-stage builds can also digest-pin each stage's base independently. ## Multi-arch nuance For multi-platform images the tag usually points at an image index (manifest list) that enumerates per-platform manifests. Pinning the index digest keeps multi-arch behaviour: the client still selects the right platform entry. Pinning a single platform-specific manifest digest instead locks the build to that one architecture, which is a common accident when people copy a digest out of a registry UI on an amd64 laptop and then break arm64 builds. ## Choosing a policy Use tags when you want an unattended stream of upstream patches and reproducibility does not matter much: local development, exploratory work, images rebuilt constantly anyway. Use digests when the build must be reproducible or auditable: release pipelines, regulated environments, anything where you sign images or produce an SBOM and must be able to say precisely what shipped. Digest pinning also removes a real supply-chain vector, where an attacker with push access moves a tag to malicious content and every downstream build inherits it on the next rebuild. The standard failure mode of digest pinning is staleness. A digest never gets a CVE fix; it is frozen by definition. So a pinning policy without an automated bump process trades a small risk (surprise upstream change) for a larger one (running a base image with known unpatched vulnerabilities for a year). Renovate and Dependabot both understand Dockerfile digest pins and will open pull requests that update the digest and the accompanying tag comment, which lets the change go through code review and CI like any other dependency bump. A related distinction worth stating in an interview: pinning affects resolution, not caching. The BuildKit cache may reuse layers, but the base reference is resolved against the registry; with a mutable tag, whether you pick up a new base depends on cache state and on whether the build pulls. That indeterminism is exactly what digest pinning removes.