iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

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

Example
docker compose up -d
docker compose logs -f api
docker compose down
Try it Yourself »

Exercise

Bring up a compose project in the background.

docker compose -d

Discussion

Loading…