Docker
Docker Commands Cheat Sheet

Published: October 5, 2026 · 8 min read

Docker Commands Cheat Sheet — Remember Every Command Easily

You know why Docker exists and you can read every Dockerfile instruction — now it's time to actually drive. This Docker commands cheat sheet covers the essential commands you'll type while learning Docker, organized the easy-to-remember way: not as a flat list, but as one image's journey from docker build all the way to docker push. Learn the journey once, and every command has a fixed place in the story.

In this cheat sheet, you will:

  • See the big picture: build → images → run → ps → stop → rm → rmi → prune
  • Decode docker build -t username/project:label . piece by piece
  • Understand -p host-port:container-port and why your side always comes first
  • Never confuse rm vs rmi again (one letter = one rule)
  • Clean your disk with docker system prune -a
  • Share your image with the world: login → push → logout
  • Keep builds fast and secrets safe with .dockerignore
  • Pick up the three Linux commands (pwd, ls -l, mkdir) that Docker work depends on

Docker commands cheat sheet diagram showing one image's journey from docker build through docker run and docker ps to docker push

The Big Picture — One Image's Journey

Don't memorize commands as a list. Memorize one story — every command is a step in it:

terminal — the full journey
# THE BIG PICTURE — one image's full journey, start to finish:
#
#   build → images → run → ps → stop → rm → rmi → prune
#   (cook)  (check)  (play) (watch) (pause) (throw) (throw) (clean)
#
# Every command on this page lives somewhere on this line.

docker build -t srinu/my-app:v1 .   # 1. cook the image from the Dockerfile
docker images                       # 2. check it exists
docker run -p 3000:3000 srinu/my-app:v1   # 3. start a container from it
docker ps                           # 4. see it running
docker stop <container-id>          # 5. stop the container
docker rm <container-id>            # 6. delete the container
docker rmi srinu/my-app:v1          # 7. delete the image
docker system prune -a              # 8. clean up everything unused

Memory hook: build (cook) → images (check) → run (play) → ps (watch) → stop (pause) → rm/rmi (throw away) → prune (clean the kitchen). When you forget a command, find its place in the story.

docker build — Create the Image

This is the command with the most "mystery symbols", so let's decode every piece:

terminal — docker build decoded
# docker build — turn a Dockerfile into an image

docker build -t username/project_name:label .
#            │  │                           │
#            │  │                           └── the DOT = "Dockerfile is in
#            │  │                               THIS folder" (build context)
#            │  └── name:label for the image
#            │      username     → your Docker Hub username
#            │      project_name → your app's name
#            │      label        → version tag (v1, latest, 1.0)
#            └── -t = "Tag" — give the image a name
#                (without -t you get a random ID — hard to use)

# Real example:
docker build -t srinu/node-api:v1 .

# Memory hook: -t = name Tag, dot = "look here".

docker images and docker rmi — See and Remove Images

terminal — image commands
# SEEING AND REMOVING IMAGES

docker images        # list all images on your machine
# Shows: REPOSITORY, TAG, IMAGE ID, CREATED, SIZE

docker rmi <image-id/image-name>     # remove an image
docker rmi srinu/node-api:v1

# Memory hook:
#   rmi = "ReMove Image" — the 'i' at the end means IMAGE.
#   rm  (no i)           = removes a CONTAINER.

# Note: an image can't be removed while a container
# (even a stopped one) is still using it — remove the
# container first with docker rm.

docker run -p — Start a Container with Port Mapping

The image exists — now run it. The -p flag is the part everyone gets backwards at first:

terminal — docker run -p decoded
# docker run — start a container from an image

docker run -p host-port:container-port <image-id/image-name>
#          │  │         │
#          │  │         └── the port your app listens on INSIDE
#          │  │             the container (EXPOSE in the Dockerfile)
#          │  └──────────── the port on YOUR machine (the host)
#          └── -p = "Port" — connect host port to container port

# Real example — Node.js app listening on 3000:
docker run -p 3000:3000 srinu/node-api:v1
# → open http://localhost:3000 and your app answers

# Host and container ports can differ:
docker run -p 8080:3000 srinu/node-api:v1
# → app still listens on 3000 inside,
#   but YOU reach it at http://localhost:8080

# Memory hook: -p host:container — YOUR side always comes first.
⚠️

-p host:container — your machine's port always comes first. -p 8080:3000 means "I visit localhost:8080, the app inside listens on 3000." Remember: EXPOSE in the Dockerfile only documents the port — -p is what actually connects it.

Docker commands port mapping diagram showing docker run -p 3000:3000 connecting the host port on your laptop to the container port inside Docker

docker ps — What's Running?

terminal — docker ps
# docker ps — currently RUNNING containers only

docker ps

# Shows: CONTAINER ID, IMAGE, COMMAND, CREATED, STATUS, PORTS, NAMES
# The CONTAINER ID here is what you pass to stop / rm.

docker stop and docker rm — Stop, Then Remove

terminal — stop and rm
# STOPPING AND REMOVING CONTAINERS

docker stop <container-id/container-name>   # stop a running container
docker rm   <container-id/container-name>   # remove a STOPPED container

# The order matters:
#   1. docker stop  → container stops (but still exists — see docker ps -a)
#   2. docker rm    → container is deleted for good

# You cannot rm a container that is still running —
# stop it first.

rm vs rmi — One Letter, One Rule

The most common beginner mix-up, solved forever:

terminal — rm vs rmi
# rm vs rmi — the classic mix-up, solved by one letter

docker rm  <container-id>   # removes a CONTAINER
docker rmi <image-id>       # removes an IMAGE ( i = Image )

# And the order of cleanup is always:
#   stop the container → rm the container → rmi the image
# (Docker refuses to delete an image that a container still uses.)

docker system prune -a — Clean Everything Unused

After a week of practice your disk fills up with stopped containers and old images. One command cleans it all:

terminal — system prune
# docker system prune -a — the one-command cleanup

docker system prune -a

# Removes everything UNUSED:
#   • all stopped containers
#   • all unused networks
#   • all unused images
#
# Docker asks for confirmation first:
#   "Are you sure you want to continue? [y/N]"
#
# When to use it: your disk is filling up with old
# experiments, stopped containers, and forgotten images.

# Memory hook: prune = what a gardener does —
# cut away the dead branches, keep the living tree.
🚫

prune -a deletes all unused images — including ones you built yesterday but aren't running right now. You'll have to docker build them again. Fine while learning; pause and think before running it on a real server.

login → push → logout — Share Your Image

Docker Hub (opens in a new tab) is like GitHub, but for images. Three commands move your image from your laptop to the world:

terminal — push to Docker Hub
# SHARING IMAGES — Docker Hub (like GitHub, but for images)
# The flow is: login → push → logout

docker login
# → asks for your Docker Hub username and password
# → you stay logged in until you log out

docker push <image-name>
docker push srinu/node-api:v1
# → uploads your image to Docker Hub
# → now ANYONE can run your app from any machine

docker logout
# → logs out from the Docker registry

# Why the image name must be username/project:label —
# Docker Hub uses the username part to know WHOSE
# account receives the push. That's why docker build -t
# starts with your username.

Docker commands login and push flow diagram showing a built image uploading from a laptop through docker push to Docker Hub where anyone can pull it

.dockerignore — What NOT to Send to Docker

.dockerignore
# .dockerignore — files Docker should NOT copy during docker build
# Same idea as .gitignore, but for the build context.

node_modules
.git
.env
*.log
Dockerfile
.dockerignore

# Why it matters:
#   COPY . .  copies EVERYTHING from your folder —
#   without .dockerignore that includes node_modules
#   (huge, and rebuilt inside anyway by RUN npm install)
#   and .env (your secrets baked into the image!).
#
# Result: smaller images, faster builds, no leaked secrets.

The Linux Commands You'll Need Alongside

Containers are Linux inside, so three tiny Linux commands keep showing up in Docker work:

terminal — Linux basics
# LINUX COMMANDS — containers are Linux, so these come along for free

pwd
# "Print Working Directory" — which folder am I in right now?
# Output: /app

ls -l
# "List" files and folders with details ( -l = Long format )
# Shows: permissions, owner, size, modified date, name

mkdir folder-name
# "MaKe DIRectory" — create a new folder
mkdir uploads

# Where you'll use these: checking what COPY actually
# copied into the image, and understanding what WORKDIR
# does (WORKDIR /app is like mkdir /app + cd /app).

A Complete Session — Everything in Order

Here's every command from this page in the exact order a real session uses them:

terminal — complete session
# A COMPLETE SESSION — every command, in the order you'd really type them

docker build -t srinu/node-api:v1 .    # 1. build image from Dockerfile
docker images                          # 2. confirm the image exists
docker run -p 3000:3000 srinu/node-api:v1   # 3. run it, map the port
docker ps                              # 4. see it running (copy the ID)
docker stop 3f2a91c8b7e4               # 5. stop the container
docker ps -a                           # 6. it's stopped, but still exists
docker rm 3f2a91c8b7e4                 # 7. delete the container
docker rmi srinu/node-api:v1           # 8. delete the image (optional)

# And to share it with the world:
docker login                           # 9.  log in to Docker Hub
docker push srinu/node-api:v1          # 10. upload the image
docker logout                          # 11. log out

# Disk getting full after a week of practice?
docker system prune -a                 # 12. remove everything unused

Docker Commands Quick Reference Table

Bookmark this table — it's the whole page in twelve rows. Every flag and option beyond these lives in the official Docker CLI reference (opens in a new tab), but you won't need it for a long while.

I want to...Command
Build an imagedocker build -t username/project:label .
List my imagesdocker images
Run a container with a portdocker run -p 3000:3000 image-name
See running containersdocker ps
See ALL containers (stopped too)docker ps -a
Stop a containerdocker stop container-id
Remove a containerdocker rm container-id
Remove an imagedocker rmi image-id
Clean up everything unuseddocker system prune -a
Log in to Docker Hubdocker login
Upload my imagedocker push username/project:label
Log outdocker logout

What's Next

You can now take an image through its full life: build it (docker build -t), check it (docker images), run it with a reachable port (docker run -p), watch it (docker ps / ps -a), stop and remove it (stop, rm, rmi), clean up after practice (system prune -a), and publish it to Docker Hub (login → push → logout) — with .dockerignore keeping your builds small and your secrets out of the image. These commands plus the 13 Dockerfile instructions are the complete toolkit for everything that comes next in the series.

← Back to Dockerfile Instructions Explained

Continue to Install Docker on AWS EC2 →


Frequently Asked Questions

What is the difference between docker rm and docker rmi?

One letter changes the target: docker rm removes a container, docker rmi removes an image — the i at the end of rmi stands for image. The cleanup order is always: docker stop the running container, docker rm the stopped container, then docker rmi the image. Docker refuses to delete an image while any container — even a stopped one — was created from it, which is why rm must come before rmi.

What is the difference between docker ps and docker ps -a?

docker ps shows only containers that are currently running. docker ps -a (the -a means All) shows every container, including stopped ones. This matters because a stopped container disappears from plain docker ps but still exists and still occupies disk space — docker ps -a is how you find its CONTAINER ID so you can delete it with docker rm.

What does -p 3000:3000 mean in docker run?

-p maps a port on your machine (the host) to a port inside the container, in the order host-port:container-port — your side always comes first. docker run -p 3000:3000 my-image means requests to http://localhost:3000 on your machine reach the app listening on port 3000 inside the container. The two can differ: -p 8080:3000 keeps the app on 3000 inside while you reach it at http://localhost:8080. Without -p, the container runs but no port on your machine reaches it.

What does the -t flag and the dot mean in docker build?

In docker build -t username/project_name:label ., the -t flag means Tag — it gives the image a human-readable name instead of a random ID. The name has three parts: your Docker Hub username (so docker push knows whose account receives the image), the project name, and a label such as v1 or latest for versioning. The dot at the end is the build context: it tells Docker the Dockerfile and the files to copy are in this folder.

What does docker system prune -a remove?

docker system prune -a removes unused Docker resources in one command: all stopped containers, all unused networks, and all unused images. Docker asks for confirmation before deleting anything. Use it when your disk fills up after days of practice builds — old experiments, stopped containers, and forgotten images all disappear at once. Anything currently in use by a running container is kept.

How do I push a Docker image to Docker Hub?

Three steps: docker login (enter your Docker Hub username and password), docker push username/project_name:label (uploads the image), and docker logout when you are done. The image must be named with your username prefix — that is why docker build -t starts with username/ — because Docker Hub uses it to know whose account receives the push. Once pushed, anyone can pull and run your app on any machine, which is the whole point of Docker: the image travels, and it works the same everywhere.

What is a .dockerignore file and why do I need it?

.dockerignore lists files and folders that should not be sent to Docker during docker build — the same idea as .gitignore, but for the build context. The classic entries are node_modules (huge, and rebuilt inside the image anyway by RUN npm install), .git, .env (so secrets never get baked into the image), and log files. The result is smaller images, faster builds, and no leaked credentials.