Docker Disk Exhaustion: Reclaiming 56 GB and Automating Cleanup

Docker Ate 56 GB of Disk in a Day: Building a Cleanup Automation

A GitHub Actions pipeline failed when the runner hit a ‘No space left on device’ error on a 72 GB VPS. Investigation revealed that Docker was consuming 38 GB of storage, with 11 MB of disk space remaining.

Why This Matters

The technical reality of containerized environments is that Docker acts as a ‘hoarder,’ failing to natively clean up unreferenced image layers or build caches. Without active resource management, iterative deployment processes eventually lead to resource starvation, halting CI/CD pipelines and production services due to storage exhaustion.

Key Insights

• Docker system analysis in 2026 showed 24 out of 33 images were inactive, representing 23.27 GB (84%) of reclaimable space.
• The Docker Build Cache consumed 7.695 GB of disk space with zero active layers, all of which were available for deletion.
• Emergency recovery using ‘docker image prune -af’ reduced disk usage from 100% to 56%, reclaiming 56 GB total.
• Automated cleanup strategy distinguishes between ‘prune -af’ (aggressive) for manual fixes and ‘prune -f’ (dangling only) for daily automation.
• Systemd timers with ‘Persistent=true’ ensure that cleanup tasks are executed even if the VPS was powered down during the scheduled window.

Working Examples

Emergency manual recovery commands to reclaim space immediately.

sudo docker builder prune -af
sudo docker image prune -af

Automated disk-cleanup.sh script for safe scheduled maintenance.

#!/usr/bin/env bash
set -euo pipefail
echo "=== disk-cleanup starting ==="
docker builder prune -af --filter "until=72h"
docker image prune -f
journalctl --vacuum-time=7d
apt-get clean
find /home/github-runner -path '*/_diag/*' -type f -name '*.log' -mtime +14 -delete

Systemd timer configuration for reliable daily execution.

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=10m
Persistent=true

Practical Applications

• Use Case: GitHub Runner maintenance via daily ‘find’ commands to delete legacy _diag log files older than 14 days to prevent log overflow.
• Pitfall: Running ‘docker image prune -a’ in an automated cron can delete non-dangling tagged images, potentially causing deployment delays during rollbacks.
• Use Case: Multi-project VPS hosting where ‘docker image prune’ (without -a) preserves active project images while removing orphaned layers.

References:

• https://dev.to/merbayerp/docker-ate-56-gb-of-disk-in-a-day-building-a-cleanup-automation-49d6