đ 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 âvolumesis 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
--rmflag. - 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
RUNcommand 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
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
Darianâs Tip: On our CI/CD build runners, we have a cron job that runs
docker system prune -af --volumesnightly. 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
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.
đ Read the original article on TechResolve.blog
â Support my work
If this article helped you, you can buy me a coffee:

Top comments (0)