Hardening Docker Compose for Production-Like Dev

Local stacks that diverge from production breed "works on my machine" incidents. Hardened Docker Compose mirrors topology, limits, and health semantics teams see in Kubernetes.

Resource limits mirror prod ratios

services:
  api:
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
    healthcheck:
      test: ['CMD', 'curl', '-f', 'http://localhost:3000/health']
      interval: 10s
      retries: 5

If local dev runs without limits, memory leaks hide until deploy.

Topology fidelity

Run the same dependencies as prod:

• PostgreSQL primary + replica (even if small)
• RabbitMQ with management plugin
• Redis with persistence enabled for queue-adjacent caches
• MinIO or LocalStack only when S3 semantics matter—avoid mocking S3 behavior that B2 differs on

Seed and migration parity

• Apply Prisma migrations on compose up, not manual SQL
• Seed scripts use production-like volumes (thousands of rows, not three)
• Document port mapping in .env.example—no tribal knowledge

Developer experience guardrails

docker compose down -v should be safe and documented. Named volumes for Postgres survive restarts but reset cleanly for schema experiments.

Production-like dev environments catch integration failures at laptop cost, not customer cost.