How Docker layer caching works and how to exploit it
layer cache invalidation, cache-busting, dependency layer trick, cache ordering, build performance, --no-cache flag
Layer Caching Is Your Biggest Build-Speed Lever
Docker caches each layer. On rebuild, it reuses cached layers until it detects a change. Once any layer is invalidated, all subsequent layers must rebuild — even if their content is identical.
The Dependency Layer Trick
This is the single most impactful Dockerfile optimization:
# BAD — source changes invalidate the npm install layer
COPY . .
RUN npm ci
# GOOD — npm install is cached unless package.json changes
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
By copying only the manifest first and running install before copying source, you get a cached install layer on every rebuild where only code (not dependencies) changed. A full project rebuild drops from 45 seconds to 3 seconds.
What Invalidates a Cache Layer
Any of these bust the cache for that layer and all layers below it: the instruction text changed, a COPY or ADD source file changed (Docker checksums files), or --no-cache was passed to docker build.
# Force a clean rebuild ignoring all cache
docker build --no-cache -t myapp .
Always order Dockerfile instructions from least-frequently-changing to most-frequently-changing: base image → system packages → dependency install → app source copy → startup command.