9.2.1 Compose Services

The services key is the central, almost always present section of a Compose file, mapping each component of a multi-container application to its own name and configuration, forming the backbone around which the rest of the Compose file's structure is organized.

The Role of Services Within the Overall File

Every other top-level Compose concept — networks, volumes — ultimately exists to support what's declared under services, since services are what actually run as containers.

services:
  api:
    build: .
    networks:
      - app-net
    volumes:
      - api-data:/data

networks:
  app-net:

volumes:
  api-data:

The networks and volumes declared at the top level exist specifically to be referenced and used by entries under services.

Configuration Options Available Within a Service

Each service entry supports a wide range of configuration keys, covering everything from how the container is built or sourced to how it's networked, configured, and resourced.

services:
  api:
    build: .
    image: myapi:latest
    ports:
      - "8080:8080"
    environment:
      - LOG_LEVEL=debug
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 512M

Distinguishing Build-From-Source Services From Pre-Built Image Services

A service can either build its own image from a local Dockerfile or simply use an existing, pre-built image — both are valid, with the choice depending on whether the service represents custom application code or an off-the-shelf dependency.

services:
  api:
    build: .
  db:
    image: postgres:16

Why the Services Key Matters

As the section actually responsible for defining what runs, the services key is the part of a Compose file most directly analogous to a collection of individual docker run commands, and understanding its full range of configuration options is foundational to making effective use of Compose at all.