Rebuild a Docker image without instruction cache

Use --no-cache to avoid reusing cached instruction results for the requested build. Add --pull when you also want the builder to check for newer referenced images:

docker build --no-cache --pull -t myapp:1.2 .

These options address different layers of reuse. They do not turn a mutable dependency graph into a reproducible build, and a digest-pinned base image still identifies the same content.

Use the same distinction with Compose

docker compose build --no-cache --pull app
docker compose up -d --no-build app

Replace app with the service that has a build definition. Review whether its image pull policy also needs adjustment in your setup. Building does not update an already running container; the following up applies the resulting service configuration and image.

Avoid immediately requesting an unnecessary second build with up --build when the intended fresh build has already succeeded.

Invalidate one part of a build

For a deliberately refreshable step, declare and use a build argument at the relevant point:

ARG CACHEBUST=1
RUN echo "Dependency refresh: ${CACHEBUST}" \
    && ./scripts/install-dependencies.sh

The script must already be present and executable. Then:

docker build --build-arg CACHEBUST="$(date +%s)" -t myapp:1.2 .

A changed ARG affects the cache where the value is used, not simply because its declaration exists. Subsequent RUN instructions can use in-scope arguments through their environment; the explicit use above makes the intended boundary clear. Prefer pinned dependencies over timestamp-based refreshes when reproducibility is the goal.

With Buildx, docker buildx build --no-cache-filter STAGE ... can target a named stage. Check the installed builder's options and selected target rather than treating this as a flag accepted identically by every historical Docker CLI.

Know what may still be reused

BuildKit cache mounts, such as a package-manager download cache mounted with RUN --mount=type=cache, can persist even when instruction results are bypassed. Registry storage and package proxies can also reuse downloads. --no-cache means the relevant instructions run again; it is not a request to erase every cache in the toolchain.

To reclaim builder storage, inspect the selected builder and use docker builder prune or the corresponding Buildx command. -a broadens pruning to unused cache, not cache actively needed by every running build. Pruning is separate from running a build without cache.

FAQ

When is a fresh build useful?

When diagnosing stale package results, missing build inputs, or differences hidden by a warm local cache. It is also one useful validation step before a release, but it does not prove every dependency is fixed or available offline.

Why is the result still old?

Check the actual context, .dockerignore, pinned versions, build arguments, selected stage, base image reference, and the image used by the running container. The build may be correct while the deployment still uses an older image.

Is slower execution expected?

Yes. Steps normally reused from cache must run again. Retain normal caching for routine development unless a specific reason calls for bypassing it.

See cache invalidation and Buildx build options.