CONTAINERS Updated 2026-07-05 49+ commands Verified against official docs

Docker Cheat Sheet

48 Docker commands with flags, real-world use cases, and gotchas. Searchable and filterable. Verified against official Docker docs.

Ctrl+K

Everything runs in your browser. No commands or data are sent to any server.

New to Docker? Start with these

5 essential commands to get you started. The full reference is right below.

Run a container

docker run -d --name myapp -p 8080:80 nginx:1.27

Start a new container from an image, mapping ports and mounting volumes as needed for local development.

List running containers

docker ps

Check what's currently running before starting a duplicate container or debugging why a port is already in use.

View container logs

docker logs -f myapp

Read stdout and stderr from a running or recently stopped container to debug a startup failure.

Run a command in a running container

docker exec -it myapp sh

Get a shell inside a running container to inspect files, test connectivity, or run diagnostic commands.

Start services defined in a compose file

docker compose up -d

Bring up an entire multi-container stack, like an app plus its database and cache, with one command.

49 commands

Build an image

Beginner
docker build -t myapp:latest .

↓ Click command to explain

-t Tag the built image with a name and optional tag, e.g. myapp:latest
-f Use a Dockerfile at a path other than ./Dockerfile

When to use this

Build a container image from a Dockerfile before pushing it to a registry or running it locally.

Gotcha

The dot at the end is the build context. It is not optional, and sending a large directory as context slows every build. Add a .dockerignore file to exclude node_modules and other large directories.

List local images

Beginner
docker images

↓ Click command to explain

When to use this

See every image pulled or built locally, along with size, to find what's eating disk space.

Pull an image from a registry

Beginner
docker pull nginx:1.27

↓ Click command to explain

When to use this

Download a specific image and tag before running it or as part of a CI pipeline warm-up step.

Push an image to a registry

Beginner
docker push myrepo/myapp:latest

↓ Click command to explain

When to use this

Publish a locally built image to a registry like Docker Hub or a private ECR/GCR repository.

Tag an image

Beginner
docker tag myapp:latest myrepo/myapp:v1.2.0

↓ Click command to explain

When to use this

Give a locally built image the fully-qualified name a registry expects before pushing it.

Remove an image

Beginner Destructive
docker rmi myapp:latest

↓ Click command to explain

When to use this

Free up disk space by deleting an old or unused image tag.

Gotcha

Fails if any container, running or stopped, still references the image. Remove or prune the container first.

Remove dangling images

Intermediate Destructive
docker image prune

↓ Click command to explain

-a Remove all unused images, not just dangling (untagged) ones

When to use this

Clean up untagged layers left behind by repeated docker build runs during local development.

Gotcha

With -a this removes every image not currently used by a container, not just dangling ones. Check docker ps -a first if you don't want to re-pull anything.

Run a container

Beginner Destructive
docker run -d --name myapp -p 8080:80 nginx:1.27

↓ Click command to explain

-d Run detached in the background instead of attaching to the terminal
-it Allocate an interactive TTY and keep STDIN open, for shells and interactive tools
-p Publish a container port to a host port, host:container
--name Give the container a fixed, memorable name instead of a random one
--rm Automatically remove the container when it exits

When to use this

Start a new container from an image, mapping ports and mounting volumes as needed for local development.

Gotcha

-d runs detached in the background, -it allocates an interactive terminal, and they serve completely different purposes. Using -d then wondering why there is no output is the most common docker run confusion.

List running containers

Beginner
docker ps

↓ Click command to explain

-a Show all containers including stopped ones, not just running

When to use this

Check what's currently running before starting a duplicate container or debugging why a port is already in use.

Gotcha

Shows only running containers by default. Use docker ps -a to see stopped containers, including ones that exited with an error.

List all containers including stopped

Beginner
docker ps -a

↓ Click command to explain

When to use this

Find a container that exited unexpectedly so you can inspect its exit code and logs.

Start a stopped container

Beginner
docker start myapp

↓ Click command to explain

When to use this

Resume a previously stopped container with the same configuration instead of running a new one.

Stop a running container

Beginner Destructive
docker stop myapp

↓ Click command to explain

When to use this

Gracefully stop a container, sending SIGTERM and waiting before force-killing it, such as before a maintenance window.

Gotcha

Waits up to 10 seconds for graceful shutdown by default before sending SIGKILL. Use --time to change the grace period for slow-shutdown apps.

Restart a container

Beginner Destructive
docker restart myapp

↓ Click command to explain

When to use this

Pick up a changed environment variable or config file mount without recreating the container from scratch.

Remove a container

Beginner Destructive
docker rm myapp

↓ Click command to explain

-f Force removal of a running container by stopping it first

When to use this

Delete a stopped container permanently, freeing its name so a new container can reuse it.

Gotcha

Fails on a running container unless you pass -f. This is a safety guard, not a bug.

Create a container without starting it

Intermediate Destructive
docker create --name myapp nginx:1.27

↓ Click command to explain

When to use this

Pre-create a container's filesystem and config to inspect or modify before actually starting it.

View container logs

Beginner
docker logs -f myapp

↓ Click command to explain

-f Stream logs continuously instead of printing a static snapshot
--tail Only show the last N lines
--since Only show logs newer than a relative time or timestamp

When to use this

Read stdout and stderr from a running or recently stopped container to debug a startup failure.

Gotcha

Without -f it prints a snapshot and exits. With -f it streams, but the stream stops if the container restarts, so you'll need to run it again.

View live resource usage

Beginner
docker stats

↓ Click command to explain

When to use this

Watch live CPU, memory, and network usage across all running containers to spot a runaway process.

View running processes in a container

Intermediate
docker top myapp

↓ Click command to explain

When to use this

Check what processes are actually running inside a container without needing a shell inside it.

Inspect a container's configuration

Intermediate
docker inspect myapp

↓ Click command to explain

When to use this

Get the full JSON configuration of a container, including mounted volumes, network settings, and env vars, for deep debugging.

Stream Docker daemon events

Advanced
docker events

↓ Click command to explain

When to use this

Watch real-time daemon-level events like container start, stop, die, and OOM across the whole host.

Run a command in a running container

Beginner
docker exec -it myapp sh

↓ Click command to explain

-it Allocate an interactive TTY for a shell session

When to use this

Get a shell inside a running container to inspect files, test connectivity, or run diagnostic commands.

Attach to a running container's main process

Advanced
docker attach myapp

↓ Click command to explain

When to use this

Attach directly to the container's PID 1 stdin/stdout, useful for interacting with a foreground process.

Gotcha

Detaching with Ctrl-C often kills the container's main process. Use the Ctrl-P Ctrl-Q escape sequence to detach without stopping it.

Copy a file into a container

Intermediate Destructive
docker cp ./local-file.txt myapp:/path/in/container

↓ Click command to explain

When to use this

Push a config file or patched asset into a running container without rebuilding the image.

Copy a file out of a container

Intermediate
docker cp myapp:/path/in/container ./local-file.txt

↓ Click command to explain

When to use this

Pull a log file or generated report out of a container for local inspection.

Show filesystem changes in a container

Advanced
docker diff myapp

↓ Click command to explain

When to use this

See exactly which files were added, changed, or deleted inside a container compared to its base image.

Create a network

Beginner Destructive
docker network create mynetwork

↓ Click command to explain

When to use this

Create a named network so containers can reach each other by service name instead of IP address, which changes on every restart.

List networks

Beginner
docker network ls

↓ Click command to explain

When to use this

See what networks exist before deciding whether to create a new one or reuse an existing one.

Inspect a network

Intermediate
docker network inspect mynetwork

↓ Click command to explain

When to use this

Check which containers are attached to a network and what IPs they were assigned, when containers can't reach each other.

Connect a container to a network

Intermediate Destructive
docker network connect mynetwork myapp

↓ Click command to explain

When to use this

Attach an already-running container to an additional network without recreating it.

Remove a network

Beginner Destructive
docker network rm mynetwork

↓ Click command to explain

When to use this

Clean up an unused custom network left over from a stopped project.

Gotcha

Fails if any container is still attached to the network. Disconnect or remove those containers first.

Create a volume

Beginner Destructive
docker volume create mydata

↓ Click command to explain

When to use this

Create a named, persistent volume for a database container so data survives container recreation.

List volumes

Beginner
docker volume ls

↓ Click command to explain

When to use this

See what named volumes exist on the host, including ones left behind by containers that have since been removed.

Inspect a volume

Intermediate
docker volume inspect mydata

↓ Click command to explain

When to use this

Find the actual host filesystem path backing a named volume for direct inspection or backup.

Remove a volume

Beginner Destructive
docker volume rm mydata

↓ Click command to explain

When to use this

Permanently delete a named volume and all the data stored in it once it's no longer needed.

Gotcha

This permanently deletes all data in the volume with no undo. Double check nothing still depends on it before running this against a shared environment.

Remove unused volumes

Intermediate Destructive
docker volume prune

↓ Click command to explain

When to use this

Reclaim disk space taken up by volumes left behind from containers that were removed without --volumes.

Gotcha

Removes all volumes not attached to any container, including volumes with data you might want. There is no undo, so check docker volume ls first.

Start services defined in a compose file

Beginner Destructive
docker compose up -d

↓ Click command to explain

-d Run all services detached in the background
--build Rebuild images before starting, instead of using cached ones

When to use this

Bring up an entire multi-container stack, like an app plus its database and cache, with one command.

Gotcha

depends_on only waits for a container to start, not for the service inside it to be ready. A database container starting does not mean PostgreSQL is accepting connections yet, so use healthchecks for real readiness waiting.

Stop and remove compose services

Beginner Destructive
docker compose down

↓ Click command to explain

-v Also remove the named volumes declared in the compose file

When to use this

Tear down an entire stack, including containers, networks, and optionally volumes, after finishing local development.

Gotcha

Without -v your named volumes persist, which is usually what you want for databases, but it surprises people expecting a completely clean slate.

Build or rebuild compose services

Beginner
docker compose build

↓ Click command to explain

When to use this

Rebuild service images after changing a Dockerfile without also restarting the containers.

View logs from compose services

Beginner
docker compose logs -f

↓ Click command to explain

-f Stream logs continuously from all services

When to use this

Watch combined, colour-coded logs from every service in a stack at once while debugging a startup issue.

List compose services

Beginner
docker compose ps

↓ Click command to explain

When to use this

Check the status of every service defined in the current compose file.

Run a command in a compose service

Intermediate
docker compose exec web sh

↓ Click command to explain

When to use this

Open a shell inside one specific service from a multi-container compose stack, by service name rather than container ID.

Restart compose services

Beginner Destructive
docker compose restart

↓ Click command to explain

When to use this

Restart every service in a stack, or a single named service, to pick up a config or environment change.

Clean up unused Docker data

Intermediate Destructive
docker system prune

↓ Click command to explain

-a Also remove all unused images, not just dangling ones
--volumes Also remove unused volumes

When to use this

Reclaim significant disk space when a build server or laptop is running low on space from accumulated Docker artifacts.

Gotcha

Removes ALL stopped containers, unused networks, dangling images, and build cache with no undo. On a CI server this is safe to run regularly, but on a development machine it removes months of cached layers and will slow your next build significantly.

Show Docker disk usage

Beginner
docker system df

↓ Click command to explain

When to use this

Check how much disk space images, containers, volumes, and build cache are consuming before deciding whether to prune.

Show Docker system-wide info

Beginner
docker info

↓ Click command to explain

When to use this

Check the storage driver, number of running containers, and daemon configuration when debugging an environment issue.

Show Docker version info

Beginner
docker version

↓ Click command to explain

When to use this

Confirm client and server (daemon) version before troubleshooting an API compatibility issue.

Log in to a registry

Beginner
docker login myregistry.example.com

↓ Click command to explain

When to use this

Authenticate against a private or third-party registry before pulling or pushing images that require credentials.

Gotcha

Credentials are stored in plaintext in ~/.docker/config.json by default unless a credential helper is configured, which is worth knowing on a shared machine.

Save an image to a tar archive

Intermediate
docker save -o myapp.tar myapp:latest

↓ Click command to explain

When to use this

Export an image to a file for transfer to an air-gapped machine with no registry access.

Load an image from a tar archive

Intermediate Destructive
docker load -i myapp.tar

↓ Click command to explain

When to use this

Import an image on a machine that received it via docker save instead of pulling from a registry.

Frequently Asked Questions

Every Docker container goes through the same predictable lifecycle: an image is built or pulled, a container is created from that image, the container runs, and eventually it stops and is either restarted or removed. Understanding this lifecycle explicitly, rather than treating docker run as one big magic command, is what makes the rest of Docker's CLI make sense. docker create allocates the container's filesystem and configuration without starting its main process; docker start actually launches that process; docker stop sends a termination signal and waits for a graceful shutdown; and docker rm deletes the container object entirely, freeing its name for reuse. docker run is simply a convenience wrapper that does create and start in one step, which is exactly why it has such a large flag surface. It's really two commands' worth of options merged together.

The distinction between an image and a container is the second concept every Docker user needs solid before anything else clicks. An image is an immutable, read-only template: a set of filesystem layers plus metadata describing what command to run, what ports to expose, and what environment variables to expect. A container is a running (or stopped) instance of that image, with its own writable layer on top where any runtime changes get written. You can create many containers from the same image, each isolated from the others, the same way you can run many processes from the same compiled binary. This is why docker build only needs to happen once per code change, while docker run can happen many times against that same built image without rebuilding anything.

A recurring point of confusion is running docker ps and seeing nothing, despite being sure a container was started moments earlier. The explanation is almost always that the container already exited. Plain docker ps only lists currently running containers, silently omitting anything that stopped, whether it exited cleanly or crashed. The fix is docker ps -a, which includes stopped containers alongside running ones, and pairing that with docker logs <container> immediately reveals why it exited: a missing environment variable, a failed database connection, or a foreground process that finished and had nothing left to keep the container alive. This single habit, defaulting to -a when something 'disappeared,' resolves a surprising fraction of early Docker confusion.

Docker Compose introduces its own well-known trap around service readiness: depends_on only guarantees that a dependency container has started, not that the service inside it is actually ready to accept connections. A Postgres container can report as started within a second while the database engine itself is still initializing for several more seconds, and an application container that starts immediately after will fail its very first connection attempt even though depends_on was configured correctly. The fix is to define a healthcheck on the dependency and have depends_on wait on that specific health condition instead of just container start, or to build retry logic into the application's own startup sequence. Treating depends_on as a strict ordering guarantee rather than a readiness guarantee is one of the most common sources of flaky local development environments.