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.

runs locally on your browser. Your data never leaves your device.
13 sections
48 commands
Searchable quick reference
100% offline

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 nginx
Essential

Downloads an image from a registry — Docker Hub by default — without running it.

docker images
Essential

Lists every image currently stored locally, with repository, tag, and size.

docker run nginx
Essential

Creates 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 -a
Essential

docker ps lists running containers. Add -a to list every container, including ones that have already stopped.

docker stop my-container
Essential

Gracefully stops a running container — sends SIGTERM, waits briefly, then sends SIGKILL if it hasn't exited yet.

docker rm my-container
Handy

Removes a stopped container. Add -f to force-remove one that's still running, skipping the stop step.

docker rmi nginx
Handy

Removes a local image. Fails if any container — even a stopped one — still references it; remove that container first.

Image vs. container, in one line
An image is a read-only template; a container is a running (or stopped) instance created from one. You can run many independent containers from the exact same image at once.

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
Essential

-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
Essential

-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 nginx
Handy

Gives 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 nginx
Essential

Maps port 8080 on your machine to port 80 inside the container, always in host:container order.

docker run -v $(pwd):/app node
Essential

Mounts 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 hi
Handy

Automatically 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 nginx
Handy

Sets an environment variable inside the container. Repeat -e for each additional variable.

-p is always host:container, never the other way around
Swapping the order is a very common source of "why can't I reach my app" — you'd be mapping a port on the container to itself instead of exposing it to your machine.
Pro trick
Flags combine freely on one line: 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-alpine
Essential

The 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 /app
Essential

Sets the working directory for every instruction after it — RUN, COPY, and CMD all execute relative to this path.

COPY . .
Essential

Copies files from your build context — the folder you ran docker build in — into the image, at the path set by WORKDIR.

RUN npm install
Essential

Executes a command at build time and bakes its result into a new image layer, permanently, as part of the image.

ENV NODE_ENV=production
Handy

Sets an environment variable that persists into every container run from this image — not just during the build, unlike a plain shell variable.

EXPOSE 3000
Handy

Documents 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"]
Essential

The default command a container runs when started, unless overridden by whatever command you pass to docker run.

CMD vs. ENTRYPOINT
CMD sets a default command that's easy to override — 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.
Order your Dockerfile for layer caching
Copy just the dependency manifest and install first — COPY package.json ., then RUN npm install — and only COPY the rest of your code afterward. Docker caches each layer, so dependency installation only reruns when package.json actually changes, not on every single code edit.

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 .
Essential

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:v1
Handy

Adds 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:v1
Handy

Uploads a tagged image to a registry — Docker Hub, or a private one your team runs.

docker login
Handy

Authenticates with a registry before you're able to push to it.

docker build --no-cache -t my-app .
Advanced

Rebuilds every layer from scratch, ignoring Docker's build cache entirely — use when you suspect a cached layer has gone stale.

:latest is just a tag, not a guarantee
Pushing over an existing tag silently replaces what it points to for anyone who pulls it next — :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-data
Handy

Creates a named volume, managed entirely by Docker, independent of any specific host path.

docker run -v my-data:/data nginx
Essential

Mounts 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 node
Essential

A 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 ls
Handy

Lists every volume Docker currently knows about.

docker volume rm my-data
Handy

Deletes a named volume and everything stored inside it, permanently.

Named volume vs. bind mount
A named volume is managed by Docker and portable across machines — the right choice for a database's data directory. A bind mount points at an exact host path, which is exactly what you want for live-editing your own code during development, but ties the container to that specific host's filesystem layout.

Networking

How containers reach each other, and how you reach them from outside.

docker network ls
Handy

Lists Docker's networks. Every container joins the default bridge network unless told otherwise.

docker network create my-net
Handy

Creates 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 postgres
Essential

Attaches 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-container
Handy

Shows which host ports are currently mapped to which ports inside a container — a quick sanity check when you've forgotten exactly what you mapped.

Tip
Within a custom network, containers reach each other by container name as if it were a hostname — no manual IP tracking required. This is exactly what makes multi-container setups like Compose work without any extra configuration.

Docker Compose

Running more than one container together, defined in a single file instead of a stack of docker run commands.

docker compose up -d
Essential

Starts every service defined in docker-compose.yml, detached in the background.

docker compose down
Essential

Stops and removes every container and network created by the compose file. Named volumes are kept unless you add --volumes.

docker compose logs -f
Essential

Follows 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 sh
Handy

Opens a shell inside a running service's container, referenced by its service name from the compose file instead of a container ID.

docker compose build
Handy

Rebuilds images for any service that has a build: section in the compose file, without starting them.

docker compose ps
Handy

Lists the containers managed by this compose file and their current status.

docker compose vs. docker-compose
docker compose (a space) is the current, built-in syntax bundled with modern Docker. docker-compose (a hyphen) is the older, separately-installed standalone tool. Both accept nearly identical files and commands day to day, but new setups should default to the space version.

Inspecting & Debugging

For once a container isn't behaving the way you expected.

docker logs -f my-container
Essential

Shows 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 sh
Essential

Opens an interactive shell inside an already-running container — the main way to poke around inside one without stopping it.

docker inspect my-container
Handy

Dumps 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 stats
Handy

A live, top-like view of every running container's CPU, memory, and network usage at once.

docker top my-container
Advanced

Lists the actual processes running inside a container, from the host's perspective.

docker logs only sees stdout and stderr
A process that logs to a file inside the container won't show up in docker logs at all — you'd need to docker exec in and read that file directly, or reconfigure the app to log to stdout, which is the standard container-logging convention for exactly this reason.
Pro trick
docker exec -it my-container sh works even on minimal images that don't include bash — sh is available almost everywhere. Reach for bash specifically only once you know the image actually has it.

Cleanup & Maintenance

Docker accumulates stopped containers, unused images, and old layers quietly, until a disk fills up.

docker system df
Handy

Shows 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 prune
Essential

Removes all stopped containers, unused networks, dangling images, and build cache in one command. Prompts for confirmation first.

docker system prune -a
Advanced

The same as above, but also removes every image not currently used by a running container — not just dangling ones. Considerably more aggressive.

docker image prune
Handy

Removes only dangling images — untagged layers left behind by rebuilds — without touching containers or networks at all.

docker container prune
Handy

Removes every stopped container in one pass.

docker volume prune
Advanced

Removes every volume not currently referenced by at least one container.

prune commands don't ask twice about what's inside
docker system prune -a and docker volume prune are destructive and delete real data without a second confirmation for the contents. Check docker system df first, and never run volume prune against something you haven't personally confirmed is disposable.

Quick Reference

Already comfortable with Docker — just blanked on a flag? Search instead of scrolling.

docker pull

Download an image from a registry without running it

docker images

List every image stored locally

docker run

Create and start a new container from an image

docker ps

List running containers

docker ps -a

List every container, including stopped ones

docker stop

Gracefully stop a running container

docker rm

Remove a stopped container

docker rmi

Remove a local image

-d

Run a container detached, in the background

-it

Allocate an interactive terminal with stdin open

--name

Give a container a memorable name

-p host:container

Map a host port to a container port

-v

Mount a volume or host directory into a container

--rm

Automatically remove the container when it exits

-e

Set an environment variable inside the container

FROM

The base image a Dockerfile starts from

WORKDIR

Set the working directory for later instructions

COPY

Copy files from the build context into the image

RUN

Execute a command at build time, baked into a layer

ENV

Set an environment variable for every container run from this image

EXPOSE

Document which port the container listens on

CMD

The default command a container runs, easy to override

ENTRYPOINT

The command an image is built around, harder to override

docker build -t

Build an image from a Dockerfile and tag it

docker tag

Add another tag to an existing local image

docker push

Upload a tagged image to a registry

docker login

Authenticate with a registry before pushing

docker volume create

Create a named volume managed by Docker

docker volume ls

List every volume Docker knows about

docker volume rm

Delete a named volume and its data

docker network ls

List Docker's networks

docker network create

Create a custom network for containers to share

--network

Attach a container to a specific network

docker port

Show which host ports map to a container's ports

docker compose up -d

Start every service in docker-compose.yml, detached

docker compose down

Stop and remove containers and networks from a compose file

docker compose logs -f

Follow the combined logs of every service live

docker compose exec

Open a shell inside a running service by name

docker compose ps

List containers managed by a compose file

docker logs -f

Follow a container's stdout/stderr output live

docker exec -it

Open an interactive shell inside a running container

docker inspect

Dump a container's full configuration as JSON

docker stats

Live view of every running container's resource usage

docker top

List the processes running inside a container

docker system prune

Remove stopped containers, unused networks, and dangling images

docker image prune

Remove only dangling, untagged images

docker volume prune

Remove every volume not used by a container

docker system df

Show 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:

  1. 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:

  1. docker ps -a
  2. docker logs container-id

You need to poke around inside a running container

Open an interactive shell without stopping it:

  1. 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:

  1. COPY package.json .
  2. RUN npm install
  3. 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:

  1. docker system df
  2. 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:

  1. docker compose up -d

Debugging & Troubleshooting

The exact error text Docker prints, decoded.

Error response from daemon: port is already allocated

Another 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 ps
Container exits immediately after docker run

The 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-id
Cannot connect to the Docker daemon

The 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 container

Either 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 df
docker-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 version

Things 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

Recall the exact -p flag order before mapping a container's port to your own machine
Figure out why a container keeps exiting immediately after docker run
Reorder a Dockerfile's COPY and RUN steps before a slow rebuild eats another five minutes
Search the quick-reference table for a command's exact flags instead of digging through Docker's docs

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