Container Commands List (Docker/Podman)
Universal commands for managing containers across different runtimes. These OCI-standard commands work with Docker, Podman, and other container engines.
🔄 Lifecycle Management
Control the state of containers from creation to removal.
runCreate and start a container in one command. The most commonly used command.createCreate a container but do not start it. State becomes "Created".startStart a stopped or created container.stopGracefully stop a running container (sends SIGTERM, then SIGKILL after timeout).restartStop and then start a container. Useful for applying configuration changes.pause/unpauseSuspend/resume all processes in the container without stopping it.killSend SIGKILL to immediately terminate. Use when stop fails.rmRemove a stopped container. Add -f to force remove running containers.📊 Information & Monitoring
Inspect container state, resource usage, and debug issues.
psList running containers. Add -a to include stopped containers.logsFetch stdout/stderr from a container. Add -f to follow in real-time.inspectReturn detailed JSON metadata: network config, mounts, environment, and more.statsDisplay live stream of CPU, memory, network, and disk I/O usage.topDisplay running processes inside a container (like Linux top).portList port mappings for a container.diffShow filesystem changes made since container was created.⌨️ Interaction
Execute commands and interact with running containers.
execRun a command inside a running container. Use -it for interactive shell.attachAttach stdin/stdout/stderr to a running container's main process.cpCopy files between container filesystem and host.exportExport container filesystem as a tar archive.commitCreate a new image from a container's current state.Understanding Container Management Commands
Containers have revolutionized software deployment by providing a consistent, isolated environment that runs identically across different systems. Whether you are using Docker (the most popular container runtime), Podman (its daemonless alternative), or other OCI-compliant runtimes, the fundamental commands for managing containers are remarkably consistent. This guide covers these essential operations with a focus on practical usage patterns and best practices.
Understanding container lifecycle commands deeply transforms how you work with containerized applications. Instead of treating containers as mysterious black boxes, you will be able to debug issues, optimize performance, and manage production deployments with confidence.
Container Lifecycle Deep Dive
A container goes through several states during its lifetime: Created, Running, Paused, Stopped, and Removed. Understanding these states helps you choose the right command for each situation.
When you run docker run image, several things happen behind the scenes. First, the container is created—a writable layer is added on top of the image, network interfaces are configured, and the container's process environment is set up. Then the container is started—the main process specified in the image's CMD or ENTRYPOINT begins executing.
The stop command sends SIGTERM to the main process, giving it a chance to clean up gracefully (save state, close connections, etc.). If the process does not exit within the timeout (default 10 seconds), SIGKILL is sent, forcefully terminating it. For applications that need more cleanup time, you can extend the timeout: docker stop -t 30 container.
A stopped container still exists on disk with all its data intact. You can start it again, inspect it, or copy files out of it. Only rm actually deletes the container. To stop and remove in one step, use docker rm -f container.
The Essential Debugging Commands
When a container misbehaves, you need visibility into what is happening inside. logs is usually the first command to run—it shows everything the container's main process wrote to stdout and stderr. Add -f to follow logs in real-time, --tail 100 to see only the last 100 lines, or --since 1h to see logs from the last hour.
exec is arguably the second most important command after run. It lets you run additional processes inside a running container. The most common use is getting a shell: docker exec -it container /bin/bash (or /bin/sh for minimal images like Alpine). From there, you can explore the filesystem, test network connectivity, check process state, and investigate problems directly.
inspect returns comprehensive metadata in JSON format. This includes the container's network configuration (IP address, network membership), mount points, environment variables, restart policy, health check status, and much more. Use jq to extract specific fields: docker inspect container | jq '.[0].NetworkSettings.IPAddress'.
Resource Monitoring
stats provides a live, updating view of resource consumption for one or more containers. It shows CPU usage (as a percentage of available CPU), memory usage and limit, network and disk I/O. This is invaluable for identifying resource-hungry containers or verifying that limits are working as expected.
For a snapshot of processes running inside a container, use top. This is the container equivalent of the Linux ps or top commands. It shows process IDs, CPU and memory usage per process, and the command being run.
diff shows what has changed in the container's filesystem since it was created. This helps identify whether a container has modified its own files, which can be important for debugging state-related issues or understanding what data would be lost if the container were replaced.
File Transfer and Image Creation
cp copies files between the host and a container. The syntax is similar to the Unix cp command but includes the container name with a colon: docker cp container:/app/config.json ./config.json or docker cp ./file.txt container:/app/. This works even with stopped containers, making it useful for extracting logs or data from crashed containers.
commit creates a new image from a container's current state. While not recommended for production (Dockerfiles provide reproducible builds), it is useful for quickly saving a debugging session or creating throwaway images during development. The command is: docker commit container newimage:tag.
Docker vs Podman
Podman is a daemonless container engine that is largely command-compatible with Docker. You can often alias docker to podman and have scripts work unchanged. The key difference is architecture: Docker uses a background daemon (dockerd) that owns all containers, while Podman runs containers as child processes of your shell.
This daemonless architecture has security implications—Podman can run entire container workflows as a non-root user without any elevated privileges. Docker, by default, requires root access to communicate with the daemon (though rootless Docker is now available).
The commands in this guide work identically on both runtimes. Podman also supports pods (groups of containers that share network namespaces), which aligns with Kubernetes pod concepts.
Practical Patterns
Running a temporary container for a one-off command: docker run --rm image command. The --rm flag automatically removes the container after it exits, preventing accumulation of stopped containers.
Running a container in the background and monitoring it: docker run -d --name myapp image followed by docker logs -f myapp. The -d detaches, --name gives a predictable name.
Quick cleanup of all stopped containers: docker container prune. This removes all containers that are not running, freeing disk space.
Restart policies for production: docker run --restart unless-stopped image ensures the container restarts automatically after crashes or reboots, unless you explicitly stopped it.
Troubleshooting Common Issues
Container exits immediately: check logs (docker logs container). Common causes include missing environment variables, incorrect command, or the application not finding expected files. The exit code can give hints: 0 means clean exit, 1 usually means application error, 137 means killed by signal (often out-of-memory).
Cannot connect to container: verify port mappings (docker port container), check that the application inside is listening on the expected port and interface (0.0.0.0, not 127.0.0.1), and verify no firewall is blocking.
Container is slow: use docker stats to check resource usage. If hitting memory limits, the OOM killer may be terminating processes. CPU throttling occurs when hitting CPU limits.