πŸ“ Tutorials
Β· 3 min read
Last updated on

What is Docker Compose? A Simple Explanation for Developers


Docker Compose is a tool for defining and running multi-container Docker applications. Instead of running multiple docker run commands with long argument lists, you describe your entire stack in a single YAML file and start everything with one command.

If you’re already familiar with Docker containers, Compose is the next step β€” it’s how you go from β€œI can run one container” to β€œI can run my entire app stack locally.”

The problem Compose solves

A typical web app needs more than one container:

  • Your app (Node.js, Python, etc.)
  • A database (PostgreSQL, MySQL, MongoDB)
  • A cache (Redis)
  • Maybe a reverse proxy (Nginx)

Without Compose, you’d run each container separately, manually creating networks and volumes. With Compose, you define everything in one file:

# docker-compose.yml
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://postgres:secret@db:5432/myapp
    depends_on:
      - db
      - redis

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: myapp
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

volumes:
  pgdata:

Then start everything:

docker compose up        # start all services
docker compose up -d     # start in background
docker compose down      # stop and remove everything
docker compose logs -f   # follow logs from all services

Key concepts

Services are the containers in your stack. Each service gets its own container, and Compose creates a network so they can talk to each other by service name (db, redis, etc.).

Volumes persist data between container restarts. Without a volume, your database data disappears when the container stops.

depends_on controls startup order. Your app won’t start until the database container is running (though it doesn’t wait for the database to be ready β€” that’s a common gotcha).

build vs image β€” use build: . to build from a local Dockerfile, or image: postgres:16 to pull a pre-built image.

Common commands

docker compose up -d          # start everything in background
docker compose down           # stop and remove containers
docker compose down -v        # also remove volumes (deletes data!)
docker compose ps             # list running services
docker compose logs app       # logs for one service
docker compose exec app sh    # shell into a running container
docker compose build          # rebuild images
docker compose pull           # pull latest images

Docker Compose vs plain Docker

Use plain docker run when you have a single container. Use Compose when you have two or more containers that need to work together. In practice, most developers use Compose even for single-container setups because the YAML file documents the configuration.

Docker Compose vs Kubernetes

Compose is for local development and simple deployments. Kubernetes is for production orchestration at scale β€” auto-scaling, rolling deployments, self-healing. Many teams use Compose locally and Kubernetes in production. See our Docker Compose vs Kubernetes comparison for details.

FAQ

What’s the difference between docker compose up and docker-compose up?

The hyphenated docker-compose is the old standalone Python tool (v1). The space-separated docker compose is the newer Go-based plugin built into Docker itself (v2). They’re functionally equivalent, but you should use docker compose (no hyphen) β€” it’s faster, actively maintained, and ships with Docker Desktop by default.

How do I connect my app to the database in Docker Compose?

Use the service name as the hostname. If your database service is called db, your app connects to db:5432 (for PostgreSQL) instead of localhost:5432. Compose creates a shared network where services can reach each other by name. Make sure to use depends_on so the database starts before your app.

Should I use Docker Compose in production?

For simple deployments on a single server, Compose works fine in production β€” many small teams run their entire stack this way. For anything requiring auto-scaling, rolling deployments, or multi-server orchestration, you’ll want Kubernetes or a managed container platform like AWS ECS or Google Cloud Run.

Learn more

Related: Docker vs Kubernetes

πŸ“˜