Configuration

Almost every Compose CLI flag has an environment-variable counterpart. Setting them once in a project .env file, in your shell, or in CI removes the need to retype the same flags on every command — and makes the configuration of a stack visible to anything that reads the environment. The core set The variables you reach for most often: Variable What it sets CLI equivalent COMPOSE_FILE Path(s) to the Compose file(s) -f, --file COMPOSE_PATH_SEPARATOR Separator when listing multiple files (in COMPOSE_FILE) COMPOSE_PROJECT_NAME Project name -p, --project-name COMPOSE_PROFILES Profiles to enable --profile COMPOSE_ENV_FILES Project-level env files --env-file COMPOSE_PARALLEL_LIMIT Max parallel operations --parallel (on some subcommands) COMPOSE_IGNORE_ORPHANS Don’t warn about orphan containers (no flag) COMPOSE_REMOVE_ORPHANS Always remove orphans on up/down --remove-orphans COMPOSE_ANSI Control ANSI output (auto, never, always) --ansi COMPOSE_PROGRESS Progress style (auto, tty, plain, json, quiet) --progress COMPOSE_STATUS_STDOUT Send status messages to stdout instead of stderr (no flag) COMPOSE_MENU Disable the interactive Docker Desktop menu (no flag) The full list lives in the Compose docs. The table above covers the ones that show up in real workflows. ...

Named volumes are great for keeping data alive across container restarts. The default behavior mounts the entire volume root at the container target. Sometimes you want to mount only a sub-directory — for instance, a single service among many sharing the same named volume, each scoped to its own directory. The subpath option does exactly that. The basic shape services: app: image: myapp volumes: - type: volume source: shared-data target: /app/data volume: subpath: app volumes: shared-data: The named volume shared-data exists once on the host. The app container sees only the app/ directory of it mounted at /app/data. Other directories in shared-data are invisible to app. ...

By default, Compose pulls an image when it’s missing locally and uses the cached one otherwise. pull_policy lets you change that behavior per service. The policies services: web: image: nginx pull_policy: always Available values: missing (default when no build: is defined): pull only if the image is not present locally. Alias: if_not_present. Note: the latest tag is always pulled even with this policy. always: pull on every up, even if the local image is recent never: don’t pull, fail if the image is missing build: build the image, rebuilds even if it’s already present locally daily: check the registry if the last pull was more than 24 hours ago weekly: check the registry if the last pull was more than 7 days ago every_<duration>: check the registry if the last pull was older than the given duration. Units: w, d, h, m, s (or any combination, e.g. every_12h, every_30m, every_1d12h) When to use each always for development against a fast-moving tag: ...

Not everything in your stack is a container. Managed databases, SaaS APIs, VPN tunnels, Kubernetes intercepts, all sit outside Docker but still need to be wired into your local environment. Compose 2.36 introduced provider services to declare and manage these alongside your containers. The syntax A provider service replaces image: with a provider: block: services: api: image: my-api:latest tunnel: provider: type: telepresence options: namespace: avatars service: api port: 5732:api-80 Two parts: ...

LLMs are now first-class citizens in Compose. The models top-level key lets you declare which models your application needs and wire them into your services, all in the same Compose file. Basic usage Declare a model at the top level, reference it from a service: models: smollm: model: ai/smollm2 services: app: image: myapp models: - smollm When the stack starts, Compose ensures the model is available locally and connects the app service to it. The container receives endpoint information via environment variables. ...