Cheat sheet

Docker CLI

Containers, images, volumes, networks, Compose, and cleanup — the daily-driver commands.

Containers

# Run detached with port mapping
docker run -d --name web -p 8080:80 nginx:alpine

# Run interactively, remove on exit
docker run -it --rm ubuntu:24.04 bash

# List running / all containers
docker ps
docker ps -a

# Stop, start, remove
docker stop web && docker rm web

# Exec into a running container
docker exec -it web /bin/sh

# Resource limits
docker run -d --memory=512m --cpus=1.5 my-app

Images

# Build with a tag
docker build -t my-app:v1 .

# Build for a different platform
docker build --platform linux/amd64 -t my-app:v1 .

# List, tag, push
docker images
docker tag my-app:v1 registry.example.com/my-app:v1
docker push registry.example.com/my-app:v1

# Pull a specific digest (immutable)
docker pull nginx@sha256:abc123...

# Remove dangling images
docker image prune

Logs & debugging

# Follow logs with timestamps
docker logs -f --timestamps web

# Last 100 lines
docker logs --tail 100 web

# Live resource usage
docker stats

# Processes inside a container
docker top web

# Inspect anything (IP address example)
docker inspect -f '{{.NetworkSettings.IPAddress}}' web

# What changed on the filesystem
docker diff web

Volumes & networks

# Named volume
docker volume create mydata
docker run -v mydata:/data my-app

# Bind mount
docker run -v $(pwd)/config:/etc/app:ro my-app

# Create a network and attach containers
docker network create appnet
docker run -d --network appnet --name db postgres:17
docker run -d --network appnet my-app  # reaches db by name

# Clean up unused volumes / networks
docker volume prune
docker network prune

Compose essentials

# Start / stop the stack
docker compose up -d
docker compose down

# Rebuild after Dockerfile changes
docker compose up -d --build

# Logs for one service
docker compose logs -f api

# Run a one-off command
docker compose run --rm api ./manage.py migrate

# Scale a service
docker compose up -d --scale worker=3

Copy, export & registry

# Copy files in / out
docker cp ./app.conf web:/etc/app/
docker cp web:/var/log/app.log ./

# Image as tarball (air-gapped transfer)
docker save my-app:v1 | gzip > my-app.tar.gz
docker load < my-app.tar.gz

# Container filesystem snapshot
docker export web > web-fs.tar

# Login to a private registry
docker login registry.example.com

Cleanup

# Disk usage breakdown
docker system df

# Remove stopped containers, unused networks,
# dangling images and build cache
docker system prune

# Also remove unused images and volumes (careful!)
docker system prune -a --volumes

# Remove everything matching a filter
docker container prune --filter "until=24h"
docker image prune -a --filter "until=168h"

Build cache & multi-stage

# Build without cache
docker build --no-cache -t my-app:v1 .

# Target a specific stage
docker build --target builder -t my-app:build .

# BuildKit cache mounts (in Dockerfile)
# RUN --mount=type=cache,target=/root/.cache pip install -r requirements.txt

# Inspect image layers and sizes
docker history my-app:v1

# Why is my image huge?
docker history --no-trunc my-app:v1 | head -20

Going deeper

Full walkthroughs in the Docker tutorial series: Fundamentals, Multi-stage builds, and Compose.

Writing images? See Dockerfile Best Practices; on a daemonless stack, the Podman cheat sheet mirrors this one.

About the Docker CLI Cheat Sheet

The Docker CLI is broad, and day-to-day work uses a small fraction of it. What separates comfortable use from constant searching is knowing which subcommand owns which noun — containers, images, volumes and networks each have their own management group, and the top-level shortcuts are aliases into them.

The commands worth internalising early are the diagnostic ones rather than the run ones. Inspecting a container's configuration, reading logs with a follow flag, executing a shell inside a running container, and listing what is actually consuming disk will resolve most problems you meet.

Disk usage is the recurring operational surprise. Stopped containers, dangling images, build cache and unused volumes accumulate quietly until a machine runs out of space, usually at an inconvenient moment. Knowing the difference between pruning images and pruning volumes matters, because one of those can delete data you wanted.

Frequently asked questions

Where did my disk space go?

Ask Docker directly with the system disk usage command, which breaks down images, containers, local volumes and build cache. Build cache is frequently the largest and least expected entry on a machine that builds often. Prune deliberately by category rather than reaching for a blanket cleanup, because volume pruning removes data.

What is the difference between stopping and removing a container?

Stopping halts the process but keeps the container's writable layer, so it can be started again with its filesystem changes intact. Removing deletes that layer permanently. A stopped container still consumes disk, which is why lists showing only running containers hide a common source of usage.

How do I get a shell in a container that has no shell?

Minimal and distroless images often have no shell at all, which is a security feature rather than an oversight. Attach a debug container that shares the target's namespaces, giving you tools without adding them to the image. On Kubernetes this is ephemeral debug containers; with Docker it means running a second container that joins the first's namespaces.

Why can my container not reach another container by name?

Name resolution only works on user-defined networks, not the default bridge. Create a network and attach both containers, or use Compose, which creates one automatically and makes service names resolvable. This is the most common cause of connection failures between containers that look correctly configured.

Do I lose data when a container is removed?

Anything written to the container's writable layer is lost. Data in a named volume or a bind mount survives, because it lives outside the container's lifecycle. If data must persist, put it in a volume deliberately rather than relying on the container continuing to exist.