Docker Commands Cheat Sheet for Developers Who Need Real Control

Docker commands are easier when grouped by workflow

Docker has many commands, but daily work usually follows a few workflows: build an image, run a container, inspect state, read logs, enter a container, manage volumes, connect networks, and clean up old resources. Learning commands by workflow is more useful than memorizing a long alphabetical list.

Start with inspection commands. docker ps shows running containers. docker ps -a includes stopped containers. docker images shows local images. docker logs reveals container output. docker inspect shows detailed configuration. These commands help you understand state before changing it.

Build and run deliberately

docker build creates an image from a Dockerfile. Tags make images easier to identify. docker run starts a container, but the flags matter: ports, environment variables, volumes, names, networks, restart policies, and detached mode all change behavior. A container that works once with a long command should usually become a documented script, Compose file, or deployment definition.

docker exec runs a command inside an existing container. It is useful for debugging, but it should not become the normal way to configure production. Changes made manually inside a container disappear when the container is replaced unless they are written to a mounted volume or external system.

• Use docker logs -f to follow live output.
• Use docker exec -it for temporary debugging shells.
• Use named volumes for persistent local data.
• Use cleanup commands carefully after inspecting what will be removed.

Cleanup commands deserve caution

Docker can accumulate stopped containers, unused images, dangling layers, build cache, networks, and volumes. Cleanup commands such as docker system prune, docker image prune, and docker volume prune can free space, but they can also remove data you still need. Volumes are especially sensitive because they may contain databases or uploaded files.

Run docker system df before cleanup to see where space is used. Avoid running broad prune commands when you do not understand which project owns the resources. Safety is part of productivity.

Use commands to learn the platform

Docker commands teach how containers really behave. Logs show process output. Inspect reveals environment, mounts, networks, and labels. Stats show resource usage. Network commands show connectivity. Volume commands show persistence. Together, they turn Docker from a black box into an understandable local platform.

The best command-line Docker workflow is calm: inspect first, change deliberately, clean up carefully, and move repeated commands into versioned project configuration.

Prefer project commands for teams

Personal Docker command knowledge is useful, but shared projects need repeatable commands. Put common flows in Docker Compose, Makefiles, package scripts, or documentation. New developers should not need to reconstruct the correct run command from chat history. Shared commands turn Docker from individual expertise into team infrastructure.

Know when to stop debugging inside the container

Entering a container is useful for inspection, but permanent fixes belong in the Dockerfile, Compose file, environment configuration, or application code. If you install packages manually or edit files inside a running container, the change disappears on rebuild. Treat container shells as diagnostic tools, not as a configuration strategy.