Wat zijn multi-stage builds en waarom gebruik je ze?

Question

Accepted Answer

**Multi-stage builds** gebruiken meerdere `FROM` stages in één Dockerfile — het bouwen van de toepassing in één stage (met alle bouwtools) en het kopiëren van alleen de uiteindelijke artefacten naar een schone, minimale eindstage. Dit levert **veel kleinere, veiligere** productieafbeeldingen op.

## Het probleem: bouwtools maken de afbeelding groter

```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
```

De `--from=build` kopieert artefacten uit de bouwstage naar de uiteindelijke afbeelding. De uiteindelijke afbeelding **sluit alles van de bouwstage uit behalve wat je expliciet kopieert** — dus bouwtools, dev-afhankelijkheden en broncode eindigen niet in productie.

## Voordelen

```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.
```

## Waarom het belangrijk is

Multi-stage builds begrijpen is waardevol voor **het produceren van kleine, veilige productieafbeeldingen**, dus het is belangrijke praktische kennis voor het bouwen van productiekwaliteit Docker-afbeeldingen.

Het probleem dat het oplost is echt en veelvoorkomend: het bouwen van een toepassing vereist **bouwtools** (compilers, SDK's, dev-afhankelijkheden) die de **uiteindelijke productieafbeelding niet mag bevatten** — ze erin opnemen maakt de afbeelding groter (grotere grootte, langzamere implementaties en pulls) en verhoogt het **aanvalsoppervlak** (meer geïnstalleerde software betekent meer potentiële kwetsbaarheden). **Multi-stage builds** lossen dit elegant op door meerdere `FROM` stages te gebruiken: het bouwen van de toepassing in een stage met alle tools, vervolgens **alleen de uiteindelijke artefacten** (`--from=build`) kopiëren naar een schone, minimale eindstage die alles anders uitsluit.

Dit levert afbeeldingen op die **dramatisch kleiner zijn** (vaak 10x+ kleiner — alleen de runtime en artefacten) en **veiliger** (geen bouwtools of onnodige pakketten om uit te buiten), terwijl alles in één Dockerfile blijft (geen aparte bouwscripts).

Dit patroon is standaard voor gecompileerde talen (Go, Rust, Java, waarbij de compiler niet nodig is bij uitvoering) en voor frontend/Node-builds (waarbij bouwtools en broncode niet nodig zijn in productie).

Angezien kleine, veilige productieafbeeldingen belangrijk zijn voor implementatiesnelheid, opslag en beveiliging, en aangezien multi-stage builds de standaard, effectieve techniek zijn om ze te bereiken (het scheiden van de bouwomgeving van de magere runtime-afbeelding), is het begrijpen van multi-stage builds — het bloat/beveiligingsprobleem dat ze oplossen, hoe ze werken en hun voordelen — waardevol, regelmatig toegepaste kennis voor het bouwen van productiekwaliteit Docker-afbeeldingen, een best practice die veel wordt gebruikt in echte Dockerfiles en een belangrijke vaardigheid voor het produceren van efficiënte, veilige containerapplicaties.