Deploying Multi-Container Apps with Docker Compose

Introduction

Modern cloud-native applications are usually built from several small, connected services rather than a single monolith — an architecture known as microservices. Managing multiple related containers by hand with individual docker commands quickly becomes complex. Docker Compose, often just called Compose, solves this by letting an entire application be described in a single YAML file and deployed with one command.

Background

Compose originated as a tool called Fig, built by Orchard Labs to simplify deploying multi-container apps on top of Docker. Docker, Inc. later acquired Orchard Labs, rebranded the tool as Docker Compose, and eventually folded it directly into the Docker CLI as the docker compose subcommand. Compose is also guided by an open, community-led Compose Specification, with Docker Compose serving as its reference implementation.

All modern versions of Docker include Compose pre-installed, and its presence can be verified with:

docker compose version

Anatomy of a Compose File

A Compose file, conventionally named compose.yaml, defines an application's services, networks, and volumes. A typical example defines a web front-end service and a Redis backend, connected over a shared network, with Redis using a persistent volume:

services:
  web-fe:
    build: .
    command: python app.py
    ports:
      - target: 8080
        published: 5001
    networks:
      - counter-net
  redis:
    image: "redis:alpine"
    networks:
      - counter-net
    volumes:
      - type: volume
        source: counter-vol
        target: /app

networks:
  counter-net:

volumes:
  counter-vol:

The services key defines each microservice, including how to build or which image to pull, what command to run, which ports to expose, and which network to join. The networks and volumes keys declare the shared resources services can attach to or mount. Because both services join the same network, they can resolve and communicate with each other by service name — for example, the web app connects to Redis simply by referencing redis as the hostname.

Deploying the App

The most common way to deploy a Compose application is:

docker compose up --detach

This single command builds or pulls any required images, creates the declared networks and volumes, and starts all the defined containers. Docker names the resulting resources using a combination of the project name — derived from the build context's directory — and the service name, such as multi-container-web-fe-1.

A custom Compose file name or location can be specified with the -f flag:

docker compose -f apps/ddd-book/sample-app.yml up --detach

Managing the App's Lifecycle

Once deployed, a Compose app can be managed with a small set of dedicated subcommands. docker compose ps lists the running containers and their status, while docker compose top shows the processes running inside each container.

docker compose stop
docker compose restart

Stopping an app leaves its containers, networks, and volumes intact, so restarting it resumes exactly where it left off — including any data stored in a volume. Checking overall app status is done with:

docker compose ls

Cleaning Up

To fully remove an app, including its volumes and images, the following command can be used:

docker compose down --volumes --rmi all

By default, docker compose down only removes containers and networks, leaving volumes and images in place — a safeguard against accidentally losing stored data.

Conclusion

Docker Compose turns what would otherwise be a series of fragile, manually-run commands into a single, version-controllable definition of an application. Because a Compose file documents every service, image, port, network, and volume an application depends on, it also serves as valuable living documentation that helps bridge the gap between development and operations teams.