Hva er multi-stage builds og hvorfor bruker man dem?

Question

Accepted Answer

**Multi-stage builds** bruker flere `FROM`-stadier i én Dockerfile — bygger applikasjonen i ett stadium (med alle byggeverktøyene) og kopier kun de endelige artefaktene til et rent, minimalt sluttstadium. Dette produserer **mye mindre, mer sikre** produksjonsiminutt.

## Problemet: byggeverktøy fyller opp iminuttet

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

`--from=build` kopierer artefakter fra byggestadiet til det endelige iminuttet. Det endelige iminuttet **ekskluderer alt fra byggestadiet unntatt det du eksplisitt kopierer** — så byggeverktøy, dev-avhengigheter og kildekode havner ikke i produksjon.

## Fordeler

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

## Hvorfor det betyr noe

Å forstå multi-stage builds er verdifullt for **å produsere små, sikre produksjonsiminutt**, så det er viktig praktisk kunnskap for å bygge produksjonskvalitets Docker-iminutt.

Problemet det løser er reelt og vanlig: å bygge en applikasjon krever **byggeverktøy** (kompilatorer, SDK-er, dev-avhengigheter) som **det endelige produksjonsiminuttet ikke bør inneholde** — å inkludere dem fyller opp iminuttet (større størrelse, langsommere distribusjoner og pulls) og øker **angrepsflatene** (mer installert programvare betyr flere potensielle sårbarheter). **Multi-stage builds** løser dette elegant ved å bruke flere `FROM`-stadier: bygger applikasjonen i et stadium med alle verktøyene, deretter **kopierer kun de endelige artefaktene** (`--from=build`) til et rent, minimalt sluttstadium som ekskluderer alt annet.

Dette produserer iminutt som er **dramatisk mindre** (ofte 10x+ mindre — bare kjøretiden og artefaktene) og **mer sikre** (ingen byggeverktøy eller unødvendige pakker å utnytte), mens du holder alt i en enkelt Dockerfile (ingen separate byggeskripter).

Dette mønsteret er standard for kompilerte språk (Go, Rust, Java, hvor kompilatoren ikke er nødvendig ved kjøring) og for frontend/Node-bygg (hvor byggetooling og kildekode ikke er nødvendig i produksjon).

Siden små, sikre produksjonsiminutt betyr noe for distribusjonshastigfet, lagring og sikkerhet, og siden multi-stage builds er standard, effektiv teknikk for å oppnå dem (separering av byggmiljøet fra det slanke kjøremiljøiminuttet), er det verdifullt, ofte brukt å forstå multi-stage builds — bloat/sikkerhetsproblemet de løser, hvordan de fungerer, og fordelene deres — kunnskap for å bygge produksjonskvalitets Docker-iminutt, en beste praksis som brukes mye i virkelige Dockerfiler og en nøkkelferdighet for å produsere effektive, sikre containeriserte applikasjoner.