What Are the Essential Docker Commands?

Docker wraps applications and their dependencies into portable containers built from images, and about twenty commands cover the daily workflow: run, inspect, log, exec, stop, build, and clean up. This cheat sheet lists each one with exactly what it does and the flags worth memorizing. Examples assume a project with a Dockerfile in the current directory.

Run and manage containers

Containers are running instances of images. These commands start, stop, and remove them; learn run first, since its flags reappear everywhere.

Prefer naming containers with --name so later commands read like English instead of hash prefixes. The -p host:container order trips up beginners — traffic arrives at the host port on the left and forwards to the container port on the right. For the concepts behind isolation and images, see the virtualization concepts catalog entry.

Inspect, log, and exec

When a container misbehaves, these are the debugging commands. Reach for logs before a shell: most failures announce themselves in the first lines of output.

A reliable debugging order is logs, then inspect to check environment and mounts, then exec to poke around inside. If exec reports no shell, the image is probably distroless or scratch-based — use docker run --rm -it --entrypoint sh image to start a fresh copy with a shell instead, or debug from the Dockerfile side.

Build images and manage Dockerfiles

Images are built from Dockerfiles as stacked layers, and each instruction adds one layer. Order instructions from least to most frequently changing so rebuilds reuse cached layers.

docker build -t myapp:1.2 .       # build from ./Dockerfile, tag 1.2
docker build --no-cache -t myapp .  # rebuild ignoring the layer cache
docker images                     # list local images and sizes
docker tag myapp:1.2 reg.io/myapp:1.2  # retag for a registry
docker push reg.io/myapp:1.2      # upload the image
docker pull postgres:16           # download without running
docker rmi myapp:1.2              # delete a local image

Keep images small and builds fast with a few habits: pin base tags (node:20-slim, not node:latest), copy dependency manifests before source so installs stay cached, combine chained RUN steps with && to reduce layers, and add a .dockerignore so secrets and node_modules never enter the build context. Builds usually run in CI — the CI/CD pipeline stages entry shows where build, tag, and push fit.

Volumes, networks, and compose

Container filesystems are ephemeral: anything not in a volume disappears with the container. Volumes persist data, networks connect containers, and Compose declares the whole stack in one YAML file.

Inside a user-defined network, containers resolve each other by name, so your app connects to postgres://db:5432/app instead of a hardcoded IP. Published ports still matter for host access — the common network ports reference helps you pick host ports that do not collide with services already running.

Why is my container exiting immediately?

Because a container lives only as long as its main process, and yours finished or crashed. Check docker logs first — a stack trace or missing-variable error is usually sitting there. Common causes: the command ran to completion (a bare ubuntu image with no -it exits at once), the app bound to localhost instead of 0.0.0.0 and the healthcheck killed it, a required environment variable was never passed with -e, or the entrypoint script has Windows line endings and fails to execute. Fix the process, not the container flags: add a long-running foreground command, bind all interfaces, pass the variables, and convert the script with dos2unix. If it still dies, run the image with --entrypoint sh and launch the entrypoint by hand to watch it fail.

Cleanup: reclaiming disk space

Stopped containers, dangling images, and stale build cache accumulate fast — tens of gigabytes on an active dev machine. Clean in escalating order so you never delete something a running container needs.

docker container prune          # delete stopped containers
docker image prune              # delete dangling (untagged) images
docker image prune -a           # delete all images unused by containers
docker volume prune             # delete volumes no container uses (careful!)
docker system df                # show what is using space
docker system prune             # containers, networks, dangling images

docker system prune is the everyday answer and is safe for running containers, but leave -a and --volumes for deliberate cleanups — rebuilding a deleted cache is slow, and pruned named volumes take your local databases with them. Pair container hygiene with source hygiene: the git commands cheat sheet covers keeping the code that goes into your images tidy.