Why multi-stage builds reduce image size in Docker - Visual Breakdown

Process Flow - Why multi-stage builds reduce image size

Start: Base Build Stage

↓

Install dependencies & build app

↓

Start: Final Stage

↓

Copy only built app from build stage

↓

Create smaller final image

↓

Result: Reduced image size

The build process uses one stage to compile and prepare the app, then copies only the needed files to a smaller final stage, reducing image size.

Execution Sample

Docker

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

FROM node:18-slim
WORKDIR /app
COPY --from=build /app/package.json ./
RUN npm install --production
COPY --from=build /app/dist ./dist
CMD ["node", "dist/index.js"]

This Dockerfile builds the app in a full node image (with dev deps), then copies package.json to install production deps only and copies the built files to a smaller node-slim image.

Process Table

Step	Action	Stage	Files Present	Image Size Impact
1	Start build stage with full node image	build	Base Node runtime & tools	Large size due to full tools
2	Install dependencies and build app	build	Source + node_modules + build output	Size grows with dependencies and build artifacts
3	Start final stage with slim node image	final	Empty except base slim image	Small base size
4	Copy package.json & build output from build stage, install prod deps	final	package.json + prod node_modules + /app/dist	Small size, no dev dependencies or source code
5	Set command to run built app	final	Built app ready to run	Final image size is minimal
6	Image build complete	final	Only runtime files	Reduced image size compared to single stage
7	Exit	-	-	Build finished, smaller image created

💡 Build finishes after copying only necessary files to final stage, reducing image size

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
Files Present	Empty	Source + node_modules + build output	package.json + prod node_modules + build output (/app/dist)	package.json + prod node_modules + build output (/app/dist)
Image Size	Base slim image size	Large (full node + deps)	Small (slim + prod deps + build output)	Small (slim + prod deps + build output)

Key Moments - 3 Insights

Why does the final image not include node_modules from the build stage?

Because package.json and only the built output folder (/app/dist) are copied from the build stage to the final stage (prod node_modules installed separately), excluding build stage node_modules (dev + prod) and source files as shown in execution_table step 4.

Why is the build stage image larger than the final image?

The build stage includes all source code, dependencies, and build tools, making it large (step 2), while the final stage copies only the minimal runtime files (step 4), reducing size.

What happens if we copy everything from the build stage to the final stage?

The final image size would be large, similar to the build stage, losing the benefit of multi-stage builds as explained in the exit note and step 6.

Visual Quiz - 3 Questions

Look at the execution table, at which step are only the built app files copied to the final image?

A Step 2

B Step 4

C Step 1

D Step 6

💡 Hint

Check the 'Action' and 'Files Present' columns in execution_table row for step 4.

According to variable_tracker, what happens to the image size after step 4?

A It becomes larger

B It stays the same

C It becomes smaller

D It is empty

💡 Hint

Look at the 'Image Size' row values after step 4 in variable_tracker.

If we copied node_modules to the final stage, how would the final image size change?

A It would be larger

B It would be smaller

C It would stay the same

D It would be empty

💡 Hint

Refer to key_moments question about copying everything and execution_table step 2 vs step 4.

Concept Snapshot

Multi-stage builds use separate stages to build and package apps.
The build stage includes all tools and dependencies.
The final stage copies only needed files (like package.json & build output).
This reduces final image size by excluding dev files.
Use COPY --from=build to transfer files between stages.

Full Transcript

Multi-stage builds in Docker help reduce image size by separating the build environment from the final runtime environment. First, a build stage uses a full image with all dependencies and tools to compile the app. Then, a final stage starts from a smaller base image, copies package.json to install production deps only, and copies only the built app files from the build stage. This way, the final image excludes unnecessary files like source code and dev node_modules, making it much smaller. The execution table shows each step: starting the build stage, installing dependencies, building the app, starting the final stage, copying necessary files & installing prod deps, and finishing with a small image. The variable tracker highlights how files and image size change after each step. Key moments clarify why only specific files are copied and why the build stage is larger. The visual quiz tests understanding of these steps and their effects. Overall, multi-stage builds are a simple and effective way to keep Docker images lean.

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