Containers from Scratch
Dockerfile & layer caching
Lesson 2 of 5
What you'll learn
- Read a Dockerfile as an ordered stack of layers
- Understand how the build cache reuses unchanged layers
- Know why COPYing source late keeps dependency installs cached
A Dockerfile is an ordered list of instructions. Each instruction produces one layer, and Docker caches the result. On a rebuild, Docker walks the instructions top to bottom and reuses a cached layer only if that step and every step before it are unchanged.
FROM node:20-alpine # layer 1
WORKDIR /app # layer 2
COPY package*.json ./ # layer 3 (rarely changes)
RUN npm ci # layer 4 (expensive!)
COPY . . # layer 5 (changes every edit)
CMD ["node", "server.js"] # layer 6
Order for cache hits
The trick: copy package.json and install dependencies before copying the rest of your source. Editing application code only invalidates layer 5 onward — npm ci stays cached. Flip the order (COPY . . before the install) and every code edit busts the expensive install.
Once a layer is invalidated, every layer after it rebuilds too, because each builds on the previous one.
Cache busting cascades downward
Changing one instruction never affects layers above it, but always rebuilds the ones below. That's why the most frequently changing inputs (your source code) belong near the bottom.
Run it. Given which step changed, see which layers hit the cache and which rebuild. Try changing the changedStep index.
Next: where data goes when a container's writable layer disappears.
Sign in to save your progress across devices.