Docker CLI and Compose Commands: A Cheat Sheet

Most Docker work is a small set of commands applied in the same few situations: start something, check on it, look at its logs, get inside it, tear it down. The value of a cheat sheet is not the individual commands — you can look those up — but the shape of the workflow: which command belongs to which stage of a container's life, and which flags save you the tenth command. This guide groups the docker CLI and docker compose commands exactly that way, with the fast paths that turn a debugging session into a two-command sequence.

Create and Run Containers

The four verb forms matter even though they read similarly. docker create prepares a container without starting it; docker run creates and starts in one step; docker start resumes a stopped one; docker restart stops and starts. For interactive work on an image, docker run -it runs one command with a terminal attached.

# One-shot command from an image (no long-running container)
docker run --rm -it debian:bookworm-slim bash

# Detached long-running service, named, published, with restart policy
docker run -d --name web -p 8080:80 --restart unless-stopped nginx:alpine

# Attach to a running container for a throwaway command
docker exec -it web sh
docker exec web nginx -t   # validate config without entering

--rm is the anti-clutter default for anything temporary: the container deletes itself on exit, which keeps a workstation full of abandoned test containers from becoming the norm. docker exec is how you get inside without altering the container's primary command.

Observe What Is Running

Before debugging anything, establish the facts: what exists, in what state, since when.

docker ps -a
docker ps --filter "status=exited"
docker run -d --name web -p 8080:80 nginx:alpine

# A container's only job is to keep the name free
docker stop web
docker start web
docker logs --tail 100 -f web

docker ps -a includes stopped containers, which is where "where did my postgres go" turns out to be an exited container, not magic deletion. docker logs --tail 100 -f is the two-flag form of "give me the last hundred lines and keep following".

Investigate When Something Is Wrong

The three-investigator set is inspect, top, and events. docker inspect returns the full JSON state — config, mounts, network settings, exit code, health — and its --format flag lets you pull a single field without the firehose. docker top shows the container's actual process list, and docker events streams engine-level activity from another terminal while you reproduce the bug.

docker inspect web --format 'state={{ .State.Status }} exit={{ .State.ExitCode }}'
docker inspect web --format 'image={{ .Config.Image }} cmd={{ .Config.Cmd }}'
docker top web
docker stats
docker events --filter container=web

docker stats is the always-on resource dashboard, and pairing it with docker events turns "it died" into "what was it doing when it died". Remember that container logs are only what the application wrote to stdout and stderr — a process that crashes before logging writes nothing, and a missing log is itself a diagnosis.

Images, Volumes, and Networks Housekeeping

docker pull nginx:alpine
docker build -t my-app:1.2.3 .
docker tag my-app:1.2.3 registry.example.org/my-app:latest
docker rmi my-app:old
docker image prune

docker volume create backups
docker volume ls
docker network create appnet
docker network inspect appnet
docker system df

docker image prune removes dangling images (the ones replaced by newer tags), while docker system df shows where everything went — images, containers, volumes, and the build cache in one table. Pruning images without ever pruning volumes is the common blind spot: volumes can hold gigabytes of abandoned database files that no container references.

The Compose Lifecycle in eight commands

Compose wraps the same lifecycle in project-level verbs that act on every service at once.

docker compose up -d
docker compose up -d --build
docker compose ps
docker compose logs -f web
docker compose exec web sh
docker compose restart web
docker compose down
docker compose config

compose up -d brings the whole stack up detached; adding --build rebuilds changed images first. compose logs -f web follows one service's stream, compose exec runs a command in a running service, and compose down tears the whole stack down — but by default leaves named volumes alone, so your database state survives unless you ask for -v. Before trusting any of it, compose config prints the fully-resolved file, which is the review step that catches a typo before it becomes a four-container teardown.

The Fast-Forward Happiness Pattern

The sequence that covers most days in three commands: docker compose ps to see what is broken, docker compose logs --tail 100 -f SERVICE to see why, docker compose up -d to bring it back. When a container refuses to start, those same first two commands plus docker inspect --format '{{ .State.ExitCode }}' SERVICE reveal whether the problem is a config error (exit 1 fast, log line present) or a runtime crash (nonzero exit, log gone silent).

Takeaway

Docker's CLI is a lifecycle, not a grab bag: create with run and up, observe with ps and logs, investigate with inspect and exec, remove with stop and down. Learning the commands as stages — not as a flat list — means you always know which verb comes next. The same workflow runs identically on any VPS you control, and on a Netbay host you get it with fresh Docker-ready disk in under a minute, so the cheat sheet above pays off from your very first container — netbayhosts.in.