Quick Reference · containers & images

docker cli cheat sheet

Every command moves software through five places: a Dockerfile, a built image, a running container, a registry (Docker Hub), and shared infrastructure (volumes, networks, Compose). Learn the map once and the commands stop being a list to memorize.

Dockerfile / build image container registry volumes / network / compose destructive most common

Distilled & cross-checked across: docs.docker.com · docker.com/resources/cli-cheat-sheet · buddy.works · devopscycle.com · github.com/wsargent/docker-cheat-sheet · dockerlabs.collabnix.com

The five areas & the commands that move work between them
Dockerfile recipe — you write this FROM / RUN / COPY CMD / EXPOSE Image read-only template, layered docker images Container a running instance of an image docker ps Registry Docker Hub or private registry docker search docker build docker run docker push stop / rm docker pull (downloads an image from a registry) YOUR REPO YOUR HOST THE CLOUD
01Build & Manage ImagesDockerfile → image
02Run Containersimage → container
03Inspect & Managethe daily loop
04Stop & Removeend the lifecycle
05Registry & Docker Hubshare images
06Volumespersist data
07Networkscontainer ↔ container
08Docker Composemulti-container apps
09System & Cleanupreclaim disk space
10Help & Infoeverywhere
Refer to an Objectanywhere you see <container>/<image>

Container lifecycle & core concepts

Four shapes worth holding in your head — based on the reference diagrams used across the official Docker docs and the community cheat sheets.

Container state machine

A container moves through a small set of states; most commands are just verbs that flip it from one box to the next.

created running paused stopped removed start pause stop rm

Image layers

Each Dockerfile instruction adds a read-only layer. A running container adds one thin writable layer on top.

FROM ubuntu:24.04 RUN apt-get install … COPY . /app CMD ["node","app.js"] writable container layer

Volumes vs. bind mounts

Both persist data outside the container's writable layer — but who manages the storage differs.

container named volume docker managed host path you manage it -v myvol:/data -v /host/path:/data

Default network drivers

Most setups never leave bridge — but knowing the other two saves a debugging session someday.

bridge default · isolated C + port mapping (-p) host shares host network C no -p needed none fully isolated C no networking

Dockerfile instructions

The vocabulary the docker build command reads, top to bottom, to assemble an image.

FROMbase image to build on top of
RUNexecute a command, bakes a new layer
COPYcopy files from build context into the image
ADDlike COPY, plus URL/tar-extract support
WORKDIRset the working directory for later instructions
ENVset an environment variable at build & run time
ARGbuild-time-only variable
EXPOSEdocument the port the app listens on
VOLUMEdeclare a mount point for persistent data
CMDdefault command when container starts (overridable)
ENTRYPOINTfixed executable; CMD becomes its arguments
USERswitch to a non-root user for later steps

Worth memorizing

pull → run → ps → stop → rmthe everyday workflow, start to finish
CMD vs ENTRYPOINTCMD is overridable defaults; ENTRYPOINT is fixed
-d vs -itdetached background vs. attached interactive
image ≠ containerimage is the template; container is a running copy
stop vs killstop is graceful (SIGTERM); kill is immediate (SIGKILL)
volume vs bind mountDocker manages volumes; you manage bind-mount paths
rm -fstops a running container before removing it — no confirm
system prune -a --volumesnukes everything unused — read the prompt first