Container Images Are Stacked Deltas

WHY IT EXISTS: Shipping applications with all their dependencies used to mean copying entire filesystems or heavy virtual machine images. That wastes bandwidth and disk space because most applications share common foundations like operating system libraries. Container image layers were invented to solve this by capturing only the differences between steps and allowing those differences to be reused across many applications.

THE MENTAL MODEL: Imagine a stack of overhead transparency sheets. Each sheet is read-only and shows only what changed at that step. The bottom sheet might be a minimal Ubuntu filesystem. The next sheet adds Python. The next adds your source code. When you run a container, you place one final blank sheet on top; this is the writable container layer where logs and temp files go. To the process inside, the stack looks like one coherent filesystem, but nothing below the top sheet can actually be altered.

HOW IT WORKS: A Dockerfile instruction like RUN, COPY, or ADD creates a new layer. The build engine executes the instruction, compares the resulting filesystem to the previous state, and stores just the delta as a tarball and a JSON metadata file. These layers are content-addressed by a digest, so identical layers are stored once on disk even if multiple images reference them. During a docker pull, the client checks which layer digests it already has and downloads only the missing ones. At runtime, the container engine uses a union filesystem or overlay driver to merge all layers into a single mount point, with the writable layer capturing any new or modified files.

WHEN TO USE IT: Leverage layers to speed up CI pipelines by ordering Dockerfile instructions from least frequent change to most frequent change. Put dependency installation before code copies so that changing a single line of source does not invalidate the cached dependency layer. Use slim shared base images so that every application on a host can reuse the same underlying OS layers, saving gigabytes of disk.

WHEN NOT TO USE IT: Do not treat layers as a versioning system for artifacts. Do not assume that removing a secret or a large file in a later layer erases it from the image; the data remains in the earlier layer and is trivial to extract. Do not create excessive layers by chaining dozens of RUN commands, because each layer adds metadata overhead and can slow down the union mount.

ONE CANONICAL EXAMPLE: A typical Python application Dockerfile starts with FROM python:3.11-slim, which might consist of multiple base layers totaling hundreds of megabytes. The next instruction, COPY requirements.txt /app followed by RUN pip install, creates a new layer containing only the installed packages. Finally, COPY . /app adds the application code. If you change a single Python file and rebuild, Docker reuses the heavy base and dependency layers from cache and rebuilds only the thin code layer. The resulting push or pull transfers just that small delta.