Free Docker Compose Cheat Sheet Online — docker-compose.yml Commands, Services & Configuration Reference

Docker Compose turns multi-container applications from a mess of docker run commands and shell scripts into a single declarative YAML file. One docker compose up and your entire stack — web server, database, cache, message queue, worker — springs to life, networked together, with volumes mounted, environment variables set, and health checks monitoring every service. Our free interactive Docker Compose Cheat Sheet gives you instant access to 120 docker compose YAML snippets, CLI commands, and configuration patterns across 10 categories, with real-time search, one-click copy, and a Composer's Score aesthetic. No signup. No server. 100% client-side.

Why Docker Compose Defines Modern Development

Docker Compose has become the universal language of multi-service applications. Every major framework ships a docker-compose.yml in its quickstart. Every CI pipeline that runs integration tests uses Compose to spin up dependencies. Every developer who needs a local PostgreSQL, Redis, and RabbitMQ in one motion reaches for Compose. The Compose Specification — now vendor-neutral and maintained by the Docker community — ensures that a compose file that works on your laptop also works in production Swarm, on a CI runner, or under Kubernetes with the Compose-to-K8s bridge.

Yet for all its ubiquity, Docker Compose has deep configuration surface: port mapping syntax (short and long), volume types (bind mount, named volume, tmpfs), network modes (bridge, host, service), environment injection (map syntax, array syntax, env_file with required flag), health checks with start periods and retries, dependency ordering with service_healthy conditions, deploy resource limits, Compose Watch for hot-reload development, and the newer include and extends patterns for project composition. Our cheat sheet organizes this surface into 10 focused categories with every key, value, and pattern you need.

Compose File Fundamentals — The Top-Level Structure

Every compose file starts with top-level keys: services: (the only required key — defines every container), networks: (custom networks for service isolation), volumes: (named volumes with driver configuration), configs: and secrets: (Swarm-native configuration distribution), name: (custom project name, Compose v2.10+), and include: (sub-project merging, Compose v2.20+).

The Fundamentals category in our cheat sheet covers every top-level key, the difference between docker compose v2 (Go plugin, space separator) and docker-compose v1 (legacy Python, hyphen, deprecated since July 2023), the Compose Specification that eliminated the version field, and the docker compose config command for validating and displaying the fully merged configuration. Understanding these fundamentals prevents configuration drift between environments.

Service Configuration — Defining Every Container

Under services:, each service is a named block that defines one container. The Service Configuration category covers the essential keys: image: (which image to run, including registry, repository, and tag), build: with context, dockerfile, and args (build-time variables), container_name: (fixed name, override the auto-generated project-service-N pattern), command: and entrypoint: (override the image's CMD and ENTRYPOINT), working_dir: (set the container's working directory), user: (run as non-root for security), init: true (use tini as PID 1 for proper signal handling), labels: (metadata for reverse proxies and monitoring), and pull_policy: (control when images are re-pulled).

Ports & Networking — How Services Communicate

Networking is where Docker Compose shines. Every service gets DNS-based service discovery — the service name is the hostname. Our Ports & Networking category documents the full port mapping syntax: short form ("8080:80") and long form with target, published, protocol, and mode keys. The expose: key for service-to-service ports (informational only — Compose does not enforce it). Custom networks with aliases for multi-role services. Special network_mode values: host (share the host network stack, Linux only), bridge (the default), and service:web (share another service's network namespace — the sidecar pattern). DNS customization, extra_hosts entries for /etc/hosts overrides, and MAC address assignment for network policies.

Volumes & Storage — Persistent Data in a Container World

Containers are ephemeral; data should not be. Compose supports three volume types. Bind mounts (./host/path:/container/path) map a host directory into the container — essential for development hot-reload. Named volumes (type: volume, source: db_data, target: /var/lib/mysql) are Docker-managed and survive container removal. tmpfs mounts (type: tmpfs, target: /tmp) store data in RAM — fast, volatile, ideal for caches. The Volumes category also covers volume drivers for external storage (NFS, cloud volumes), the external: true flag for referencing pre-existing volumes, volumes_from for sharing all volumes from another service, Docker socket mounting (powerful but dangerous), read-only root filesystems, and secret file mounts.

Environment & Configuration — Injecting Settings

Every application needs configuration. Compose provides multiple layers: environment: in map syntax (KEY: value, the clearest form) or array syntax (KEY=value, no colon ambiguity), env_file: for loading variables from files with the newer required: true flag (Compose v2.24+), and secrets: for sensitive values mounted as files at /run/secrets/<name>. A critical rule: environment: values always override env_file: values. The .env file in the project directory is used for variable substitution in the compose file itself (${VAR}), not passed to containers. Secrets and configs support fine-grained control with custom mount targets, UID/GID ownership, and file permissions.

Resource & Health Management — Production Readiness

Production Compose files define resource constraints and health monitoring. The deploy: key (respected by both Swarm and Compose v2) sets CPU and memory limits (resources.limits.cpus: "2.0", memory: 512M) and reservations (soft minimums for scheduling). Replicas and update configuration (parallelism, delay, failure action) for zero-downtime rolling updates. Restart policies with condition, delay, max_attempts, and window parameters.

Health checks are the critical bridge between "container is running" and "application is ready." Our Health Management entries cover the full healthcheck: syntax: the test: command (curl, wget, or custom script), interval:, timeout:, retries: (consecutive failures to mark unhealthy), start_period: (grace period after container start), and start_interval: (probe frequency during start_period, Compose v2.20+). Health checks enable depends_on with condition: service_healthy — the cleanest solution to startup ordering.

Dependency & Startup Order — Who Starts When

Multi-service applications have startup dependencies: the database must be running and accepting connections before the web server starts, migrations must complete before the application boots. Compose offers a progressive set of solutions. The short depends_on: syntax controls start order only — it does not wait for readiness. The long syntax with condition: service_healthy waits for the dependency's health check to pass (the modern, built-in approach). condition: service_completed_successfully waits for one-shot services like database migrations to exit cleanly. Legacy approaches like links: (deprecated) and external_links: exist for backward compatibility.

Profiles (profiles: [debug, tools]) enable optional service groups — start extra services only when requested with --profile. The classic wait-for-it.sh and dockerize patterns provide TCP-port-level readiness checks when health checks aren't available. Modern Compose (v2.1+) with health-check-driven depends_on makes external scripts unnecessary for most use cases.

CLI Commands — The docker compose Toolbox

Docker Compose has a rich CLI. Our CLI Commands category covers the complete toolbox: docker compose up (the workhorse — build, create, start, attach), up -d (detached mode, the default for development), up --build (force rebuild before start), down (stop and remove containers and default network) and down -v (add volume removal), ps (list project containers with status), logs with -f (follow), --tail, and service name filters, exec (run commands in a running container — the goto for debugging), run --rm (one-off commands in a fresh container for migrations and tests), build (rebuild images), and pull/push (image registry operations for CI/CD). Every command includes the most-used flags and the scenario it solves.

Build & Development — The Inner Loop

Compose isn't just for production — it accelerates development. Our Build & Development category covers the development inner loop: multi-stage builds with target: (stop at the dev stage), BuildKit cache with cache_from: and cache_to: (pull/push build cache from a registry for faster CI), build-time network configuration, extra_hosts for accessing private registries during build, and most importantly, Compose Watch (v2.22+) — the file-watching system that syncs, rebuilds, or restarts services when source files change.

Compose Watch actions: sync copies changed files into the running container (instant, no rebuild — ideal for interpreted languages and hot module replacement), rebuild triggers a full image rebuild when tracked files change (for dependency manifests like package.json), and restart restarts the container. The x- extension fields pattern using YAML anchors (&shared / *shared) keeps compose files DRY by defining reusable configuration blocks.

Production & Advanced Patterns — Compose at Scale

As projects grow, compose files need structure. The Production & Advanced Patterns category covers composition patterns: extends: (inherit service definitions from other files — the base + override pattern), include: (merge entire sub-projects, Compose v2.20+), multiple -f files (docker compose -f base.yml -f prod.yml up — later files override earlier ones), docker compose config for validating the merged result, COMPOSE_PROJECT_NAME and COMPOSE_FILE environment variables for CI/CD parameterization, --project-name for running multiple instances of the same project, docker compose top for inspecting running processes, docker compose events --json for real-time container lifecycle monitoring, and docker compose pause/unpause for freezing/resuming services via cgroups.

The Composer's Score — Aesthetic Design

Docker Compose orchestrates multiple containers into a coherent application — like a conductor leading a symphony orchestra. Our Docker Compose Cheat Sheet embraces The Composer's Score aesthetic: a deep concert hall background (#0b090e) with a warm golden stage spotlight radiating from the top-center, as if the curtain has just risen. Musical staff lines — five thin golden lines — span the background at subtle opacity, evoking the manuscript paper on which a conductor writes a score. Forty floating musical notes (♪ ♫ ♬ ♭ ♮ ♯) drift upward like sound through a concert hall, each at randomized size, speed, and delay.

A conductor's baton pulse animates along the top edge — a thin golden line that breathes with a 3-second rhythm. The Playfair Display typeface brings a classical, engraved elegance to the headings, reminiscent of the title page of a bound musical score. Lora provides warm, readable body text. JetBrains Mono serves YAML snippets and CLI commands with monospace precision. Category cards are styled as velvet-bound sheet music panels with gold foil left borders and a flat (♭) corner decoration that glows on hover. The color palette draws from the orchestra pit: Gold Foil (#c9a84c, Fundamentals), Opera Red (#c04040, Service Config), Oboe Blue (#5588bb, Networking), Brass Bronze (#b08040, Volumes), Forest Green (#4a8c5c, Environment), Viola Violet (#8855aa, Resources), Cello Amber (#d09030, Dependencies), Baton Copper (#c87040, CLI), Stage Silver (#98a0a8, Build & Dev), and Spotlight Gold (#e0b040, Production). This is not another dark-mode terminal reference; it's a deliberate, crafted space that makes infrastructure orchestration feel like conducting a performance.

How This Cheat Sheet Fits Into Your Workflow

The Docker Compose Cheat Sheet is part of the DevToolkit suite of free developer reference tools. It complements our Docker Commands Cheat Sheet (which covers individual container management, Dockerfile instructions, image operations, and the docker CLI), our Kubernetes Commands Cheat Sheet (for production orchestration at scale), our DevOps Commands Cheat Sheet (CI/CD pipelines and infrastructure automation), and our Linux Commands Cheat Sheet (the operating system that runs the containers). Together with Docker Compose, they form a complete container-and-orchestration reference cluster for developers and DevOps engineers.

The workflow is simple: press Ctrl+K to focus the search bar, type what you need (a Compose key name, a CLI command, a YAML pattern), and the matching entries appear instantly. Click any card to copy its YAML snippet or command to your clipboard. Filter by category to narrow the view. Everything runs in your browser — no server requests, no signup, no tracking. Bookmark it, reference it while writing compose files, and stop searching through Docker documentation for the right syntax.