--- title: "PruneMate: The Docker Cleanup Tool Your Home Lab Needs" lang: "en" author: "Mohammad Abu Mattar" canonical: https://mkabumattar.com/post/docker-disk-space-prunemate --- ![Blog post image for Docker Is Eating Your Disk Space (And How PruneMate Fixes It) - Your Docker host is slowly filling up with unused images, orphaned volumes, and stale build cache. Manual cleanup feels risky, and you might accidentally delete the wrong thing. Here's how PruneMate automates Docker maintenance across your home lab with scheduled cleanup, remote host support, and a clean interface that shows exactly what you're deleting before you commit. ](/_astro/hero.BD8-gtdG_Z1vam3B.webp) [Home](/)›[Devtips](/devtips)›[All Categories](/devtips/categories)›[Containers & Docker](/devtips/categories/containers--docker) Devtips [Containers & Docker](/devtips/categories/containers--docker) # Docker Is Eating Your Disk Space (And How PruneMate Fixes It) [Mohammad Abu Mattar](/authors/mohammad-abu-mattar)Published: 02 Jan 202605 Mins read07 Mins listen [Markdown for AI(opens in a new tab)](/post/docker-disk-space-prunemate/index.md "Open the plain-Markdown version of this page, for pasting into an AI tool") TL;DR Your Docker host is slowly filling up with unused images, orphaned volumes, and stale build cache. Manual cleanup feels risky, and you might accidentally delete the wrong thing. Here's how PruneMate automates Docker maintenance across your home lab with scheduled cleanup, remote host support, and a clean interface that shows exactly what you're deleting before you commit. Series [Containers & Kubernetes](/series/containers--kubernetes)1/1 All posts in this series (1) DevTips1 1. [Docker Is Eating Your Disk Space (And How PruneMate Fixes It)You are here](/devtips/post/docker-disk-space-prunemate) ### Docker Is Eating Your Disk Space (And How PruneMate Fixes It) Contents [The problem: Docker is eating your disk space](#the-problem-docker-is-eating-your-disk-space)[What it looks like when it happens](#what-it-looks-like-when-it-happens)[Why Docker holds onto so much](#why-docker-holds-onto-so-much)[Checking what's using your space](#checking-whats-using-your-space)[The risks of manual Docker cleanup](#the-risks-of-manual-docker-cleanup)[The built-in prune commands](#the-built-in-prune-commands)[Why manual cleanup is risky](#why-manual-cleanup-is-risky)[What makes PruneMate worth using](#what-makes-prunemate-worth-using)[Setting up PruneMate](#setting-up-prunemate)[Managing multiple Docker hosts](#managing-multiple-docker-hosts)[Using PruneMate](#using-prunemate)[The interface and cleanup options](#the-interface-and-cleanup-options)[A typical cleanup](#a-typical-cleanup)[Setting up automated cleanup](#setting-up-automated-cleanup)[PruneMate vs manual cleanup](#prunemate-vs-manual-cleanup)[The trade-offs](#the-trade-offs)[Why this matters now](#why-this-matters-now)[Bottom line](#bottom-line) ## [The problem: Docker is eating your disk space](#the-problem-docker-is-eating-your-disk-space) ### [What it looks like when it happens](#what-it-looks-like-when-it-happens) **Your Docker host is running out of space. Again.** You’ve been spinning up containers, testing new services, building images. Everything’s humming along nicely. Then your system starts throwing errors because the root filesystem is full. You check your disk usage and Docker has taken 200GB. Wait, what? How did this even happen? ### [Why Docker holds onto so much](#why-docker-holds-onto-so-much) **What’s actually going on** Docker is trying to be helpful. When you stop a container, you might want to restart it later with the same data, so Docker doesn’t throw anything away. Volumes stick around after containers are gone. Build cache hangs out to make your next build faster. Old images stay put “just in case” you need them again. This makes total sense for production. But in a home lab where you’re constantly trying new stuff? It turns into a slow pile-up of junk. That database volume from three months ago? Still there. Build cache from a project you ditched? Yep, still hanging around. Images you pulled once for curiosity and never touched again? All of it adds up. ### [Checking what’s using your space](#checking-whats-using-your-space) Find out where it went. Run this: Terminal window ``` 1docker system df ``` You’ll probably see something like this: Terminal window ``` 1TYPE TOTAL ACTIVE SIZE RECLAIMABLE2Images 47 12 23.5GB 15.2GB (64%) # 15GB we could get back!3Containers 15 8 2.1GB 1.3GB (61%)4Local Volumes 89 24 45.8GB 38.2GB (83%) # Ouch, 38GB of unused volumes5Build Cache 156 0 12.3GB 12.3GB (100%) # 100% unused. All of it. ``` Look at that. 66GB sitting there doing nothing. And if your Docker volumes live on your root filesystem, which they probably do, the whole machine goes down with it. Databases refuse connections. Package managers throw errors. Containers can’t write logs. ## [The risks of manual Docker cleanup](#the-risks-of-manual-docker-cleanup) ### [The built-in prune commands](#the-built-in-prune-commands) Sure, you can manually prune stuff with Docker’s built-in commands: Terminal window ``` 1# These work, but they're scary to run blindly2docker image prune # Removes unused images. Pretty safe.3docker volume prune # Removes unused volumes. WAIT, ARE YOU SURE?4docker system prune # Nuclear option. Add -a and you're in danger territory. ``` ### [Why manual cleanup is risky](#why-manual-cleanup-is-risky) It always feels risky, though. Are those volumes actually unused? What if you delete something you needed? I made this mistake early on. I thought I’d be clever and deleted folders in `/var/lib/docker/volumes` by hand. I destroyed persistent data I cared about, because from the filesystem I couldn’t tell which volume belonged to what. The built-in prune commands are safer than my folder deletion, but they’re still blunt. It’s all or nothing. And if you’ve got multiple Docker hosts, you’re SSHing into each one running the same commands over and over. **Enter PruneMate: actually sensible Docker cleanup** ### [What makes PruneMate worth using](#what-makes-prunemate-worth-using) [PruneMate](https://github.com/anoniemerd/PruneMate) is an open-source tool that fixes all this. It shows you what’s eating your space, lets you pick exactly what to clean, and runs it all on a schedule so you don’t have to think about it. What makes it worth using: - **Visual dashboard** that shows where your space is going across all your Docker hosts - **Granular control** pick images, volumes, networks, containers, or build cache. Your choice. - **Preview mode** see exactly what’ll get deleted before you pull the trigger - **Scheduled cleanup jobs** that run automatically while you sleep - **Remote host support** using Docker Socket Proxy (no SSH needed) - **Notifications** via Gotify, ntfy, Discord, or Telegram Instead of SSHing around and guessing what’s safe to delete, every host is in one interface. ### [Setting up PruneMate](#setting-up-prunemate) Just deploy the container on one of your Docker hosts with Docker Compose. Here’s all you need: compose.yml ``` 1services:2 prunemate:3 image: anoniemerd/prunemate:latest4 container_name: prunemate5 ports:6 - '7676:8080' # Access the web UI on port 76767 volumes:8 # Give PruneMate access to Docker on this host9 - /var/run/docker.sock:/var/run/docker.sock10 # Keep logs and config between restarts11 - ./prunemate/logs:/var/log12 - ./prunemate/config:/config13 environment:14 - PRUNEMATE_TZ=America/New_York # Change to your timezone15 - PRUNEMATE_TIME_24H=true # Or false if you prefer AM/PM16 # Optional: Add a password to protect the interface17 # - PRUNEMATE_AUTH_USER=admin18 # - PRUNEMATE_AUTH_PASSWORD_HASH=your_hash_here19 restart: unless-stopped ``` Bring it up: Terminal window ``` 1docker compose up -d ``` Now just open `http://your-host:7676` in your browser and you’re good to go. ### [Managing multiple Docker hosts](#managing-multiple-docker-hosts) If you want to manage other Docker hosts remotely, set up a Docker Socket Proxy on each one. PruneMate then connects through the proxy instead of getting full access to the Docker socket, which is effectively root on the host: compose.yml ``` 1services:2 dockerproxy:3 image: ghcr.io/tecnativa/docker-socket-proxy:latest4 environment:5 # These control what PruneMate can do via the proxy6 - CONTAINERS=1 # Let it see and manage containers7 - IMAGES=1 # Let it manage images8 - NETWORKS=1 # Let it manage networks9 - VOLUMES=1 # Let it manage volumes10 - BUILD=1 # Needed for cleaning build cache11 - POST=1 # Needed for actually running prune commands12 ports:13 - '2375:2375' # Standard Docker API port14 volumes:15 # Read-only access to Docker socket. Much safer.16 - /var/run/docker.sock:/var/run/docker.sock:ro17 restart: unless-stopped ``` Deploy this on each remote host, then add them to PruneMate’s interface with their hostname and port 2375. That’s the whole home lab from one place. ## [Using PruneMate](#using-prunemate) ### [The interface and cleanup options](#the-interface-and-cleanup-options) The interface is a set of checkboxes for what to clean: - All unused containers - All unused images - All unused networks - All unused volumes - All build cache By default, only unused images are checked, which is the right default. An image you delete by mistake is one `docker pull` away. A volume you delete by mistake is gone, so PruneMate leaves volumes alone until you say otherwise. ### [A typical cleanup](#a-typical-cleanup) Here’s what a typical cleanup looks like: 1. Check the boxes for what you want to clean 2. Hit “Preview & Run” 3. Look at what it’s about to delete (with size estimates) 4. If it looks good, hit “Confirm & Execute” 5. Get a notification when it’s done That preview step is the reason I use it. You’ll see something like “About to delete 50 unused volumes and free up 38GB” before anything happens, and if a number looks wrong you back out. ### [Setting up automated cleanup](#setting-up-automated-cleanup) For automated cleanup, I set up a schedule. Here’s mine: - **Images and containers**: Weekly cleanup - **Build cache**: Weekly (I rebuild often, so cache gets stale fast) - **Volumes**: Manual only (way too risky to automate) This keeps everything clean without me having to remember. The notifications tell me what got cleaned up, so I know what happened without watching it happen. ## [PruneMate vs manual cleanup](#prunemate-vs-manual-cleanup) ### [The trade-offs](#the-trade-offs) Manual Cleanup PruneMate **Visibility** Run `docker system df` on each host manually Dashboard shows all hosts at once **Safety** High risk with wrong flags (`-a`, `--volumes`) Preview before deletion, focused on unused resources **Granularity** All-or-nothing (especially with `system prune`) Pick exactly what to clean **Remote hosts** SSH to each one individually Manage all hosts from one interface **Automation** Requires cron jobs or CI/CD pipelines Built-in scheduler with notifications **Learning curve** Forces you to understand Docker maintenance Hides complexity (good and bad) **Time investment** High upfront to script it properly 10 minutes to deploy and configure ### [Why this matters now](#why-this-matters-now) Manual cleanup teaches you how Docker actually works underneath, and that is worth learning once. But once you’ve learned it, running the same three commands on four hosts forever teaches you nothing new. PruneMate does the repetitive part and tells you what it did. Component prices are also brutal right now. A 1TB NVMe that cost $80 last year is closer to $150. Thanks, AI boom. If you can’t throw money at bigger drives, you have to get more out of the ones you have. Docker disk space is one of those problems you ignore until it bites you. Then your system is already falling apart. Logs won’t write. Databases run out of room. New deployments fail because there’s no space for the image. By the time you notice, you’re firefighting. PruneMate keeps you ahead of that by cleaning up on a schedule. It’s a boring tool for a boring problem, which is exactly what I want in something with delete permissions. ### [Bottom line](#bottom-line) If you’re running Docker anywhere, home lab or production, disk maintenance isn’t optional. You can do it by hand with discipline and shell scripts, and plenty of people do. Or you can hand it to PruneMate and stop thinking about it. Grab it here: [PruneMate on GitHub](https://github.com/anoniemerd/PruneMate) How are you handling Docker cleanup? Manual commands? Custom scripts? Already using some automation tool? Was this useful? ## Tags [#Docker](/devtips/tags/docker)[#Containers](/devtips/tags/containers)[#Home Lab](/devtips/tags/home-lab)[#DevOps](/devtips/tags/devops)[#Storage Management](/devtips/tags/storage-management)[#PruneMate](/devtips/tags/prunemate)[#Docker Cleanup](/devtips/tags/docker-cleanup)[#Infrastructure Maintenance](/devtips/tags/infrastructure-maintenance) ## Share [Facebook](https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmkabumattar.com%2Fdevtips%2Fpost%2Fdocker-disk-space-prunemate "Share on Facebook")[Twitter](https://twitter.com/intent/tweet/?text=Docker%20Is%20Eating%20Your%20Disk%20Space%20\(And%20How%20PruneMate%20Fixes%20It\)&url=https%3A%2F%2Fmkabumattar.com%2Fdevtips%2Fpost%2Fdocker-disk-space-prunemate "Share on Twitter")[LinkedIn](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fmkabumattar.com%2Fdevtips%2Fpost%2Fdocker-disk-space-prunemate&title=Docker%20Is%20Eating%20Your%20Disk%20Space%20\(And%20How%20PruneMate%20Fixes%20It\)&summary=Your%20Docker%20host%20is%20slowly%20filling%20up%20with%20unused%20images%2C%20orphaned%20volumes%2C%20and%20stale%20build%20cache.%20Manual%20cleanup%20feels%20risky%2C%20and%20you%20might%20accidentally%20delete%20the%20wrong%20thing.%20Here's%20how%20PruneMate%20automates%20Docker%20maintenance%20across%20your%20home%20lab%20with%20scheduled%20cleanup%2C%20remote%20host%20support%2C%20and%20a%20clean%20interface%20that%20shows%20exactly%20what%20you're%20deleting%20before%20you%20commit.%0A&source=https://mkabumattar.com "Share on LinkedIn")[WhatsApp](https://wa.me/?text=Docker%20Is%20Eating%20Your%20Disk%20Space%20\(And%20How%20PruneMate%20Fixes%20It\)%20https%3A%2F%2Fmkabumattar.com%2Fdevtips%2Fpost%2Fdocker-disk-space-prunemate "Share on WhatsApp")[Telegram](https://t.me/share/url?url=https%3A%2F%2Fmkabumattar.com%2Fdevtips%2Fpost%2Fdocker-disk-space-prunemate&text=Docker%20Is%20Eating%20Your%20Disk%20Space%20\(And%20How%20PruneMate%20Fixes%20It\) "Share on Telegram")[Reddit](https://www.reddit.com/submit?url=https%3A%2F%2Fmkabumattar.com%2Fdevtips%2Fpost%2Fdocker-disk-space-prunemate&title=Docker%20Is%20Eating%20Your%20Disk%20Space%20\(And%20How%20PruneMate%20Fixes%20It\) "Share on Reddit")[Hacker News](http://news.ycombinator.com/submitlink?u=https%3A%2F%2Fmkabumattar.com%2Fdevtips%2Fpost%2Fdocker-disk-space-prunemate&t=Docker%20Is%20Eating%20Your%20Disk%20Space%20\(And%20How%20PruneMate%20Fixes%20It\) "Share on Hacker News")[Pinterest](https://pinterest.com/pin/create/button/?url=https%3A%2F%2Fmkabumattar.com%2Fdevtips%2Fpost%2Fdocker-disk-space-prunemate&media=&description=Your%20Docker%20host%20is%20slowly%20filling%20up%20with%20unused%20images%2C%20orphaned%20volumes%2C%20and%20stale%20build%20cache.%20Manual%20cleanup%20feels%20risky%2C%20and%20you%20might%20accidentally%20delete%20the%20wrong%20thing.%20Here's%20how%20PruneMate%20automates%20Docker%20maintenance%20across%20your%20home%20lab%20with%20scheduled%20cleanup%2C%20remote%20host%20support%2C%20and%20a%20clean%20interface%20that%20shows%20exactly%20what%20you're%20deleting%20before%20you%20commit.%0A "Share on Pinterest")[Email]() ## Comments ## You might also enjoy More posts on similar topics [![Understanding Kubernetes Services: ClusterIP vs NodePort vs LoadBalancer](/_astro/hero.DBNjupL__148EQW.webp)](/devtips/post/kubernetes-services-clusterip-nodeport-loadbalancer) ## [Understanding Kubernetes Services: ClusterIP vs NodePort vs LoadBalancer](/devtips/post/kubernetes-services-clusterip-nodeport-loadbalancer) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [DevOps & Kubernetes](/devtips/categories/devops--kubernetes) If you're working with Kubernetes, you've probably noticed that Pods come and go, and their IP addresses keep changing. That's where Services come in. They give you a stable way to keep your apps acce [#Kubernetes](/devtips/tags/kubernetes)[#K8s Services](/devtips/tags/k8s-services)[#ClusterIP](/devtips/tags/clusterip)+5 tags [read more](/devtips/post/kubernetes-services-clusterip-nodeport-loadbalancer) [![Managing Terraform at Scale with Terragrunt](/_astro/hero.DUZZoi07_ZRPUOh.webp)](/devtips/post/terraform-terragrunt-wrappers) ## [Managing Terraform at Scale with Terragrunt](/devtips/post/terraform-terragrunt-wrappers) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Cloud & Infrastructure Automation](/devtips/categories/cloud--infrastructure-automation) The problem with Terraform at scale Duplicated code across environments If you're managing infrastructure with Terraform across several environments or projects, you've probably hit the point [#Terraform](/devtips/tags/terraform)[#Terragrunt](/devtips/tags/terragrunt)[#Infrastructure as Code](/devtips/tags/infrastructure-as-code)+4 tags [read more](/devtips/post/terraform-terragrunt-wrappers) [![HashiCorp Pulls the Plug on CDKTF](/_astro/hero.BBIsBB2t_Z22hNwP.webp)](/devtips/post/cdktf-deprecation-hashicorp-terraform) ## [HashiCorp Pulls the Plug on CDKTF](/devtips/post/cdktf-deprecation-hashicorp-terraform) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Cloud & Infrastructure Automation](/devtips/categories/cloud--infrastructure-automation) CDKTF is officially deprecated The deprecation announcement Well, it finally happened. HashiCorp (now owned by IBM) officially deprecated the Cloud Development Kit for Terraform (CDKTF) [#Terraform](/devtips/tags/terraform)[#CDKTF](/devtips/tags/cdktf)[#HashiCorp](/devtips/tags/hashicorp)+6 tags [read more](/devtips/post/cdktf-deprecation-hashicorp-terraform) [![Container Image Vulnerability Scanning in CI/CD with Trivy](/_astro/hero.yY1orHlw_2oq3jw.webp)](/devtips/post/container-image-vulnerability-scanning-trivy) ## [Container Image Vulnerability Scanning in CI/CD with Trivy](/devtips/post/container-image-vulnerability-scanning-trivy) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [DevOps & DevSecOps](/devtips/categories/devops--devsecops) Why container security matters Where the vulnerabilities hide A container image is one of the largest pieces of untrusted code you ship. Every image you build carries the base OS layer, [#Container Security](/devtips/tags/container-security)[#Vulnerability Scanning](/devtips/tags/vulnerability-scanning)[#Trivy](/devtips/tags/trivy)+4 tags [read more](/devtips/post/container-image-vulnerability-scanning-trivy) [![Docker Multi-Stage Builds: Smaller, Safer Images for Production](/_astro/hero.CI-H9NMO_1DjM7c.webp)](/devtips/post/docker-multi-stage-builds-smaller-production-images) ## [Docker Multi-Stage Builds: Smaller, Safer Images for Production](/devtips/post/docker-multi-stage-builds-smaller-production-images) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Kubernetes & Containers](/devtips/categories/kubernetes--containers) Why multi-stage builds matter Image size is really about what is inside Hey, want to stop shipping a toolshed to production? If your Dockerfile builds and runs the app in one stage, your [#Docker](/devtips/tags/docker)[#Multi Stage Build](/devtips/tags/multi-stage-build)[#Container Image](/devtips/tags/container-image)+4 tags [read more](/devtips/post/docker-multi-stage-builds-smaller-production-images) [![7 Reasons Learning the Linux Terminal is Worth It (Even for Beginners)](/_astro/hero.Ci9C_A6W_1AKnQ0.webp)](/devtips/post/7-reasons-learning-linux-terminal-worth-it-beginners) ## [7 Reasons Learning the Linux Terminal is Worth It (Even for Beginners)](/devtips/post/7-reasons-learning-linux-terminal-worth-it-beginners) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [DevOps & DevSecOps](/devtips/categories/devops--devsecops) Why learn the Linux terminal? Why it still matters Even with the graphical tools and AI assistants available now, the terminal is the most direct way to work with a Linux system. It's a core [#Linux](/devtips/tags/linux)[#Terminal](/devtips/tags/terminal)[#Command Line](/devtips/tags/command-line)+4 tags [read more](/devtips/post/7-reasons-learning-linux-terminal-worth-it-beginners) 6 related posts