DEV Community

Cover image for Solved: How do you nuke your docker?
Darian Vance
Darian Vance

Posted on • Originally published at wp.me

Solved: How do you nuke your docker?

🚀 Executive Summary

TL;DR: Docker frequently causes ‘disk space full’ issues due to accumulated images, containers, and cache. This guide offers three methods to reclaim disk space: the safe docker system prune, targeted removal of specific components, and a ‘nuclear’ option for a complete Docker reset.

🎯 Key Takeaways

  • Docker’s aggressive caching for immutability and speed often leads to significant disk space consumption from dangling images, stopped containers, and build cache.
  • docker system prune -af –volumes is the most aggressive safe command for routine cleanup, effectively removing all unused images, networks, and volumes.
  • The ‘nuclear’ cleanup method involves a sequence of commands to forcefully stop and remove all Docker containers, images, volumes, and networks, providing a complete factory-fresh reset.

Tired of ‘disk space full’ errors from Docker? A Senior DevOps Engineer shares three battle-tested methods to reclaim your disk space, from a simple, safe prune to the full ‘nuclear’ option for a truly clean slate.

How to Nuke Docker (And Why You Sometimes Have To)

I still remember the 2 AM PagerDuty alert. It was a classic, the kind that makes your heart sink: prod-db-01 was reporting critical disk space alerts. I SSH’d in, ran a quick df -h, and saw the culprit immediately: /var/lib/docker was eating up nearly 90% of the root partition. A junior engineer had been testing a new build pipeline on the wrong machine, leaving behind dozens of gigabytes of dangling images and build cache. We’ve all been there, staring at a terminal, wondering what arcane combination of commands will give us our disk back without breaking everything. It’s a rite of passage, but it doesn’t have to be a painful one.

First, Why Does Docker Hoard So Much Junk?

Before we go nuclear, let’s understand the enemy. Docker is designed for immutability and caching, which is great for speed and consistency, but terrible for your disk space if left unchecked. Over time, your system accumulates:

  • Dangling Images: These are layers that have no relationship to any tagged images. They’re the leftovers from previous builds.
  • Stopped Containers: Every time you run a container, it leaves behind a stopped version of itself unless you use the --rm flag.
  • Unused Volumes: If you don’t explicitly manage them, volumes can persist long after their parent containers are gone, silently holding onto data.
  • Unused Networks: Custom bridge networks that aren’t being used by any containers.
  • Build Cache: The real monster. Every RUN command in your Dockerfile creates a layer, and Docker aggressively caches these to speed up future builds.

Now that we know what we’re fighting, let’s gear up. I’ve got three approaches for you, from a gentle tap to a full-blown orbital strike.

Solution 1: The Daily Driver – docker system prune

This is your first, best, and safest tool. The docker system prune command is the built-in garbage collector. By itself, it’s pretty conservative and only removes dangling images, unused networks, and build cache.

For a slightly deeper clean, I almost always use the -a (or --all) flag. This tells it to also remove any unused images—not just dangling ones.

# This will prompt you for confirmation before deleting.
docker system prune -a

# Add -f to force it without a prompt (great for scripts)
docker system prune -af
Enter fullscreen mode Exit fullscreen mode

But wait, what about volumes? By default, prune leaves volumes alone to prevent accidental data loss. If you’re sure you don’t have any important data in your local Docker volumes, you can add the --volumes flag.

# The most aggressive "safe" command
docker system prune -af --volumes
Enter fullscreen mode Exit fullscreen mode

Darian’s Tip: On our CI/CD build runners, we have a cron job that runs docker system prune -af --volumes nightly. It’s a lifesaver and has prevented countless “disk full” build failures.

Solution 2: The Surgical Strike – Targeted Removal

Sometimes prune isn’t enough, or you need to be more selective. Maybe you want to remove all containers based on a specific image, or just clear out old volumes. This is where you combine a few standard Linux commands with the Docker CLI. It feels a bit hacky, but in the trenches, it’s incredibly effective.

Here’s a quick reference table I give to my team:

Goal Command
Stop and remove all containers


docker stop $(docker ps -aq) docker rm $(docker ps -aq)

|
| Remove all “dangling” images |

docker rmi $(docker images -f "dangling=true" -q)

|
| Remove all unused volumes |

docker volume rm $(docker volume ls -qf dangling=true)

|

The -q flag (quiet) is the key here; it makes commands output only the IDs, which you can then pass into the removal command. It’s powerful, precise, and lets you clean up exactly what you want.

Solution 3: The ‘Nuclear’ Option – Burn It All Down

Okay. You’ve tried pruning. You’ve tried targeted strikes. But the disk is still full, something is corrupted, or you just want to reset Docker to a factory-fresh state without a full reinstall. This is the moment we’ve been waiting for. This is how you nuke it from orbit.

WARNING: This is the point of no return. The following commands will forcefully and IRREVERSIBLY delete ALL Docker containers, images, volumes, and networks on your system. Do not run this on a production machine unless you are 100% certain you know what you are doing.

This is the one-liner you’ll find in forums and on Stack Overflow. It’s beautiful in its sheer destructive power.

# Step 1: Stop all running containers
docker stop $(docker ps -aq)

# Step 2: Remove all containers
docker rm $(docker ps -aq)

# Step 3: Remove all images
docker rmi -f $(docker images -aq)

# Step 4: Remove all volumes
docker volume rm $(docker volume ls -q)

# Step 5: Remove all networks
docker network rm $(docker network ls -q)

# Step 6: The final boss - The system prune to get any leftovers
docker system prune -af --volumes
Enter fullscreen mode Exit fullscreen mode

After running that sequence, your docker ps, docker images, and docker volume ls commands should all come up empty. Your /var/lib/docker directory will be a fraction of its former size. It’s a clean slate. A fresh start. Now, go build something great.


Darian Vance

👉 Read the original article on TechResolve.blog


☕ Support my work

If this article helped you, you can buy me a coffee:

👉 https://buymeacoffee.com/darianvance

Top comments (0)