Interactive YAML key browser for Docker Compose — all top-level keys and service properties with examples.
Docker Compose Reference documents all Docker Compose specification keys and their values: service definitions, build config, volumes, networks, healthchecks, deploy options, and environment variable handling. Each key includes the schema type, valid values, examples, and version compatibility notes. Use it as a quick lookup while writing or debugging docker-compose.yml files.
The Docker Compose Specification (compose-spec.io, 2020) is the current standard, superseding the versioned format (version: 2, version: 3). The spec defines all supported keys and their semantics. Compose V2 (docker compose) implements the specification. Key service-level properties: image (which container to run), build (build from Dockerfile), ports (host:container mapping), environment (env vars), volumes (file mounts), networks (network attachment), depends_on (startup ordering), healthcheck (readiness check), restart (restart policy), command/entrypoint (process to run).
Docker Compose is primarily a development and testing tool. For production: Docker Swarm (built into Docker) or Kubernetes handles orchestration, scaling, and high availability. The compose format can be converted to Kubernetes manifests with Kompose (kompose.io). Many cloud platforms (Google Cloud Run, AWS ECS) also support Compose-compatible formats for deployment.
Port mapping
Result: ports: - '8080:80' -> host port 8080 maps to container port 80
Named volume
Result: volumes: - postgres-data:/var/lib/postgresql/data -> persistent data survives container restart
Restart policy
Result: restart: unless-stopped -> restart on crash but not on explicit 'docker compose stop'
What is the difference between CMD and ENTRYPOINT in Docker?
ENTRYPOINT defines the executable that always runs when the container starts. CMD provides default arguments to the entrypoint (or the default command if no entrypoint). When you run docker run myimage arg1: if ENTRYPOINT is set, arg1 is appended to it. If only CMD is set, arg1 replaces CMD entirely. Best practice: ENTRYPOINT for the application binary (ENTRYPOINT ['node', 'server.js']), CMD for default flags that can be overridden. In Compose: command: overrides CMD. entrypoint: overrides ENTRYPOINT. Use exec form (['cmd', 'arg']) not shell form (cmd arg) to properly handle signals.
What is the difference between bind mounts and volumes?
Bind mount: maps a host directory to the container: volumes: - ./app:/app. The host directory must exist. Good for: development (live code reload), config files, logs. Changes in the container affect the host. Volume: a Docker-managed storage object: volumes: - mydata:/data. Docker manages the storage location (usually /var/lib/docker/volumes/). Good for: persistent data (databases), sharing data between containers. Volumes survive container removal; bind mounts depend on the host directory. Named volumes are preferred for production data (database files) because they are more portable than host paths.
How do networks work in Docker Compose?
By default, Compose creates a default bridge network and attaches all services to it -- services can reach each other by service name (the container hostname is the service name). You can define custom networks for isolation: networks: frontend: backend: -- then assign services to specific networks to control which services can communicate. Services on different networks cannot communicate. Use external: true for networks created outside Compose. For DNS: in Compose, db service is reachable as 'db' from other services on the same network -- no need to use IP addresses.
How do I pass environment variables in Docker Compose?
Options: (1) Inline in compose file: environment: DB_HOST: localhost DB_PORT: '5432'. (2) Pass-through from host (no value): environment: - HOME (uses the host's HOME value). (3) From a .env file (Compose automatically loads .env in the same directory): env_file: - .env. (4) Variable substitution in compose file: image: myapp:${APP_VERSION:-latest} (uses APP_VERSION from .env or environment, defaulting to 'latest'). For secrets: use Docker secrets (Swarm) or a secret manager -- never hardcode sensitive values in docker-compose.yml.
What is the Compose Specification and how does it differ from version 3?
The Compose Specification (2020, compose-spec.io) is the unified, version-independent standard replacing the old versioned files (version: '2', '3', '3.8'). Key differences: no version: key needed (or use 'version: latest'). The spec merges the best of V2 and V3 -- e.g., resource limits work in both Swarm and standalone mode (V3 required Swarm for resource limits). All services, networks, volumes, and configs are defined the same way. Docker Compose V2 (docker compose) implements the specification. Old versioned files still work for compatibility, but new files should omit the version key.