What causes cache busting in Docker builds, and how do you avoid it?
Learn what causes Docker build cache invalidation and how to reorder Dockerfiles and pin images to keep builds fast.
Expected Interview Answer
Cache busting happens when a Dockerfile instruction’s cache key changes unexpectedly — usually because an earlier layer’s content changed, the instruction itself changed, or a build argument varies — forcing Docker to invalidate that layer and every layer after it, even when the actual work being done is functionally identical.
Docker’s layer cache is sequential: it walks the Dockerfile top to bottom, and the moment one instruction’s cache key does not match the previous build, every instruction from that point onward must re-execute, regardless of whether those later steps would have produced the same result. The most common cause is copying source code before installing dependencies, so any code change invalidates the dependency-install layer even though the dependencies themselves did not change; the fix is copying only the dependency manifest (`package.json`, `requirements.txt`, `go.mod`) first, running the install, and copying the rest of the source afterward. Another frequent cause is using a floating base image tag like `latest` or `node:20`, which can silently point to a different underlying image on rebuild day, invalidating everything downstream — pinning to a specific digest or immutable tag avoids that. `ADD` with a remote URL, `RUN apt-get update` without pinning package versions, and build arguments that change on every invocation (like embedding a timestamp) are other classic cache-busters, since BuildKit treats a changed `ARG` value as a new cache key for every instruction that references it afterward. Multi-stage builds and `RUN --mount=type=cache` for package-manager directories both help by isolating volatile steps from stable ones and by persisting reusable cache state outside the layer graph entirely.
- Keeps CI/CD pipeline build times low by maximizing cache reuse
- Prevents unnecessary re-downloads of dependencies on every commit
- Improves developer inner-loop speed for local iterative builds
- Reduces registry bandwidth and storage churn from unnecessarily rebuilt layers
AI Mentor Explanation
Cache busting is like a groundskeeper who insists on redoing the entire pitch preparation from bare soil just because the boundary rope was moved slightly — even though the pitch itself needed no changes. If the crew instead separated "prepare the pitch" from "position the boundary rope" as independent later steps, moving the rope would never force redoing the pitch. Using an unpinned "whatever grass seed is in stock today" instead of a specific certified batch is another way an unrelated supply change can silently force a full re-prep. Smart groundstaff order their tasks so a change late in the process, like the rope, never cascades back to redoing early, stable work like the pitch itself.
Step-by-Step Explanation
Step 1
Identify the volatile instruction
Find which Dockerfile instruction changes on nearly every build — usually a COPY of source code or a floating tag.
Step 2
Reorder stable steps earlier
Move dependency manifests and installs before the volatile COPY so they stay cached across code changes.
Step 3
Pin base images and versions
Use a specific digest or immutable tag instead of `latest`, and pin package versions in install commands.
Step 4
Isolate volatile data with mounts or multi-stage
Use RUN --mount=type=cache for package caches and multi-stage builds to keep unstable steps from invalidating stable ones.
What Interviewer Expects
- Understanding that cache invalidation cascades forward from the first changed instruction
- Knowing the classic fix: manifest COPY + install before full source COPY
- Awareness that floating tags like `latest` are a common, subtle cache-busting source
- Familiarity with ARG-triggered cache invalidation and cache mounts as mitigation
Common Mistakes
- Copying the entire source tree before running dependency installation
- Using `FROM node:latest` instead of a pinned tag or digest, causing silent invalidation
- Embedding a timestamp or build number as an early ARG that busts cache for every later instruction
- Not realizing that even a single unchanged instruction after a busted layer still has to re-run
Best Answer (HR Friendly)
“Cache busting is when one small change in our Dockerfile accidentally forces Docker to redo way more work than necessary, because the build cache only works in order — once one step changes, everything after it has to rerun too. The fix we apply is ordering our Dockerfile so the things that rarely change, like installing dependencies, happen before the things that change on every commit, like copying our source code, so a normal code change only busts the small last layer instead of the whole build.”
Code Example
# Cache-busting version: any source change reinstalls all dependencies
# COPY . .
# RUN npm ci --production
# Cache-friendly version: dependency layer only busts when the manifest changes
FROM node:20.11.1-alpine3.19
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --production
COPY . .
CMD ["node", "server.js"]
# Pin the base image by digest for maximum reproducibility
# FROM node@sha256:1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2bFollow-up Questions
- Why does using `FROM node:latest` risk unpredictable cache invalidation?
- How does an ARG value affect cache keys for instructions that reference it?
- How would you use a multi-stage build to isolate a volatile compile step from a stable base?
- What is the tradeoff of pinning every dependency to an exact version for cache stability?
MCQ Practice
1. What is the most common cause of unnecessary cache busting in a Dockerfile?
Copying the whole source tree before installing dependencies means any code change invalidates the dependency-install layer too.
2. Once a Dockerfile instruction's cache is invalidated, what happens to later instructions?
Docker's layer cache is sequential: once one layer's cache is busted, every subsequent instruction must re-execute.
3. Why is pinning a base image to a specific digest safer for cache stability than using `latest`?
A floating tag like `latest` can change what it points to between builds, causing an unexpected, silent cache invalidation cascade.
Flash Cards
What is cache busting in a Docker build? — When an early layer's cache key changes, forcing that layer and all subsequent layers to re-execute.
Classic fix for source-code cache busting? — COPY the dependency manifest and install first, then COPY the rest of the source code afterward.
Why avoid `FROM image:latest`? — A floating tag can silently point to a different image, invalidating the cache unpredictably.
What does a cache mount help with? — Persists a package-manager cache directory across builds without bloating the final image or being part of the layer graph.