Docker best practices 2026: Multi-stage builds, rootless containers och SBOM

Många Dockerfiles jag stöter på är skrivna efter en handledning från för länge sedan och har inte uppdaterats sedan dess. De fungerar, men de bygger images som är onödigt stora, långsamma att bygga och fyllda med saker som inte borde vara i produktion. Verktygen har förbättrats rejält, och 2026 finns det inget skäl att leva med en image på flera hundra megabyte när samma applikation kan rymmas i en bråkdel. Det här är de vanor jag konsekvent använder: multi-stage builds, rootless containers och SBOM.

Multi-stage builds är utgångspunkten

Den enskilt viktigaste tekniken är multi-stage builds. Tanken är enkel: du har ett bygg-steg med alla verktyg, kompilatorer och utvecklingsberoenden, och ett separat slutsteg dit du bara kopierar den färdiga artefakten. Allt byggskräp stannar i det första steget och följer aldrig med till den image du kör i produktion.

Skillnaden är dramatisk. En typisk applikation kan gå från flera hundra megabyte till några tiotal, helt enkelt för att kompilatorer, paketcacher och byggverktyg inte längre släpar med. Mindre image betyder snabbare nedladdning, snabbare start och mindre angreppsyta. Det är svårt att hitta en anledning att inte göra det här.

Rootless och minimala basbilder

Nästa steg handlar om vad slutsteget bygger på och vem din process kör som. Att köra som root i en container är en onödig risk: om en angripare tar sig in får de fler möjligheter än de borde. Att skapa en användare med begränsade rättigheter och köra processen som den, alltså rootless, begränsar skadan om något går fel.

Parallellt lönar det sig att slimma basbilden. En full operativsystembild innehåller ett skal, pakethanterare och dussintals verktyg som din applikation aldrig använder, men som en angripare gärna gör. Minimala eller distroless-bilder tar bort allt det.

• Mindre angreppsyta: utan ett skal är det betydligt svårare för en angripare att ta sig vidare.
• Färre sårbarheter: färre paket betyder färre kända sårbarheter att hålla efter.
• Snabbare skanningar: en sårbarhetsskanning på en minimal image är snabb och resultatet hanterbart.

BuildKit och smart cache

BuildKit är numera standard och gör byggena både snabbare och mer kapabla. Det bygger oberoende steg parallellt och cachar lager intelligent. Nyckeln till snabba byggen är att ordna din Dockerfile så att det som ändras sällan ligger tidigt och det som ändras ofta ligger sent.

Det konkreta exemplet är beroenden. Kopiera in din beroendelista och installera beroenden innan du kopierar in din källkod. Då återanvänds det dyra installationssteget från cachen så länge beroendena inte ändrats, även när du ändrar i koden. Gör du tvärtom byggs allt om vid varje liten kodändring. Den här ordningen är skillnaden mellan ett bygge på sekunder och ett på minuter.

SBOM och en spårbar leveranskedja

En SBOM, alltså en lista över exakt vilka komponenter och versioner som ingår i din image, ger dig en innehållsförteckning över vad du faktiskt levererar. När en ny sårbarhet i ett beroende dyker upp kan du på sekunder svara på frågan om du är drabbad, i stället för att gissa. 2026 är det en självklar del av en mogen byggprocess, inte en lyx.

SBOM hänger ihop med övriga säkerhetsvanor: pinna dina basbilder till en specifik, verifierbar version i stället för en flytande tagg, och lägg en sårbarhetsskanning i bygget så att kända problem fångas innan de når produktion. Tillsammans ger de dig svar på vad som finns i din image och om det är tryggt. Hur images, skanning och deploy hänger ihop till en trygg helhet beskriver jag i min tjänst för DevOps-plattform.

Reproducerbarhet i praktiken

En bra image är förutsägbar. Samma källkod ska ge samma image, oavsett vem som bygger den eller när. Det betyder att undvika flytande versioner, att inte ladda ner saker från internet mitt i bygget utan att verifiera dem, och att hålla en .dockerignore som hindrar onödiga filer från att smyga in i bygget och blåsa upp storleken. Lägg heller aldrig en hemlighet i ett lager, eftersom den finns kvar även om du tar bort den senare. Små detaljer, men de avgör om dina byggen är tillförlitliga.

Relaterat

• GitOps med ArgoCD vs Flux: Vilket passar er K8s-stack?
• SRE för 5-personers team: Error budgets, SLO:er och on-call light
• Trunk-based development på riktigt: Feature flags med PostHog/Unleash

Vill du se hur moderniserade images sett ut i ett skarpt projekt finns exempel i min casebook.

Vill du ta det vidare?

Om dina images är stora, långsamma att bygga eller fulla av saker som inte borde vara där hjälper jag dig att slimma dem. Hör av dig via kontaktsidan.