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:

1
docker system df

You’ll probably see something like this:

1
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
2
Images          47        12        23.5GB    15.2GB (64%)     # 15GB we could get back!
3
Containers      15        8         2.1GB     1.3GB (61%)
4
Local Volumes   89        24        45.8GB    38.2GB (83%)     # Ouch, 38GB of unused volumes
5
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:

1
# These work, but they're scary to run blindly
2
docker image prune    # Removes unused images. Pretty safe.
3
docker volume prune   # Removes unused volumes. WAIT, ARE YOU SURE?
4
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 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:

1
services:
2
  prunemate:
3
    image: anoniemerd/prunemate:latest
4
    container_name: prunemate
5
    ports:
6
      - '7676:8080' # Access the web UI on port 7676
7
    volumes:
8
      # Give PruneMate access to Docker on this host
9
      - /var/run/docker.sock:/var/run/docker.sock
10
      # Keep logs and config between restarts
11
      - ./prunemate/logs:/var/log
12
      - ./prunemate/config:/config
13
    environment:
14
      - PRUNEMATE_TZ=America/New_York # Change to your timezone
15
      - PRUNEMATE_TIME_24H=true # Or false if you prefer AM/PM
16
      # Optional: Add a password to protect the interface
17
      # - PRUNEMATE_AUTH_USER=admin
18
      # - PRUNEMATE_AUTH_PASSWORD_HASH=your_hash_here
19
    restart: unless-stopped

Bring it up:

1
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:

1
services:
2
  dockerproxy:
3
    image: ghcr.io/tecnativa/docker-socket-proxy:latest
4
    environment:
5
      # These control what PruneMate can do via the proxy
6
      - CONTAINERS=1 # Let it see and manage containers
7
      - IMAGES=1 # Let it manage images
8
      - NETWORKS=1 # Let it manage networks
9
      - VOLUMES=1 # Let it manage volumes
10
      - BUILD=1 # Needed for cleaning build cache
11
      - POST=1 # Needed for actually running prune commands
12
    ports:
13
      - '2375:2375' # Standard Docker API port
14
    volumes:
15
      # Read-only access to Docker socket. Much safer.
16
      - /var/run/docker.sock:/var/run/docker.sock:ro
17
    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

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

How are you handling Docker cleanup? Manual commands? Custom scripts? Already using some automation tool?