Compose day to day

The five commands you actually use

docker compose up -d          # create and start everything in the background
docker compose ps             # status of this project's services
docker compose logs -f app    # follow one service's logs
docker compose up -d --build  # rebuild images that changed, then restart
docker compose down           # stop and remove containers and the network

Three notes save real pain. up is idempotent, so running it again only recreates services whose config or image changed. After editing code, --build is required, otherwise compose happily reuses the stale image from the last build in lesson 3-1.

And down keeps named volumes by default, so the database from lesson 4-1 survives. down -v deletes volumes too, which is the reset-everything button, worth saying out loud before pressing it.

A recorded session

The session below walks the day-to-day loop on the shop app from lesson 5-1.

Each step below shows the command and the output it printed.

Step 1. Booting the whole stack in the background.

~/shop $ docker compose up -d
[+] Running 3/3
 ✔ Network shop_default  Created
 ✔ Container shop-db-1   Started
 ✔ Container shop-app-1  Started

Step 2. Checking that both services are up.

~/shop $ docker compose ps
NAME         IMAGE         COMMAND                  SERVICE   STATUS         PORTS
shop-app-1   shop-app      "python server.py"       app       Up 8 seconds   0.0.0.0:8080->8000/tcp
shop-db-1    postgres:16   "docker-entrypoint.s…"   db        Up 9 seconds   5432/tcp

Step 3. Follow the app service's logs.

~/shop $ docker compose logs -f app
shop-app-1  | connected to postgres at db:5432
shop-app-1  | listening on port 8000

Step 4. You edited server.py. Rebuild and restart whatever changed.

~/shop $ docker compose up -d --build
[+] Building 1.2s (10/10) FINISHED
[+] Running 2/2
 ✔ Container shop-db-1   Running
 ✔ Container shop-app-1  Started

Step 5. Done for the day. Tear it down, keeping the database volume.

~/shop $ docker compose down
[+] Running 3/3
 ✔ Container shop-app-1  Removed
 ✔ Container shop-db-1   Removed
 ✔ Network shop_default  Removed

An edit that never reached the image

Editing server.py, running docker compose up -d, and still seeing old behavior means compose reused the previously built image. The missing piece is --build.

Plain up -d reuses existing images, and the edit exists only in the build context, not in an image built before the edit happened.

The rebuild is cheap thanks to the layer cache from lesson 3-3, since only the code copy layer and everything after it are invalidated. Many teams simply type --build every time for that reason.

A true factory reset

For a dev database full of broken test data, the command is docker compose down -v, because plain down deliberately preserves named volumes.

down removes containers and the network but keeps named volumes, which is the safe default since data usually should survive a teardown. The -v flag adds volume deletion.

Because it destroys data, this is a command worth saying out loud before pressing enter, and it should never run against anything production-like. There is no undo, and the volume contents are not in the image.

Tearing down without losing data

The command is docker compose down.

It is the opposite of up, and it needs no extra flags because volumes survive by default. It removes containers and the auto-created network while preserving named volumes, so data such as the lesson 4-1 database stays put.

The default direction is deliberate. Compose treats containers and networks as cheap and rebuildable, and volumes as the one thing that might be irreplaceable.