Multi-Container Apps with Docker Compose

Why Compose

Real applications are several containers: a web app, a database, maybe a cache. Starting each with a long docker run command and wiring networks by hand is tedious and error-prone. Docker Compose lets you describe all of them in one docker-compose.yml file and manage them as a unit.

A web + database stack

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

  api:
    build: .
    ports:
      - "3000:3000"
    environment:
      DB_HOST: db
      DB_PASSWORD: secret
    depends_on:
      - db

volumes:
  pgdata:

Notice how much this replaces: two images, a named volume, port mapping, environment variables and a shared network (Compose creates one automatically, so api reaches the database at the hostname db).

Everyday Compose commands

docker compose up -d      # build (if needed) and start everything
docker compose ps         # see the services
docker compose logs -f api# follow one service's logs
docker compose down       # stop and remove containers + network
docker compose down -v    # also remove named volumes

build vs image

A service uses image: to pull a ready-made image, or build: . to build from a local Dockerfile. Mixing both – a built app service plus off-the-shelf database and cache images – is the normal pattern.

Key points

• Compose describes a multi-container app declaratively in one YAML file.
• Services share an auto-created network and reach each other by service name.
• up -d starts the stack; down tears it down; -v also drops volumes.
• Use build: for your own app and image: for third-party services.