--- title: "Docker Is Eating Your Disk Space (And How PruneMate Fixes It)" description: "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.\n" author: "Mohammad Abu Mattar" canonical: https://mkabumattar.com/devtips/post/docker-disk-space-prunemate --- # Docker Is Eating Your Disk Space (And How PruneMate Fixes It) ## The problem: Docker is eating your disk space ### 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 **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 Find out where it went. Run this: ```shell docker system df ``` You'll probably see something like this: ```shell TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 47 12 23.5GB 15.2GB (64%) # 15GB we could get back! Containers 15 8 2.1GB 1.3GB (61%) Local Volumes 89 24 45.8GB 38.2GB (83%) # Ouch, 38GB of unused volumes Build 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 built-in prune commands Sure, you can manually prune stuff with Docker's built-in commands: ```shell # These work, but they're scary to run blindly docker image prune # Removes unused images. Pretty safe. docker volume prune # Removes unused volumes. WAIT, ARE YOU SURE? docker system prune # Nuclear option. Add -a and you're in danger territory. ``` ### 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 [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 Just deploy the container on one of your Docker hosts with Docker Compose. Here's all you need: ```yaml title="compose.yml" showLineNumbers services: prunemate: image: anoniemerd/prunemate:latest container_name: prunemate ports: - '7676:8080' # Access the web UI on port 7676 volumes: # Give PruneMate access to Docker on this host - /var/run/docker.sock:/var/run/docker.sock # Keep logs and config between restarts - ./prunemate/logs:/var/log - ./prunemate/config:/config environment: - PRUNEMATE_TZ=America/New_York # Change to your timezone - PRUNEMATE_TIME_24H=true # Or false if you prefer AM/PM # Optional: Add a password to protect the interface # - PRUNEMATE_AUTH_USER=admin # - PRUNEMATE_AUTH_PASSWORD_HASH=your_hash_here restart: unless-stopped ``` Bring it up: ```shell docker compose up -d ``` Now just open `http://your-host:7676` in your browser and you're good to go. ### 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: ```yaml title="compose.yml" showLineNumbers services: dockerproxy: image: ghcr.io/tecnativa/docker-socket-proxy:latest environment: # These control what PruneMate can do via the proxy - CONTAINERS=1 # Let it see and manage containers - IMAGES=1 # Let it manage images - NETWORKS=1 # Let it manage networks - VOLUMES=1 # Let it manage volumes - BUILD=1 # Needed for cleaning build cache - POST=1 # Needed for actually running prune commands ports: - '2375:2375' # Standard Docker API port volumes: # Read-only access to Docker socket. Much safer. - /var/run/docker.sock:/var/run/docker.sock:ro 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 ### 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 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 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 ### 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 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 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?