What is Docker Compose, and what problem does it solve?

The problem: real applications are rarely just one container

# Manually orchestrating a 3-service application with plain docker commands:
docker network create my-app-network
docker volume create db-data
docker run -d --network my-app-network --name db -v db-data:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret postgres:16
docker run -d --network my-app-network --name api -e DB_HOST=db \
  -p 3000:3000 myapi:1.0
docker run -d --network my-app-network --name web -p 8080:80 myweb:1.0

Even a modest three-service application requires remembering and correctly sequencing several separate commands, each with several flags. This is error-prone to type out manually every time, hard to share consistently with teammates, and impossible to meaningfully version-control as a single coherent unit.

The Compose solution: one declarative file

# compose.yaml
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - db-data:/var/lib/postgresql/data

  api:
    image: myapi:1.0
    environment:
      DB_HOST: db
    ports:
      - "3000:3000"
    depends_on:
      - db

  web:
    image: myweb:1.0
    ports:
      - "8080:80"

volumes:
  db-data:

docker compose up -d      # brings up ALL three services, the network, and the volume
docker compose down        # tears it all down again

One file captures the entire application's shape: every service, its configuration, and how they relate. Two simple commands then bring the whole thing up or down consistently, every time, on any machine with Docker and Compose installed.

What Compose handles automatically that you'd otherwise do manually

• Creates a dedicated network automatically — every service defined in the file can reach every other service by its service name (db, api, web) via DNS, with zero manual network setup (see the networking topic's DNS question). Compose creates a user-defined bridge network for the whole project by default.
• Manages startup/shutdown ordering — respects depends_on relationships (with the caveats covered in that question).
• Consistent, reproducible environment — the exact same file, committed to version control, produces the exact same multi-container setup for every developer on a team, or in CI. No one needs to remember or manually re-type the individual docker run commands.

What Compose is (and isn't) meant for

Compose is designed and best suited for single-host multi-container applications — local development environments, simple single-server deployments, CI test environments spinning up a full application stack for integration testing. It is explicitly not a multi-host orchestrator. It has no concept of scheduling containers across many machines, no built-in self-healing or rescheduling on node failure, and no rolling-update mechanism comparable to Kubernetes's. (See that stack's Compose-vs-Kubernetes comparison question for exactly where Compose's scope ends and a real orchestrator's begins.)

Why this matters for local development specifically

Compose has become the standard way to "spin up this whole application's dependencies locally." A single docker compose up command that brings up a database, a cache, a message queue, and the application itself, all correctly networked together, is a dramatically better onboarding and local-development experience. This beats expecting every developer to manually install and configure each dependency directly on their own machine.