depends_on, Healthchecks & the CLI Workflow

The depends_on Gotcha

Plain depends_on only guarantees START order — db's container starting, not necessarily db being ready to accept connections yet. Pair it with a healthcheck and condition: service_healthy for a real readiness guarantee, rather than relying on the app's own retry logic alone.

Core Commands

docker-compose up -d          # start everything, detached
docker-compose up --build     # rebuild images first — needed after Dockerfile changes
docker-compose logs -f web    # stream logs from one service
docker-compose stop           # stop containers, keep them (fast resume with `start`)
docker-compose down           # stop AND remove containers/networks
docker-compose down -v        # also remove named volumes

up alone won't pick up a changed Dockerfile — needs --build or a separate `docker-compose build` first. down is a fuller teardown than stop; add -v to also wipe volumes when you genuinely want a clean slate.

Restart Policies

restart: unless-stopped (or always) auto-restarts a crashed container without manual intervention — more relevant for a long-running deployment than for everyday local dev where a developer restarts things manually anyway.

Compose vs. Kubernetes

Compose runs on a single machine with no built-in auto-scaling, multi-node distribution, or self-healing across host failures — Kubernetes provides those for genuine production-scale, distributed deployments. Many teams use Compose for local dev (simple, one command, reproducible across the team) and Kubernetes for production — matching tool complexity to each environment's actual needs.