Intermediate

The env_file key looks simple but has surprisingly rich behavior, you can load multiple files, mark some as optional, and control how they’re parsed. The two flavors of .env There are two completely different things called “.env” in Compose: The project .env file at the same level as compose.yml, used for interpolation of ${VAR} in the Compose file itself (see Tip #42) env_file: at service level, loaded as runtime environment variables inside the container This post is about the second one. ...

Most people know docker compose config as “the validate command”. It’s much more than that. The same command can list resources, output JSON, hash services for change detection, and pin image digests for reproducibility. Listing resources Ask Compose what’s actually in your project, after all overrides and interpolation: # List all services docker compose config --services # List all volumes docker compose config --volumes # List all images used docker compose config --images # List all defined profiles docker compose config --profiles These are great in scripts when you need to loop over each service: ...

Your development Compose file isn’t your CI Compose file. A dedicated CI configuration ensures tests run against a clean, seeded database with no leftover state. The development stack Take a typical full-stack project like dockersamples/sbx-quickstart — a FastAPI backend with a Next.js frontend and PostgreSQL: # compose.yml services: backend: build: ./backend ports: - "8000:8000" environment: DATABASE_URL: postgresql://postgres:postgres@db:5432/devboard depends_on: db: condition: service_healthy frontend: build: ./frontend ports: - "3000:3000" db: image: postgres:16 environment: POSTGRES_PASSWORD: postgres POSTGRES_DB: devboard volumes: - db-data:/var/lib/postgresql/data healthcheck: test: ["CMD", "pg_isready"] interval: 5s retries: 5 volumes: db-data: Adding a CI override Create a compose.ci.yml that adapts the stack for testing: ...

Running ML models, video processing, or any GPU-accelerated workload? Compose lets you reserve GPU devices for specific services. Basic GPU access Give a service access to all available GPUs: services: ml-training: image: pytorch/pytorch deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] Limiting GPU count Reserve a specific number of GPUs instead of all: services: inference: image: mymodel:latest deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] Selecting specific GPUs by ID Target specific GPU devices when you have multiple: ...

Build args and environment variables both pass values to your containers, but they work at different times and serve different purposes. Mixing them up is a common source of confusion. Build args: build-time only Build args are available during docker build and are not present in the running container: services: app: build: context: . args: NODE_VERSION: "20" APP_VERSION: "2.1.0" In the Dockerfile, they’re consumed with ARG: ...