Compose Profiles

Assigning and Activating Profiles

A profile gates a service so up starts only what you mean:

services:
  backend: { image: backend }
  db:      { image: mysql }
  phpmyadmin:
    image: phpmyadmin
    depends_on: [db]
    profiles: [debug]

Services with no profiles key always start; docker compose up here brings up backend and db only. Activate with --profile debug or COMPOSE_PROFILES=debug (comma-separated for several, --profile "*" for all). Profile names must match [a-zA-Z0-9][a-zA-Z0-9_.-]+. The rule of thumb from Docker's own docs: keep core services unprofiled so they are always enabled.

Targeting and Dependencies

Naming a service on the command line bypasses its profile:

docker compose run db-migrations

Even though db-migrations is gated behind tools, targeting it runs it directly — and its depends_on chain starts too. Everything else sharing the tools profile stays off unless you also pass --profile. This is the documented pattern for one-off jobs: migrations, seeders, and debug tools live behind a profile, get invoked by name, and never accidentally join a plain up.

Corollary: dependencies of a targeted profiled service must be unprofiled, in the same profile, or started separately — Compose will not enable an arbitrary third profile for you.

Pitfalls and Interview Angles

down scope surprises. docker compose down removes only unprofiled services; stopping profiled ones needs --profile (or down <service>). Stale containers confuse the next deploy.

Profiles as environment switch. They are for optional service groups, not per-environment config — that is what override files are for. Mixing the two makes config output hard to reason about.

Naming. debug, tools, metrics read better than extra; each name should map to a workflow a teammate already runs.

Interview: state the activation matrix (plain up, --profile, named run), then defend why phpmyadmin sits behind debug instead of starting by default.