Optimizing Dockerfile layer caching
how layer caching invalidation works.
order instructions least-to-most volatile, copy dependency manifests and install before copying source, and understand any changed layer busts all later layers.
What's really being asked
This checks whether you understand Docker's layered build cache: every instruction produces a layer, and changing one instruction invalidates its cache and all subsequent layers.
The full answer
The fix is ordering instructions from least to most frequently changing. Copy the dependency manifest first, for example package.json and lockfile or requirements.txt, run the install step, and only then COPY the rest of the source. Because the manifest rarely changes, the expensive install layer stays cached across code edits, and only the cheap final COPY and build layers rerun. Add a dockerignore to keep noisy files out of the build context so they do not bust the cache. For modern builds, BuildKit cache mounts persist package-manager caches across builds even when a layer rebuilds. Multi-stage builds keep build tooling out of the final image.
The mistakes people make
Putting COPY . . before the install command, so any code change invalidates the install layer and forces a full reinstall. Pinning nothing and assuming the cache helps anyway. Forgetting dockerignore, so changing a log file invalidates the build context.
What usually comes next
What exactly invalidates a COPY layer? How do cache mounts differ from layers? How does cache behave in CI with ephemeral runners? What is the effect of ARG on caching?
A concrete example
A Node service originally did COPY . . then RUN npm install, so editing one line in app.js triggered a fresh npm install of hundreds of packages. Reorder to COPY package.json package-lock.json ./, then RUN npm ci, then COPY . ., then RUN npm run build. Now an app.js edit only invalidates the final COPY and build layers; npm ci is served from cache and the rebuild drops from minutes to seconds.
Interview question
Why does copying the full source before installing dependencies hurt build caching when only one code line changes?
- a.Docker disables caching whenever COPY is used
- b.The changed source busts the COPY layer, invalidating the later install layer tooCorrect
- c.npm and pip refuse to use cached packages after a COPY
- d.Layer caching only works for the final image, not intermediate steps
Why? this is the answer
A changed layer invalidates itself and every subsequent layer, so installing after copying source forces a reinstall. Caching is not disabled by COPY (A) and does apply to intermediate layers (D).
Just read this? Test yourself on what you have been reading.
Read the original → docs.docker.com
- #docker
- #dockerfile
- #build-cache
- #performance
- #ci
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles