A Compose file often defines more services than a given task needs: a database, a cache, a queue, a mock billing service. Profiles let you tag services so they start only when you ask for that profile, which keeps the default up fast and resource-light.
Before you start
You should be comfortable with docker compose and a compose file. This article covers profiles and service selection.
Step-by-step walkthrough
Step 1: Tag optional services with a profile
Add profiles: [tools] to a service so it is excluded from the default set. Services without a profile always start. This lets the everyday services run with a plain up while the extras wait behind a name.
Step 2: Start the profile you need
docker compose --profile tools up starts the default services plus those tagged tools. Profiles can be combined, so --profile tools --profile debug enables both sets for a heavier session.
Step 3: Keep the default minimal
The default set should be the services needed for the core loop, so a new developer can start quickly. Put heavyweight or rarely used services behind profiles, and document which profile each one belongs to.
Worked scenario
Optionals run only with their profile.
services:
web:
image: app
mailhog:
image: mailhog/mailhog
profiles: [tools]Walk through the example
docker compose up starts only web, so the default is light. docker compose --profile tools up also starts mailhog. A developer who needs to test email opts in, while everyone else avoids the extra container.
Common mistake
Putting a required service behind a profile, so up starts an incomplete stack and the app fails in confusing ways. Another is not documenting profiles, so developers run everything “just in case” and pay the cost.
Verify the behavior
Run docker compose up and confirm only unprofiled services start. Add the profile flag and confirm the extra service appears. List the running services and check the default set matches the intended core.
Interview exercise
When is a profile better than a separate compose file?
Answer and reasoning
A profile keeps one file and one mental model while still selecting services, so shared definitions are not duplicated across files. Separate files suit genuinely different environments with different configuration. Use a profile when the difference is just which optional services run.
Continue learning
Compare dependencies in Compose dependencies and images in Docker image tags. Read the Docker Compose profiles documentation and try the Docker interview questions.