Vad är flerstegade builds och varför använda dem?

Question

Accepted Answer

**Flerstegade builds** använder flera `FROM`-steg i en Dockerfile — bygger applikationen i ett steg (med alla byggverktyg) och kopierar bara de slutliga artefakterna till ett rent, minimalt slutsteg. Detta producerar **mycket mindre, säkrare** produktionsavbildningar.

## Problemet: byggverktyg uppblåser avbildningen

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

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

`--from=build` kopierar artefakter från byggstadiet in i den slutliga avbildningen. Den slutliga avbildningen **exkluderar allt från byggstadiet förutom det du uttryckligen kopierar** — så byggverktyg, utvecklingsberoenden och källkod hamnar inte i produktion.

## Fördelar

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

## Varför det är viktigt

Att förstå flerstegade builds är värdefullt för att **producera små, säkra produktionsavbildningar**, så det är viktigt praktisk kunskap för att bygga produktionskvalité Docker-avbildningar.

Problemet det löser är verkligt och vanligt: att bygga en applikation kräver **byggverktyg** (kompilatorer, SDK:er, utvecklingsberoenden) som **den slutliga produktionsavbildningen inte bör innehålla** — att inkludera dem uppblåser avbildningen (större storlek, långsammare distributioner och pull:ar) och ökar **angreppsytan** (mer installerad programvara betyder fler potentiella sårbarheter). **Flerstegade builds** löser detta elegant genom att använda flera `FROM`-steg: bygga applikationen i ett steg med alla verktyg, sedan **kopiera bara de slutliga artefakterna** (`--from=build`) till ett rent, minimalt slutsteg som exkluderar allt annat.

Detta producerar avbildningar som är **dramatiskt mindre** (ofta 10x+ mindre — bara runtime och artefakter) och **säkrare** (inga byggverktyg eller onödiga paket att utnyttja), medan allt stannar i en enda Dockerfile (inga separata byggskript).

Detta mönster är standard för kompilerade språk (Go, Rust, Java, där kompilatorn inte behövs vid körning) och för frontend/Node-byggen (där byggverktyg och källkod inte behövs i produktion).

Since små, säkra produktionsavbildningar är viktiga för distributionshastighet, lagring och säkerhet, och eftersom flerstegade builds är standardtekniken, effektiv teknik för att uppnå dem (separera byggmiljön från den magra körmiljöavbildningen), är att förstå flerstegade builds — uppblåst/säkerhetsproblemen de löser, hur de fungerar och deras fördelar — värdefullt, ofta använd kunskap för att bygga produktionskvalité Docker-avbildningar, en bästa praxis som används ofta i verkliga Dockerfiler och en viktig färdighet för att producera effektiva, säkra containeriserade applikationer.