Docker Compose Commands Cheat Sheet

A README tells you Compose has 40-plus subcommands and a page of flags for each one. In practice, running nine stacks on one homelab host means reaching for about eight of them, daily, and ignoring the rest until a specific problem forces you to look them up.

The Commands You Actually Run Daily

Per the official Compose CLI reference, each of these takes an optional [SERVICE] argument unless noted — that distinction matters more than the command itself once you're running more than one container per stack.

Command	What it does	When you reach for it
up -d	Creates and starts all containers in the background	Bringing a stack up after a pull or a config change
logs -f <service>	Tails live output for one service	Watching a container boot or diagnosing an error in real time
exec <service> sh	Opens a shell inside a running container	Checking a file, env var, or process inside the container
ps	Lists this project's containers and their state	Confirming everything is actually running, not restarting
pull <service>	Downloads the latest image for one service	Updating a single app without touching its database or cache image
restart <service>	Stops and starts one service's container	Picking up a config change that doesn't need a full up
down	Stops and removes containers and networks (not volumes)	Tearing a stack down cleanly, e.g. before a docker compose up --build
config -q	Validates and resolves the file; prints nothing if clean	Catching a YAML or interpolation mistake before up ever runs

That's the working set. Everything else — top, images, cp, port, events, kill — exists, gets used maybe a handful of times a year, and is worth knowing exists rather than memorizing.

Scoping a Command to One Service in a Shared File

This is the part most references skip, because they document each command in isolation instead of in the context of a file with five or six services in it. Four of the commands above change behavior depending on whether you name a service:

docker compose pull          # pulls the image for every service in the file
docker compose pull app      # pulls only app's image — db, redis, etc. untouched

The same pattern holds for logs, restart, and exec:

docker compose logs -f app     # only app's log stream
docker compose restart app     # only app's container restarts
docker compose exec app sh     # shell into app specifically

I run docker compose pull app && docker compose up -d app as a pair whenever one service in a stack ships a new image — it updates exactly that container, confirms the image moved to a healthy state, and leaves the database container's uptime (and its "ready" state from the depends_on article) completely undisturbed.

up vs up -d vs up --build

Plain docker compose up runs in the foreground and streams every container's logs into your terminal until you Ctrl-C it — useful for a first run where you want to watch things boot, useless for anything you intend to leave running. up -d detaches immediately. up -d --build rebuilds any service with a build: key before starting it, which you need after editing a Dockerfile but never after only editing docker-compose.yml itself — a plain up -d already picks up YAML changes.

Reading Logs Without Drowning in Them

docker compose logs -f <service> without a service name interleaves every container's output into one stream, timestamped but not visually separated — fine for a two-service stack, unreadable for anything larger. Add --tail 100 to start from recent output instead of replaying the full history on every follow. If a single logs -f session isn't enough to find the actual failure, that's the point where our guide to debugging a broken Compose stack picks up — it covers the next layer once logs alone don't explain the symptom.

Stopping vs Removing: down, stop, kill

One line, because the full breakdown already exists elsewhere on this site: stop halts containers but keeps them (and the network) in place for a fast start; down removes both containers and networks, which is what you want before rebuilding from a changed Compose file; kill skips the graceful shutdown signal entirely and should be reserved for a container that's actually hung. Our down vs stop vs kill guide covers when each one is the correct choice, with the exit-code and signal detail this cheat sheet doesn't repeat.

config: The Command Everyone Skips

docker compose config -q resolves every ${VAR} interpolation, merges any override files, and validates the whole thing — then prints nothing at all if it's clean. Per the Compose CLI reference, a non-zero exit code means the file failed to parse or resolve, which makes it the cheapest possible check to run before up rather than after a stack fails to come up the way you expected.

FAQ

What are the most common docker compose commands?

up -d, logs -f <service>, exec, ps, pull, restart <service>, down, and config -q cover the large majority of day-to-day operation on a real homelab stack.

How do I run a docker compose command for only one service?

Add the service name as the final argument: docker compose logs -f app, docker compose restart app, docker compose pull app, and docker compose exec app sh all scope to just that one container.

What is the difference between docker compose up and docker compose up -d?

Plain up runs in the foreground and streams every container's logs to your terminal until you stop it. up -d starts the same containers detached, in the background — the form you want for anything meant to keep running.

How do I update just one service's image without pulling everything?

Name the service: docker compose pull app instead of docker compose pull. Without a service name, Compose pulls the image for every service defined in the file.

What does docker compose config do?

It resolves the compose file — merging override files and interpolating .env variables — and validates the result without starting any containers. Run with -q for a silent pass/fail check before up.

The Bottom Line

The other 30-plus Compose subcommands aren't wrong to document, they're just not what gets typed on a Tuesday. Eight commands, and the habit of naming a service when you mean one service instead of all of them, cover the real daily operation of a multi-stack homelab. For the stack layout and reverse-proxy setup these commands operate on, the self-hosting guide covers the rest; when one of these commands surfaces a problem instead of solving it, the debugging guide is the next step.