Configuration

You’ve used secrets for sensitive data (Tip #22). For non-sensitive config files like nginx.conf or prometheus.yml, there’s a parallel feature: configs. Basic usage Define a config at the top level, reference it in a service: configs: nginx_conf: file: ./nginx.conf services: web: image: nginx configs: - source: nginx_conf target: /etc/nginx/nginx.conf The file is mounted read-only inside the container at the target path. No need to declare a volume mount manually. ...

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: ...

Every Compose stack gets a project name. It prefixes all resource names such as containers, networks, volumes. Understanding how it works avoids naming conflicts and makes multi-environment setups cleaner. Default behavior By default, the project name is the directory name where your compose.yml lives: my-app/ compose.yml docker compose up -d # Creates: my-app-web-1, my-app-db-1, my-app_default network Setting the project name Three ways to set it, in order of precedence: # 1. CLI flag (highest precedence) docker compose -p myproject up # 2. Environment variable COMPOSE_PROJECT_NAME=myproject docker compose up # 3. In the Compose file itself # compose.yml name: myproject services: web: image: nginx The name key in the Compose file is the recommended approach, it’s versioned with your code and everyone on the team gets the same project name. ...

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: ...