48 Docker commands with flags, real-world use cases, and gotchas. Searchable and filterable. Verified against official Docker docs.
Everything runs in your browser. No commands or data are sent to any server.
5 essential commands to get you started. The full reference is right below.
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.
docker ps Check what's currently running before starting a duplicate container or debugging why a port is already in use.
docker logs -f myapp Read stdout and stderr from a running or recently stopped container to debug a startup failure.
docker exec -it myapp sh Get a shell inside a running container to inspect files, test connectivity, or run diagnostic commands.
docker compose up -d Bring up an entire multi-container stack, like an app plus its database and cache, with one command.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
docker compose build ↓ Click command to explain
When to use this
Rebuild service images after changing a Dockerfile without also restarting the containers.
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.
docker compose ps ↓ Click command to explain
When to use this
Check the status of every service defined in the current compose file.
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.
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.
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.
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.
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.
docker version ↓ Click command to explain
When to use this
Confirm client and server (daemon) version before troubleshooting an API compatibility issue.
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.
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.
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.
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.