Docker Cheat Sheet
The Docker commands developers actually use daily — running containers, Dockerfiles, volumes, Compose, and cleanup — with real examples, common mistakes, and a searchable quick reference.
Images & Containers
An image is a read-only template. A container is a running instance of one. Everything else in Docker builds on that distinction.
docker pull nginxDownloads an image from a registry — Docker Hub by default — without running it.
docker imagesLists every image currently stored locally, with repository, tag, and size.
docker run nginxCreates and starts a new container from an image. On its own it's rarely useful — combine it with the flags in the next section.
docker ps docker ps -adocker ps lists running containers. Add -a to list every container, including ones that have already stopped.
docker stop my-containerGracefully stops a running container — sends SIGTERM, waits briefly, then sends SIGKILL if it hasn't exited yet.
docker rm my-containerRemoves a stopped container. Add -f to force-remove one that's still running, skipping the stop step.
docker rmi nginxRemoves a local image. Fails if any container — even a stopped one — still references it; remove that container first.
Running Containers
docker run does very little on its own — its flags are where almost all the useful behavior actually comes from.
docker run -d nginx-d runs the container detached, in the background, printing just its container ID instead of attaching your terminal to it.
docker run -it ubuntu bash-it allocates an interactive terminal (-t) and keeps stdin open (-i) — the combination you want for actually working inside a container's shell.
docker run --name my-app nginxGives the container a memorable name instead of a random one, so future stop/logs/exec commands can reference it by name instead of an ID.
docker run -p 8080:80 nginxMaps port 8080 on your machine to port 80 inside the container, always in host:container order.
docker run -v $(pwd):/app nodeMounts a directory into the container, so files persist and are visible on both sides — see Volumes & Bind Mounts below for the full picture.
docker run --rm alpine echo hiAutomatically removes the container the moment it exits — ideal for one-off, throwaway commands so stopped containers don't quietly pile up.
docker run -e NODE_ENV=production nginxSets an environment variable inside the container. Repeat -e for each additional variable.
docker run -d --rm --name web -p 8080:80 -v $(pwd):/app node is a completely normal thing to type.Dockerfile Essentials
The file that defines your own images, instruction by instruction, top to bottom.
FROM node:20-alpineThe base image every Dockerfile starts from. Pick the smallest base that has what you actually need — alpine variants are dramatically smaller than full Debian/Ubuntu bases.
WORKDIR /appSets the working directory for every instruction after it — RUN, COPY, and CMD all execute relative to this path.
COPY . .Copies files from your build context — the folder you ran docker build in — into the image, at the path set by WORKDIR.
RUN npm installExecutes a command at build time and bakes its result into a new image layer, permanently, as part of the image.
ENV NODE_ENV=productionSets an environment variable that persists into every container run from this image — not just during the build, unlike a plain shell variable.
EXPOSE 3000Documents which port the container listens on. Purely informational — it doesn't actually publish the port. That's still -p at run time.
CMD ["node", "server.js"]The default command a container runs when started, unless overridden by whatever command you pass to docker run.
docker run image other-command replaces it entirely. ENTRYPOINT sets a command that's harder to override and treats CMD's value as its arguments instead. Use ENTRYPOINT when the image should always run essentially one program; use CMD for a sensible default that callers might reasonably want to replace.Building & Registries
Turning a Dockerfile into an image, and getting that image somewhere other machines can pull it from.
docker build -t my-app:latest .Builds an image from the Dockerfile in the current directory — the . is the build context — and tags it my-app:latest.
docker tag my-app:latest myregistry/my-app:v1Adds another tag to an existing local image, typically to prepare it for pushing to a specific registry under a specific name.
docker push myregistry/my-app:v1Uploads a tagged image to a registry — Docker Hub, or a private one your team runs.
docker loginAuthenticates with a registry before you're able to push to it.
docker build --no-cache -t my-app .Rebuilds every layer from scratch, ignoring Docker's build cache entirely — use when you suspect a cached layer has gone stale.
:latest has no enforced meaning beyond "whatever was pushed most recently under that name." Pin a specific version tag or digest in production instead of relying on it.Volumes & Bind Mounts
Two different ways to make data survive past a container's own lifetime, for two different situations.
docker volume create my-dataCreates a named volume, managed entirely by Docker, independent of any specific host path.
docker run -v my-data:/data nginxMounts a named volume into a container — the data persists even after the container is removed, and other containers can reuse the same volume.
docker run -v $(pwd):/app nodeA bind mount: maps a specific host directory directly into the container, so edits on either side show up on both immediately — the standard setup for local development.
docker volume lsLists every volume Docker currently knows about.
docker volume rm my-dataDeletes a named volume and everything stored inside it, permanently.
Networking
How containers reach each other, and how you reach them from outside.
docker network lsLists Docker's networks. Every container joins the default bridge network unless told otherwise.
docker network create my-netCreates a custom network, letting containers attached to it resolve each other by container name instead of by IP address.
docker run --network my-net --name db postgresAttaches a container to a specific network. Combine with --name so other containers on the same network can reach it by that name.
docker port my-containerShows which host ports are currently mapped to which ports inside a container — a quick sanity check when you've forgotten exactly what you mapped.
Docker Compose
Running more than one container together, defined in a single file instead of a stack of docker run commands.
docker compose up -dStarts every service defined in docker-compose.yml, detached in the background.
docker compose downStops and removes every container and network created by the compose file. Named volumes are kept unless you add --volumes.
docker compose logs -fFollows the combined logs of every service live, each line prefixed by which service it came from.
services: web: build: . ports: - "8080:80" db: image: postgres volumes: - db-data:/var/lib/postgresql/data volumes: db-data:
docker compose exec web shOpens a shell inside a running service's container, referenced by its service name from the compose file instead of a container ID.
docker compose buildRebuilds images for any service that has a build: section in the compose file, without starting them.
docker compose psLists the containers managed by this compose file and their current status.
Inspecting & Debugging
For once a container isn't behaving the way you expected.
docker logs -f my-containerShows a container's stdout/stderr output since it started. -f follows it live, the same idea as tail -f on a log file.
docker exec -it my-container shOpens an interactive shell inside an already-running container — the main way to poke around inside one without stopping it.
docker inspect my-containerDumps a container's full configuration as JSON — its IP address, mounted volumes, environment variables, network settings, all of it. The 'give me everything' command when higher-level commands don't show what you need.
docker statsA live, top-like view of every running container's CPU, memory, and network usage at once.
docker top my-containerLists the actual processes running inside a container, from the host's perspective.
Cleanup & Maintenance
Docker accumulates stopped containers, unused images, and old layers quietly, until a disk fills up.
docker system dfShows how much disk space images, containers, and volumes are using — the Docker equivalent of df -h, and worth checking before reaching for prune.
docker system pruneRemoves all stopped containers, unused networks, dangling images, and build cache in one command. Prompts for confirmation first.
docker system prune -aThe same as above, but also removes every image not currently used by a running container — not just dangling ones. Considerably more aggressive.
docker image pruneRemoves only dangling images — untagged layers left behind by rebuilds — without touching containers or networks at all.
docker container pruneRemoves every stopped container in one pass.
docker volume pruneRemoves every volume not currently referenced by at least one container.
Quick Reference
Already comfortable with Docker — just blanked on a flag? Search instead of scrolling.
docker pullDownload an image from a registry without running it
docker imagesList every image stored locally
docker runCreate and start a new container from an image
docker psList running containers
docker ps -aList every container, including stopped ones
docker stopGracefully stop a running container
docker rmRemove a stopped container
docker rmiRemove a local image
-dRun a container detached, in the background
-itAllocate an interactive terminal with stdin open
--nameGive a container a memorable name
-p host:containerMap a host port to a container port
-vMount a volume or host directory into a container
--rmAutomatically remove the container when it exits
-eSet an environment variable inside the container
FROMThe base image a Dockerfile starts from
WORKDIRSet the working directory for later instructions
COPYCopy files from the build context into the image
RUNExecute a command at build time, baked into a layer
ENVSet an environment variable for every container run from this image
EXPOSEDocument which port the container listens on
CMDThe default command a container runs, easy to override
ENTRYPOINTThe command an image is built around, harder to override
docker build -tBuild an image from a Dockerfile and tag it
docker tagAdd another tag to an existing local image
docker pushUpload a tagged image to a registry
docker loginAuthenticate with a registry before pushing
docker volume createCreate a named volume managed by Docker
docker volume lsList every volume Docker knows about
docker volume rmDelete a named volume and its data
docker network lsList Docker's networks
docker network createCreate a custom network for containers to share
--networkAttach a container to a specific network
docker portShow which host ports map to a container's ports
docker compose up -dStart every service in docker-compose.yml, detached
docker compose downStop and remove containers and networks from a compose file
docker compose logs -fFollow the combined logs of every service live
docker compose execOpen a shell inside a running service by name
docker compose psList containers managed by a compose file
docker logs -fFollow a container's stdout/stderr output live
docker exec -itOpen an interactive shell inside a running container
docker inspectDump a container's full configuration as JSON
docker statsLive view of every running container's resource usage
docker topList the processes running inside a container
docker system pruneRemove stopped containers, unused networks, and dangling images
docker image pruneRemove only dangling, untagged images
docker volume pruneRemove every volume not used by a container
docker system dfShow disk space used by images, containers, and volumes
48 of 48 commands
Common Use Cases
Real situations, not just isolated commands — the exact sequence that gets you through each one.
You need a database locally without installing it on your machine
Run it in a container with the port and password it needs:
- docker run -d --name db -e POSTGRES_PASSWORD=secret -p 5432:5432 postgres
You want to see why a container keeps exiting immediately
Check what it actually printed before it stopped:
- docker ps -a
- docker logs container-id
You need to poke around inside a running container
Open an interactive shell without stopping it:
- docker exec -it container-name sh
Your build reinstalls dependencies every single time
Reorder the Dockerfile so the dependency layer only invalidates when it should:
- COPY package.json .
- RUN npm install
- COPY . .
You're low on disk space and don't know what Docker is using it for
Check what's actually taking up space before deleting anything:
- docker system df
- docker system prune
You need an app and its database to talk to each other
Put both services in one compose file instead of juggling separate docker run commands:
- docker compose up -d
Debugging & Troubleshooting
The exact error text Docker prints, decoded.
Error response from daemon: port is already allocatedAnother container or process is already using that host port. Pick a different host port in -p, or find and stop whatever's using it first.
docker psContainer exits immediately after docker runThe container's main process finished, and nothing else was keeping it alive. Check its logs for what happened, and confirm the image's CMD or ENTRYPOINT is actually a long-running process if you meant for the container to keep going.
docker logs container-idCannot connect to the Docker daemonThe Docker daemon or service isn't running, or your current user doesn't have permission to talk to it. Start the Docker service, or check that your user has been added to the docker group (or use sudo in the meantime).
Code changes aren't showing up inside the running containerEither the image was never rebuilt after the change, or the edited file isn't actually inside a bind-mounted path. Confirm your COPY paths and -v mount paths line up, and remember: only files inside a live bind mount update automatically — everything else needs a rebuild.
no space left on device (from Docker itself, not the host OS)Docker's own storage — images, stopped containers, volumes, build cache — has filled up. Check what's actually using the space, then clean up what you don't need.
docker system dfdocker-compose: command not found (but docker compose works, or vice versa)One is the older standalone tool, the other the newer built-in plugin — depending on your Docker version, only one of them might be installed. Check which one you actually have before assuming a typo.
docker compose versionThings to Remember
If you forget everything else on this page, keep these.
- An image is a read-only template; a container is a running instance of it — you can run many containers from one image.
- -p is always host:container — get the order backwards and you'll be looking for your app on the wrong port.
- --rm keeps one-off containers from piling up. Forgetting it is why docker ps -a fills up with old stopped containers.
- Order a Dockerfile so rarely-changing steps (installing dependencies) come before frequently-changing ones (copying your code) — it's the difference between a 2-second rebuild and a 2-minute one.
- CMD is a default that's easy to override; ENTRYPOINT is the command an image is built around.
- docker logs only sees stdout/stderr — a container logging to its own file needs docker exec to read it.
- Named volumes persist data independent of any container; bind mounts tie a container to a specific host path, exactly what you want for live-editing code.
- Check docker system df before docker system prune — know what you're about to delete before you delete it.
- docker compose (space) is the current syntax; docker-compose (hyphen) is the older standalone tool — both still show up in the wild.
Common Use Cases
About Docker Cheat Sheet
Docker's own documentation is thorough and scattered across images, containers, volumes, networks, and Compose as separate concepts you're expected to assemble yourself. Most cheat sheets don't help — a flat list of docker verb commands with no sense of the mental model underneath: what actually separates an image from a container, the two genuinely different ways to persist data, or why a container you just started exits immediately instead of staying up.
This one starts from that mental model — images and containers, and the run flags you'll reach for constantly (-d, -it, -p, -v, --rm) — before moving into Dockerfile essentials, the file that defines your own images. From there it covers building and tagging, volumes and networking (how containers keep data and talk to each other), Docker Compose for running more than one container together, and the inspecting, debugging, and cleanup commands you need once something isn't behaving.
Every section calls out the mistakes that actually cost time: getting -p's host:container order backwards, confusing CMD with ENTRYPOINT, a Dockerfile ordered so a code change reinstalls every dependency from scratch, docker system prune deleting more than you meant to. There's a searchable quick reference for the moment you already know roughly what you want, and a troubleshooting section built around the exact error text Docker prints — port already allocated, cannot connect to the Docker daemon — not a paraphrase of it.
Nothing on this page requires Docker to be installed to read it, and nothing here runs a container anywhere — it's a static reference, like every tool on AllCoreKit. The quick-reference search filters entirely in your browser, and nothing you read or search for is ever sent anywhere or logged.
Frequently Asked Questions
Related Tools
View all Cheat SheetsGit Cheat Sheet
The Git commands developers actually use daily, organized by workflow — branching, rebasing, undoing mistakes, and recovery — with real examples and a searchable quick reference.
Regex Cheat Sheet
The regex syntax developers actually reach for — anchors, character classes, groups, and lookaround — with real patterns, common mistakes, and a searchable quick reference.
Prompt Engineering Cheat Sheet
The prompt patterns that actually change LLM output — anatomy, few-shot, chain-of-thought, and structured formatting — with real examples, pitfalls, and a searchable quick reference.