You need a container image build to genuinely re-fetch things rather than reuse cached layers — for example to pick up new upstream OS package versions. What options does the Docker CLI give you, and how do they differ from each other?

## Why you need an escape hatch at all The builder decides cache hits from keys, not from reality. A `RUN` step is matched on its command text, so `RUN apt-get update && apt-get install -y openssl` will keep reusing a months-old layer as long as its string and its parent are unchanged — even after an upstream security release. Nothing about the Dockerfile changed, so nothing rebuilds. Similarly `FROM node:22` is a *mutable tag*: the tag may now point at a new digest, but a builder that already resolved it will happily continue using the old image. So you need explicit ways to say 'ignore what you remember'. ## `--no-cache` `docker build --no-cache -t app .` disables cache lookups for the whole build: every instruction executes. It is the blunt instrument. Good uses: a scheduled (nightly/weekly) rebuild that picks up OS patches; reproducing a bug that only appears on cold builds; verifying that the Dockerfile still works from scratch — a `RUN` that depends on a file deleted from the repo can survive for weeks on a warm cache and then fail for a new contributor. Bad use: as the CI default 'to be safe'. It converts every build into a worst-case build, multiplies registry egress and pipeline minutes, and hides the ordering problems you should be fixing. ## `--pull` `--pull` forces re-resolution of every `FROM` reference against the registry. Without it, a builder that already has `python:3.12` locally will not check whether the tag moved. With it, you rebuild on top of today's base — which is precisely how you pick up base-image CVE fixes. `--pull` and `--no-cache` are orthogonal and frequently paired: `docker build --pull --no-cache` for a scheduled refresh. Note that if you pin `FROM python:3.12@sha256:…` by digest, `--pull` cannot change what you build on — an intentional tradeoff between reproducibility and automatic patching, usually resolved by a bot that bumps the pinned digest. ## `--no-cache-filter` BuildKit adds `--no-cache-filter=<stage>[,<stage>]`, which disables the cache only for named build stages. In a multi-stage Dockerfile you can force the `deps` stage to re-resolve dependencies while the expensive `toolchain` stage stays cached. It is the surgical version of `--no-cache` and is well worth knowing — most candidates only know the blunt flag. ## Cache-busting build arguments Because a referenced `ARG` is expanded into the `RUN` command string, it participates in the cache key: ``` ARG CACHEBUST=0 RUN echo "$CACHEBUST" && git clone --depth 1 https://example.com/repo.git ``` Passing `--build-arg CACHEBUST=$(date +%s)` changes the string, so that step and everything below it rebuild while everything above stays cached. This is the standard trick for a `git clone` or a `curl` of a moving artifact — steps whose text is constant but whose result is not. Two cautions. First, **placement is everything**: put the `ARG` immediately above the step that must re-run, because everything below it also rebuilds. Second, a build argument that changes every build — a commit SHA consumed at the top of the file — is an accidental cache-bust that silently destroys build times. Same mechanism, opposite intent. ## Fixing the Dockerfile instead Often the right answer to 'how do I force a rebuild' is 'stop needing to'. Fuse `apt-get update` with its `install` so they invalidate as one unit. Pin versions (`curl=8.5.0-2`) so the desired change is expressed as a text change and the cache does the right thing automatically. Prefer `ADD --checksum=sha256:…` for remote artifacts so a moved artifact is a loud failure rather than a silent stale hit. Cache correctness is mostly a Dockerfile-design problem; flags are for the residue. ## Clearing storage `docker builder prune` (or `docker buildx prune`, with `--all` and `--filter until=168h`) deletes cached build records to reclaim disk. That is a storage operation rather than a per-build flag, but it is the other way builds 'lose' their cache — and on a shared or long-lived builder, an aggressive GC policy explains mysterious cold builds. ## The summary to say out loud `--no-cache` = everything, `--pull` = base images, `--no-cache-filter` = chosen stages, a referenced `ARG` = from this instruction down. Reach for the narrowest one that solves the problem, and prefer changing the Dockerfile so the cache invalidates honestly.