Docker in productie: 8 best practices voor MKB-teams

Docker op je laptop is leuk. Docker in productie is een ander verhaal. Hier zijn 8 best practices die we leren uit echte deploys — voor MKB-teams die hun software betrouwbaar willen runnen zonder een legioen DevOps engineers.

1. Multi-stage builds — je images afslanken

Standaard Node.js image: 1.2 GB. Met multi-stage build: 180 MB. Snellere deploys, minder aanvalsoppervlak, lagere kosten.

# Build stage
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

De production image bevat alleen wat nodig is voor runtime — geen build tools, geen tests, geen documentation.

2. Gebruik specifieke image-tags, geen "latest"

FROM node:latest is een tikkende tijdbom. Vandaag werkt het, morgen breekt een minor update je productie.

Pin altijd een specifieke versie: FROM node:20.11.0-alpine3.19. Updates plan je expliciet, niet per ongeluk.

3. Health checks die meer doen dan "process is running"

Een container die draait is niet hetzelfde als een container die werkt. Implementeer een echte health check:

HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

Het /health endpoint moet checken: database-verbinding werkt, externe APIs bereikbaar, voldoende geheugen vrij.

4. Run nooit als root

Een container-breakout door een kwetsbaarheid is veel erger als je proces als root draait. Voeg een non-root user toe:

RUN addgroup -S app && adduser -S app -G app
USER app

Bonus: ontdek je code-fouten sneller — bijvoorbeeld "wil schrijven naar /etc" stopt direct in plaats van per ongeluk te werken.

5. Secrets nooit in images of environment variables

Database passwords in .env die naar Docker Hub worden gepusht: gebeurt vaker dan je denkt.

Gebruik in productie:

• Docker secrets (bij Swarm)
• Kubernetes secrets (bij K8s)
• HashiCorp Vault of AWS Secrets Manager
• Of minimaal: secrets via runtime environment, nooit gehard in images

6. Resource limits — voorkom dat één container alles opslokt

Zonder limits kan een memory leak in één service je hele host platleggen.

deploy:
  resources:
    limits:
      cpus: '1.0'
      memory: 512M
    reservations:
      cpus: '0.25'
      memory: 256M

Begin krap, monitor, breidt uit als je metrics laten zien dat het nodig is.

7. Logs naar stdout/stderr, niet naar file

Containers moeten stateless zijn. Logs schrijven naar /var/log/app.log binnen de container? Verdwijnt bij restart. Vol disk? Container crasht.

Schrijf naar stdout en stderr. Docker pikt het op, jouw log-aggregator (Loki, ELK, Datadog) verzamelt het centraal.

8. Image scanning in CI/CD

Tools zoals Trivy of Snyk scannen je image op bekende kwetsbaarheden. Voeg het toe aan je pipeline:

- name: Scan image
  run: trivy image --severity HIGH,CRITICAL my-app:${{ github.sha }}

Faalt op CRITICAL vulnerabilities? Block de deploy. Beter een uur vertraging dan een security incident.

De bonus: dependencies up-to-date houden

Tools zoals Renovate of Dependabot maken automatisch PRs voor dependency updates. Met goede tests durf je die te mergen — en je base images blijven actueel zonder handmatig werk.

De volwassen Docker setup checklist

1. ✓ Multi-stage builds voor kleine images
2. ✓ Specifieke versie tags, geen "latest"
3. ✓ Health checks die echt iets testen
4. ✓ Non-root users in alle containers
5. ✓ Secrets via secret manager, niet in images
6. ✓ Resource limits ingesteld
7. ✓ Centralized logging
8. ✓ CI/CD met security scanning

Help nodig bij Docker-productie of je CI/CD pipeline? Plan een gesprek — we hebben tientallen production-omgevingen opgezet voor MKB-bedrijven.

Verder lezen: Kubernetes — overkill of zinvol en Docker compose vs Kubernetes.