Docker Compose for Local Dev
Docker & Kubernetes for Interviews: lesson 4 of 12
One file, one command, a whole app — as long as it fits on one Docker host.
Lesson 4 of 12 · 6 min
Docker Compose for Local Dev
Step 1 of 10
One file describes the whole app: two services, a volume, and who waits for whom.
The Idea
A compose.yaml declares an app's services, networks and volumes in one file, and docker compose up starts them together. Compose puts every service on a default network where each is reachable by its service name. depends_on orders startup, but by default waits only for a container to run, not to be ready.
Real-World Example
An API and Postgres come up with one command. The API reaches the database at db:5432 — the container port, not the host port — and waits for it with condition: service_healthy and a pg_isready healthcheck.
The Tradeoff
Compose drives a single Docker Engine: ideal for development and CI, but spreading replicas across machines and rescheduling them when one dies is what an orchestrator like Kubernetes adds. docker compose down removes containers and the network but keeps named volumes unless you pass -v.
Hands-On
# illustrative — compose.yaml for local development
services:
api:
build: .
ports: ["8080:8000"]
environment: { DATABASE_URL: "postgres://postgres:dev@db:5432/postgres" }
depends_on:
db: { condition: service_healthy }
db:
image: postgres:17
environment: { POSTGRES_PASSWORD: dev }
healthcheck: { test: ["CMD-SHELL", "pg_isready -U postgres"], interval: 5s }
volumes: ["pgdata:/var/lib/postgresql/data"]
volumes:
pgdata: {}
Your turn
Put the steps in the right order.
- The healthcheck passes: db is healthy
- docker compose up creates the project's default network
- api starts and connects to db:5432
- db starts and its healthcheck begins
Mini quiz
1 / 3
Inside a Compose project, the API should reach the database at:
Sources
- How Compose works — Docker Docs
- Networking in Compose — Docker Docs
- Control startup and shutdown order — Docker Docs
- docker compose down — Docker Docs