4.3.2 Dockerfile Size Reduction
A focused guide to Dockerfile Size Reduction, connecting core concepts with practical Docker and container operations.
Dockerfile size reduction covers the techniques used to minimize a built image's overall size — choosing a smaller base, using multi-stage builds, combining and cleaning up within layers, and avoiding unnecessary installed content — each contributing to a leaner final artifact.
Choosing a Smaller Base Image
The base image alone sets a lower bound on the final image's size, making this one of the highest-leverage decisions for overall size reduction.
FROM python:3.12
FROM python:3.12-slim
Switching to the slim variant alone often produces a substantial size reduction with minimal other changes required.
Using Multi-Stage Builds to Drop Build Tooling
Separating build-time tooling from the final runtime image, copying only necessary build output across, typically produces the largest single size reduction for compiled or bundled applications.
FROM node:20 AS build
RUN npm install && npm run build
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
Combining and Cleaning Up Within Layers
Combining related operations into a single RUN instruction, and cleaning up temporary data within that same instruction, avoids layers that permanently carry size that a later, separate cleanup step cannot actually remove.
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
Avoiding Unnecessary Installed Content
Installing only what is actually needed, disabling package manager recommendations, and avoiding development tools in production images all contribute to a smaller final result.
RUN apt-get install -y --no-install-recommends curl
Measuring the Effect of Size Reduction Efforts
Comparing image size before and after applying these techniques provides direct, measurable confirmation of their actual impact.
docker images myapp
docker history myapp
Why Dockerfile Size Reduction Matters
A smaller image pulls faster, starts faster (in scenarios with cold layer caches), consumes less storage across every host and registry that stores it, and presents a smaller attack surface — benefits that compound significantly when an image is pulled and run frequently across a large infrastructure footprint.