What are multi-stage builds and why use them?

Question

Accepted Answer

**Multi-stage builds** use multiple `FROM` stages in one Dockerfile — building the application in one stage (with all the build tools) and copying only the final artifacts into a clean, minimal final stage. This produces **much smaller, more secure** production images.

## The problem: build tools bloat the image

```text
Building an app needs build tools (compilers, dev dependencies, SDKs), but the
FINAL image shouldn't include them:
  → they bloat the image (larger size, slower deploys)
  → they increase the attack surface (more software = more vulnerabilities)
→ You want only the built artifact + its runtime in the final image.
```

## Multi-stage build

```dockerfile
# STAGE 1: "build" — has all the build tools (compile/bundle the app)
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install              # includes dev dependencies, build tools
COPY . .
RUN npm run build            # produces /app/dist

# STAGE 2: final — a clean, minimal image with ONLY the built artifact
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html   # copy ONLY the build output
# → the final image has NO build tools, no dev dependencies — just nginx + the built files
```

The `--from=build` copies artifacts from the build stage into the final image. The final image **excludes everything from the build stage except what you explicitly copy** — so build tools, dev dependencies, and source don't end up in production.

## Benefits

```text
✓ SMALLER images — only the runtime + artifacts (often 10x+ smaller)
✓ More SECURE — fewer packages = smaller attack surface (no compilers/build tools)
✓ Faster deploys/pulls (smaller images transfer faster)
✓ One Dockerfile — build and final image together (no separate build scripts)
→ Common for compiled languages (Go, Rust, Java) and Node/frontend builds.
```

## Why it matters

Understanding multi-stage builds is valuable for **producing small, secure production images**, so it's important practical knowledge for building production-quality Docker images.

The problem it solves is real and common: building an application requires **build tools** (compilers, SDKs, dev dependencies) that the **final production image shouldn't contain** — including them bloats the image (larger size, slower deployments and pulls) and increases the **attack surface** (more installed software means more potential vulnerabilities). **Multi-stage builds** solve this elegantly by using multiple `FROM` stages: building the application in a stage with all the tools, then **copying only the final artifacts** (`--from=build`) into a clean, minimal final stage that excludes everything else.

This produces images that are **dramatically smaller** (often 10x+ smaller — just the runtime and artifacts) and **more secure** (no build tools or unnecessary packages to exploit), while keeping everything in a single Dockerfile (no separate build scripts).

This pattern is standard for compiled languages (Go, Rust, Java, where the compiler isn't needed at runtime) and for frontend/Node builds (where build tooling and source aren't needed in production).

Since small, secure production images matter for deployment speed, storage, and security, and since multi-stage builds are the standard, effective technique for achieving them (separating the build environment from the lean runtime image), understanding multi-stage builds — the bloat/security problem they solve, how they work, and their benefits — is valuable, frequently-applied knowledge for building production-quality Docker images, a best practice widely used in real-world Dockerfiles and a key skill for producing efficient, secure containerized applications.