docker compose up
`docker compose up` is the command that starts everything described in compose.yaml. Behind the simple verb are flags that affect every part of the dev loop: detach vs foreground, build vs use-cached image, recreate vs reuse, log streaming, scaling. Knowing the flags removes "why is my container still running yesterdays code?" from your morning.
docker compose up flags + a fast dev loop
EXAMPLE
# 1) Start everything in the foreground (logs streaming to your terminal) docker compose up # 2) Detach — start in the background, return immediately docker compose up -d # 3) Rebuild images before starting (after a Dockerfile change) docker compose up -d --build # 4) Recreate containers even if config did not change docker compose up -d --force-recreate # 5) Only rebuild + recreate ONE service (faster than the whole stack) docker compose up -d --build --force-recreate api # 6) Tear it down (containers + network, keeps named volumes) docker compose down # 7) Also remove volumes (DANGEROUS — kills data) docker compose down -v # 8) Scale a service horizontally (works only for services without published ports collisions) docker compose up -d --scale worker=4 # 9) Bring services up but skip dependencies (debug a specific service) docker compose up -d --no-deps api # 10) Pull newer image versions before starting (no build, just pull) docker compose pull docker compose up -d --no-build # 11) Project name — multiple stacks side-by-side docker compose -p shop-test up -d # everything is namespaced 'shop-test' docker compose -p shop-test down # 12) Multiple compose files — merge in order (base + override) docker compose -f compose.yaml -f compose.dev.yaml up -d docker compose -f compose.yaml -f compose.prod.yaml up -d # 13) Pass env vars at startup DB_PASSWORD=secret docker compose up -d # Or write them to a .env file (auto-loaded by Compose) # 14) Inspect what is running docker compose ps docker compose ps --status running # 15) Tail logs — best dev companion docker compose logs -f api worker docker compose logs --since 5m # 16) Exec into a running container docker compose exec api sh docker compose exec db psql -U shop shop # 17) Run a one-off command (NEW container, then exits) docker compose run --rm api npm test docker compose run --rm api node ./scripts/migrate.js # 18) Restart only one service (e.g. after editing a mounted config) docker compose restart proxy # 19) Pause / unpause for a clean snapshot docker compose pause db docker compose unpause db # 20) Watch + rebuild on file change (Compose v2.22+) docker compose watch # Configure in compose.yaml: services.api.develop.watch — copy paths into the container, # or rebuild on changes to specific globs. Removes the need for nodemon-in-a-container. # 21) Decision tree # - Started everything once, now changed code only: docker compose restart <svc> # - Changed Dockerfile: docker compose up -d --build <svc> # - Containers refuse to pick up new env: docker compose up -d --force-recreate # - Want a fresh database state: docker compose down -v && docker compose up -d # - CI run: docker compose up -d --build --wait # (--wait blocks until all services with healthchecks report healthy.)
Why it matters
`docker compose up -d --wait --build` is the right CI invocation: rebuild fresh images, run detached, return only when every healthcheck reports healthy. The exit code reflects success — perfect for `&& npm test`. Run it interactively (no --wait) in dev so you can ctrl-C out, but the --wait flag is what makes Compose CI-friendly.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Exercise
Bring up a compose project in the background.
docker compose
-d
Two letters.
Discussion
Loading…