10 Docker Commands That Save Me Hours Every Week (And You're Probably Not Using)

If you work with Docker daily, you probably know the basics — docker run, docker build, docker ps. But there's a whole layer of commands and patterns that most developers never discover until they're deep in production debugging at 2 AM.

Here are 10 Docker commands and patterns that genuinely changed how I work with containers.

1. docker system prune -a --volumes — The Nuclear Clean Option

After weeks of building images and pulling dependencies, your disk fills up silently. The standard docker system prune only removes dangling resources. Adding -a removes all unused images (not just dangling ones), and --volumes catches orphaned volumes too.

docker system prune -a --volumes --force

I run this monthly. It typically frees 5-15 GB. Just make sure you're not mid-deployment.

2. docker compose logs --tail 100 -f — Follow Logs for Multiple Services

When debugging a multi-service setup, you don't want to open 5 terminal windows. Docker Compose lets you tail and follow all services at once:

docker compose logs --tail 100 -f

Filter to a specific service with -f app. Add --since 30m to see only recent logs. This single command replaced my old habit of running docker logs in 4 separate tabs.

3. docker inspect --format '{{json .NetworkSettings.Networks}}' — Debug Networking

Container networking issues are the hardest to diagnose. Instead of guessing, inspect the actual network configuration:

docker inspect --format '{{json .NetworkSettings.Networks}}' <container>

This shows the IP address, gateway, MAC address, and which networks the container is attached to. I pipe it through jq for readability:

docker inspect --format '{{json .NetworkSettings.Networks}}' myapp | jq

4. docker stats --no-stream — Instant Resource Usage Check

Want to know which containers are eating memory without opening a live dashboard?

docker stats --no-stream

The --no-stream flag prints a single snapshot instead of a live stream. Great for scripts and quick checks. I use this in my deployment scripts to verify containers aren't leaking memory after restart.

5. docker exec -it <container> sh -c 'command' — One-Shot Debugging

Sometimes you need to run a command inside a container without dropping into an interactive shell:

docker exec -it myapp sh -c 'cat /etc/config.json | jq .database'

This is faster than docker exec -it myapp sh then running the command. It's especially useful in CI pipelines where you need to verify file contents or environment variables inside a running container.

6. docker build --no-cache --progress=plain — Debug Build Failures

When a Docker build fails mid-way, the default output hides the actual command that failed behind buildkit progress bars.

docker build --no-cache --progress=plain -t myapp .

--progress=plain shows every RUN command's output in real-time, making it easy to spot the failing step. --no-cache ensures you're building from scratch (useful when a cached layer is corrupted).

7. docker run --rm -v $(pwd):/app -w /app node:20 node test.js — Quick Script Runner

Need to run a Node.js/Python/Ruby script without installing anything globally?

docker run --rm -v $(pwd):/app -w /app node:20 node test.js
docker run --rm -v $(pwd):/app -w /app python:3.11 python script.py

The --rm flag cleans up the container after execution. Volume mount your current directory. This pattern is incredibly useful for running one-off scripts in isolated environments — no version conflicts, no global installs.

8. docker compose exec vs docker compose run — Know the Difference

docker compose exec runs a command in an already running container. docker compose run creates a new container with its own network and environment.

# Running migration on existing app container
docker compose exec app python manage.py migrate

# Running a one-off command (new container, linked services)
docker compose run --rm app python manage.py createsuperuser

Most developers use exec when they should use run (or vice versa), causing environment mismatch bugs. The rule: if the command depends on other running services, use run. If you just need to check something in an existing container, use exec.

9. docker context use — Switch Between Remote Clusters

If you work with multiple Docker hosts or Kubernetes clusters:

docker context create remote --docker "host=ssh://user@server"
docker context use remote
docker ps  # Shows containers on the remote server
docker context use default  # Switch back to local

This avoids the old pattern of setting DOCKER_HOST environment variables. I use this daily to switch between local development, staging, and production environments.

10. docker events --filter 'event=die' — Monitor Container Crashes in Real-Time

When containers are crashing in a loop, checking logs one by one is tedious. Instead, monitor Docker events:

docker events --filter 'event=die' --format '{{.Time}} {{.Actor.Attributes.name}} died (exit code: {{.Actor.Attributes.exitCode}})'

This streams container death events with exit codes, making it immediately obvious which container is crashing and why. I combine this with --since to check recent crash history:

docker events --filter 'event=die' --since 1h --until now

---

Beyond the Commands

These commands are useful on their own, but they become powerful when combined into workflows. I keep a shell script that chains health checks, log tails, and resource monitoring into a single deploy-status command.

If you're preparing for DevOps interviews or want a deeper reference, I put together a guide covering 150+ Docker and Kubernetes questions — from basic container concepts to advanced patterns like blue-green deployments and GitOps workflows: Docker & Kubernetes Interview Guide.

What Docker commands do you use daily that aren't in this list? I'm always looking for better workflows.