Multi-stage builds concept in Docker - Step-by-Step Execution

Process Flow - Multi-stage builds concept

Start: Define Stage 1

↓

Build app in Stage 1

↓

Define Stage 2

↓

Copy artifacts from Stage 1 to Stage 2

↓

Build final image in Stage 2

↓

Result: Smaller final image

Multi-stage builds use multiple steps in one Dockerfile to build and copy only needed files, making the final image smaller.

Execution Sample

Docker

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

FROM alpine:latest
COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]

This Dockerfile builds a Go app in the first stage, then copies the binary to a small Alpine image in the second stage.

Process Table

Step	Action	Stage	Files Present	Image Size Impact
1	Start Stage 1 with golang base	builder	golang base files	Large (includes build tools)
2	Copy source code to /app	builder	source code + golang files	No size change
3	Run go build to create binary	builder	binary + source + golang files	Size increases (binary added)
4	Start Stage 2 with alpine base	final	alpine base files	Small (minimal base)
5	Copy binary from builder stage	final	binary + alpine files	Size increases (only binary added)
6	Set CMD to run binary	final	binary + alpine files	No size change
7	Build completes	final	final image with binary only	Small final image (no build tools)

💡 Build ends with final image containing only necessary runtime files, excluding build dependencies.

Status Tracker

Variable	Start	After Step 3	After Step 5	Final
Files Present	golang base files	golang base + source + binary	alpine base + binary	alpine base + binary
Image Size	large	larger	small	small

Key Moments - 2 Insights

Why does the final image not include the source code or build tools?

Because in the execution_table at step 5, only the binary is copied from the builder stage to the final stage, so source code and build tools stay only in the builder stage.

How does multi-stage build reduce image size?

As shown in the execution_table, the final stage starts with a small base (alpine) and copies only the built binary, skipping all build dependencies, resulting in a smaller image.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What files are present in the builder stage after building?

A Only the binary file

B Only source code

C Source code, golang base files, and binary

D Alpine base files and binary

💡 Hint

Check the 'Files Present' column at step 3 in the execution_table.

At which step does the final image start to include the built binary?

A Step 5

B Step 4

C Step 2

D Step 7

💡 Hint

Look at the 'Files Present' column in the execution_table for when binary appears in the final stage.

If we copied source code instead of binary in step 5, how would the final image size change?

A It would be smaller

B It would be larger

C It would stay the same

D It would fail to build

💡 Hint

Refer to the variable_tracker showing image size changes related to files present.

Concept Snapshot

Multi-stage builds use multiple FROM statements in one Dockerfile.
Each stage can build or prepare files.
Later stages copy only needed artifacts from earlier stages.
This keeps the final image small by excluding build tools and source code.
Use --from=stage_name to copy files between stages.

Full Transcript

Multi-stage builds in Docker let you create smaller images by splitting the build into steps. First, you build your app in a stage with all tools. Then, you start a new stage with a small base image and copy only the built app from the first stage. This way, the final image has only what is needed to run the app, not the build tools or source code. The Dockerfile uses multiple FROM lines with stage names. The COPY command with --from= lets you copy files from one stage to another. This reduces image size and improves security.