Why multi-stage builds reduce image size in Docker - Why It Works

Introduction

Docker images can become very large when they include all the tools and files needed to build an app. Multi-stage builds help by separating the build process from the final app image, keeping only what is needed to run the app and removing extra build tools.

When you want to keep your Docker images small to save disk space and speed up downloads.

When your app needs tools to build but those tools are not needed to run the app.

When you want to improve security by not including build tools in the final image.

When you want to speed up deployment by reducing image size.

When you want to keep your Dockerfile clean and organized by separating build and runtime steps.

Config File - Dockerfile

Dockerfile

FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

FROM alpine:3.18
WORKDIR /app
COPY --from=builder /app/myapp .
CMD ["./myapp"]

This Dockerfile has two stages:

• builder: Uses the golang image to compile the app. It includes all build tools.
• final: Uses a small alpine image and copies only the compiled app from the builder stage.

This way, the final image is small and contains only what is needed to run the app.

Commands

Builds the Docker image using the multi-stage Dockerfile. This compiles the app in the first stage and creates a small final image.

Terminal

docker build -t myapp:multi-stage .

Expected Output

[+] Building 10.5s (10/10) FINISHED

 => [builder 1/5] FROM docker.io/library/golang:1.20@sha256:...  0.0s

 => CACHED [builder 2/5] WORKDIR /app  0.0s

 => CACHED [builder 3/5] COPY . .  0.0s

 => [builder 4/5] RUN go build -o myapp  9.8s

 => [final 1/3] FROM docker.io/library/alpine:3.18@sha256:...  0.0s

 => CACHED [final 2/3] WORKDIR /app  0.0s

 => [final 3/3] COPY --from=builder /app/myapp .  0.1s

 => exporting to image  0.5s

 => => exporting layers  0.5s

 => => writing image sha256:...  0.0s

 => => naming to docker.io/library/myapp:multi-stage

Shows the size of the built image to verify it is smaller than a single-stage build.

Terminal

docker images myapp:multi-stage

Expected Output

REPOSITORY   TAG           IMAGE ID       CREATED          SIZE

myapp        multi-stage   abcdef123456   10 seconds ago   12MB

Runs the final small image to confirm the app works correctly without the build tools.

Terminal

docker run --rm myapp:multi-stage

Expected Output

Hello from myapp!

→

--rm - Automatically removes the container after it stops to keep the system clean

Key Concept

Multi-stage builds reduce image size by separating the build environment from the final runtime environment, copying only the necessary files to the final image.

Common Mistakes

Copying all source files directly into the final image instead of only the built app.

This keeps unnecessary build files and tools in the final image, making it large.

Use multi-stage builds to copy only the compiled app or runtime files from the build stage.

Not naming build stages and trying to copy from unnamed stages.

Docker cannot find the source files to copy, causing build errors.

Name the build stage with AS and use that name in COPY --from=stage.

Summary

Multi-stage builds use separate stages to build and run the app, keeping the final image small.

The build stage includes all tools needed to compile the app but is not included in the final image.

Only the compiled app or runtime files are copied to a minimal base image for the final container.

Practice

1. Why do multi-stage builds in Docker help reduce the final image size?

easy

A. Because they run containers faster

B. Because they use a single large base image for all stages

C. Because they copy only the necessary files from build stages to the final image

D. Because they install all dependencies in every stage

Solution

1. Step 1: Understand multi-stage build process

   Multi-stage builds use multiple FROM statements to separate build and runtime environments.

2. Step 2: Identify file copying behavior

   Only necessary artifacts are copied from build stages to the final image, excluding build tools and dependencies.

3. Final Answer:

   Because they copy only the necessary files from build stages to the final image -> Option C

4. Quick Check:

   Copying only needed files = smaller image [OK]

Hint: Remember: copy only what you need to keep image small [OK]

Common Mistakes:

• Thinking all stages are combined fully
• Assuming all dependencies stay in final image
• Believing multi-stage builds speed up container runtime

2. Which of the following is the correct syntax to copy files from a previous stage named builder in a multi-stage Dockerfile?

easy

A. COPY --from=builder /app/build /app

B. COPY builder:/app/build /app

C. COPY /app/build builder:/app

D. COPY --stage=builder /app/build /app

Solution

1. Step 1: Recall Dockerfile COPY syntax for multi-stage

   The correct syntax uses COPY --from=stageName source destination.

2. Step 2: Match syntax with options

   COPY --from=builder /app/build /app matches the correct syntax exactly.

3. Final Answer:

   COPY --from=builder /app/build /app -> Option A

4. Quick Check:

   Use --from=stageName to copy files [OK]

Hint: Use COPY --from=stageName to copy files between stages [OK]

Common Mistakes:

• Using incorrect flags like --stage
• Trying to copy with colon syntax like builder:/path
• Reversing source and destination paths

3. Given this Dockerfile snippet, what will be the size impact on the final image?

FROM node:18 AS builder
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html

medium

A. The final image will be small because only the build output is copied

B. The final image will be empty because no files are copied

C. The final image will be large because it includes all node modules

D. The final image will include the entire node base image

Solution

1. Step 1: Analyze build and final stages

   The builder stage installs node modules and builds the app. The final stage uses a lightweight nginx image.

2. Step 2: Check what is copied to final image

   Only the build output folder /app/build is copied to nginx's html folder, excluding node modules and build tools.

3. Final Answer:

   The final image will be small because only the build output is copied -> Option A

4. Quick Check:

   Copying only build output reduces image size [OK]

Hint: Copy only build artifacts, not full build environment [OK]

Common Mistakes:

• Assuming node modules are copied to final image
• Thinking final image includes builder base image
• Believing no files are copied at all

4. You wrote a multi-stage Dockerfile but the final image is unexpectedly large. Which mistake could cause this?

medium

A. Using a lightweight base image in the final stage

B. Using multiple FROM statements

C. Not naming the build stage

D. Copying the entire build directory including node_modules to the final stage

Solution

1. Step 1: Identify common causes of large final images

   Copying unnecessary files like dependencies increases image size.

2. Step 2: Match mistake to options

   Copying the entire build directory including node_modules to the final stage describes copying the entire build directory including node_modules, which bloats the image.

3. Final Answer:

   Copying the entire build directory including node_modules to the final stage -> Option D

4. Quick Check:

   Copying unneeded files causes large images [OK]

Hint: Avoid copying full build folders with dependencies [OK]

Common Mistakes:

• Thinking multiple FROM statements cause large images
• Believing missing stage names cause size issues
• Assuming lightweight base images increase size

5. You want to build a Go application using multi-stage builds. The first stage compiles the app, and the second stage runs it. Which Dockerfile snippet best reduces the final image size?

hard

A. FROM golang:1.20
WORKDIR /app
COPY . .
RUN go build -o app
CMD ["./app"]

B. FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o app

FROM alpine
COPY --from=builder /app/app /app/app
CMD ["/app/app"]

C. FROM alpine
COPY . .
RUN go build -o app
CMD ["./app"]

D. FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o app
COPY . .
CMD ["./app"]

Solution

1. Step 1: Understand multi-stage build for Go app

   Build the app in a full Go environment, then copy only the compiled binary to a small base image.

2. Step 2: Evaluate options for size reduction

   FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o app FROM alpine COPY --from=builder /app/app /app/app CMD ["/app/app"] uses golang image to build, then copies only the binary to alpine, minimizing final image size.

3. Final Answer:

   FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o app FROM alpine COPY --from=builder /app/app /app/app CMD ["/app/app"] -> Option B

4. Quick Check:

   Build in full image, run in minimal image [OK]

Hint: Build in full image, copy only binary to small image [OK]

Common Mistakes:

• Building and running in same large image
• Trying to build in alpine without Go tools
• Copying full source code to final image