Docker Compose profiles for optional services

WHAT THIS TESTS This checks whether you know how to include optional, situational services in one Compose project without them running on every up, avoiding file duplication.

A GOOD ANSWER COVERS The profiles key tags a service with one or more named profiles. Any service that has at least one profile is not started by a plain docker compose up; only services without a profile start by default. You opt into a profile with docker compose --profile debug up or by setting COMPOSE_PROFILES=debug,tools in the environment, and multiple profiles can be enabled at once. Explicitly naming a profiled service on the command line also starts it and pulls in its declared dependencies even if their profile is not active. This keeps the core stack lean while letting developers enable extras on demand.

COMMON WRONG ANSWERS Thinking a service with a profile still starts by default. Confusing profiles with environments or with the override-file mechanism. Maintaining a second compose file just to hold optional tooling. Assuming enabling a profile disables the default services.

LIKELY FOLLOW-UPS What happens to dependencies of a profiled service? Can a service belong to multiple profiles? How does COMPOSE_PROFILES interact with --profile? How do profiles differ from override files?

ONE CONCRETE EXAMPLE In one compose.yaml, the api and db services have no profile so they always run. A mailhog service for catching outbound email gets profiles: ["debug"], and a pgadmin database UI gets profiles: ["tools"]. A normal docker compose up brings only api and db. When a developer needs to inspect emails they run docker compose --profile debug up, adding mailhog; setting COMPOSE_PROFILES=debug,tools in their shell brings up everything at once. The production-like default stays minimal.