What does `docker build --pull` do, and why can a nightly rebuild still ship an outdated base image?

## The default that surprises people When the builder reads `FROM debian:12-slim`, it needs bytes for that reference. It looks in the Docker daemon's local image store first. If an image tagged `debian:12-slim` is already there — pulled once, weeks or months ago, on a self-hosted CI runner or a developer laptop — those are the bytes the build uses, and the registry is never consulted. That single fact explains most reports of the shape "we rebuild every night and the image scanner still reports the same findings". ## What a tag actually is A tag is a **mutable pointer** inside a repository: a human-readable name that currently resolves to one manifest digest. Base-image maintainers rebuild their images regularly with patched OS packages and move the tag to the new manifest. The bytes behind `debian:12-slim` in March are not the bytes behind it in June, even though the string never changed. Nothing pushes that change to you; a client only learns the pointer moved by asking the registry. ## What `--pull` does `docker build --pull` instructs the builder to always attempt to pull a newer version of every image referenced by the build — the `FROM` of each stage, and any `COPY --from=<image>` that names an external image. If the tag now resolves to a different digest, the new manifest and its layers are fetched and become what the build uses. Nothing else changes: the per-instruction build cache still applies, so a build where the base has not moved is a normal fast build. It is a freshness switch, not a "rebuild everything" switch. ## What `--no-cache` does, and does not do `--no-cache` disables reuse of previously built layers for the instructions in your Dockerfile: every `RUN`, `COPY` and `ADD` executes again. It does **not** re-resolve the base image. A build with `--no-cache` and no `--pull` faithfully re-runs your whole Dockerfile on top of the same outdated base — the most expensive way to produce the same vulnerable image. The two flags are orthogonal and are often used together in a scheduled rebuild. ## When the FROM is pinned to a digest If the Dockerfile says `FROM debian:12-slim@sha256:...`, the reference is content-addressed: that digest can only ever mean those exact bytes. `--pull` then degenerates into a fetch-if-missing plus an integrity check — it cannot make the base newer. Freshness for a digest-pinned base comes from something editing the Dockerfile to a newer digest, typically an automated update pull request. Pinning buys you reproducibility and pays for it with a refresh path you now have to own. ## Where this bites in practice A payments reconciliation batch ships as a C++ daemon with a fat runtime-shared-library layer, roughly a 2.3 GB image, rebuilt nightly on a self-hosted runner with a persistent Docker daemon. The runner pulled `debian:12-slim` 63 days ago. Every nightly build reuses it, so an image scanner keeps reporting the same 41 critical findings and the team concludes the scanner is broken. Adding `--pull` to the build resolves the tag to the current, rebuilt base, and the same scan drops to 6 findings — none of the Dockerfile changed. The classic builder and BuildKit differ in the details of when they re-check a tag, which is exactly why CI pipelines pass `--pull` explicitly rather than relying on a default they cannot see. Ephemeral runners that start with an empty image store hide the problem, because there is nothing local to reuse; the moment you add a cache or a persistent host to speed builds up, the problem appears. ## The habit to build A scheduled rebuild that exists to pick up base-image fixes should say so in its command line: pull the base, and verify afterwards which base you actually got. `docker image inspect --format '{{index .RepoDigests 0}}' debian:12-slim` on the build host tells you the digest that was used, and comparing it week to week is a cheap check that the refresh is real rather than assumed.