Docker Compose for Development: A Practical Guide

Why Docker Compose?

Remember the last time you had to install PostgreSQL, Redis, and RabbitMQ on your Mac just to run a project locally?

I do. It took me an entire afternoon, and I still messed up the PostgreSQL version.

The Docker Compose Way

version: "3.8"
services:
  postgres:
    image: postgres:16
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

  app:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - postgres
      - redis
    environment:
      DATABASE_URL: postgres://user:pass@postgres:5432/mydb

One file, three services, zero installation headaches.

My Dev Setup

I use a docker-compose.yml for infrastructure services only:

• PostgreSQL — the database
• Redis — caching and sessions
• Mailpit — catch emails in dev
• MinIO — S3-compatible storage locally

The actual application runs on the host with hot reload. Best of both worlds.

Pro Tips

1. Use named volumes

volumes:
  pgdata:

Your data survives docker compose down. Game changer.

2. Set resource limits

services:
  postgres:
    deploy:
      resources:
        limits:
          memory: 512M

Prevents Docker from eating your laptop.

3. Create a Makefile

dev: docker-up dev-server

docker-up:
    docker compose up -d

dev-server:
    npm run dev

Common Pitfalls

❌ Forgetting to expose ports — Your app can't connect if the port isn't mapped
❌ Using latest tag — postgres:latest today might be version 17 tomorrow
❌ Not cleaning up — docker system prune once in a while saves disk space

Docker Compose is not just for production. It is the best thing that happened to local development since hot reload.