3.1.2 Image Layers
A focused guide to Image Layers, connecting core concepts with practical Docker and container operations.
Image layers are the individual, ordered filesystem changes that together make up an image, each one produced by a specific instruction in a Dockerfile, stacked so that later layers can add, modify, or remove files introduced by earlier ones.
Each Instruction Produces a Layer
Most instructions in a Dockerfile that touch the filesystem — RUN, COPY, ADD — produce a new layer when the image is built, while instructions that only set metadata, such as ENV or CMD, do not add filesystem content.
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y curl
COPY app.py /app/app.py
CMD ["python3", "/app/app.py"]
docker history myapp:1.0
The docker history output lists each layer-producing instruction along with the size it added, making it possible to see exactly which step contributed how much to the final image.
Layers Are Identified by Content
Each layer is identified by a cryptographic digest of its content, which is what allows identical layers from different images to be recognized as the same and stored only once.
docker inspect myapp:1.0 --format '{{json .RootFS.Layers}}'
Why Layer Count and Size Matter
Every layer adds some overhead to the image, both in terms of storage metadata and in terms of how many distinct filesystem operations must be reconciled when the layers are combined — consolidating related changes into fewer, more meaningful layers, rather than producing many tiny ones, often produces a more efficient image.
RUN apt-get update && apt-get install -y curl wget && rm -rf /var/lib/apt/lists/*
Combining related package installation and cleanup into a single RUN instruction produces one layer reflecting the net result, rather than separate layers for installation and a later, separate cleanup step that would not actually reduce the image's size since earlier layers remain unchanged.
Why Image Layers Matter
Understanding that an image is fundamentally a sequence of layers — not a single, opaque blob — explains both how Docker builds and caches images efficiently, and why certain Dockerfile authoring practices (ordering instructions by how often they change, combining related operations) meaningfully affect build speed and final image size.