Stop your CI runners from dragging around stale build artifacts

Technical Briefing | 7/20/2026

You spend weeks tuning your CI pipeline performance, squeezing seconds out of every test run, and then you check the disk space on your runners. They are gasping for air. It turns out that those runners are hoarding layers, cached dependencies, and temporary build outputs that never get cleaned up unless you explicitly tell them to. I once saw a build node go read-only during a Monday morning peak because a dangling container image took up the last few gigabytes of space.

The reality of persistent runners

Unlike ephemeral runners that get wiped after every job, persistent runners act like long-lived cattle. You end up with a graveyard of images, volumes, and temporary files that the engine assumes it might need again. If you’re using GitLab Runners or GitHub Actions runners on your own metal, the default cleanup behavior is often non-existent or configured to keep far too much around. You need to automate the pruning process, or your storage is going to hit a wall when you least expect it.

docker system prune -a --volumes --filter "until=24h" -f

• Use systemd timers instead of cron to manage cleanup jobs so they don’t overlap with active builds
• Set strict limits on your runner process disk usage via cgroups if you want to avoid OOM scenarios
• Point your temp directories to a separate partition so a runaway log write doesn’t kill your OS

Automating the garbage collection

Don’t trust your runners to manage their own house. Use an Ansible task to deploy a dedicated cleanup service that runs daily. If you keep the cleanup logic inside the CI pipeline, you’ll eventually run into a race condition where the runner tries to delete a layer that a concurrent build is currently using. Keep the infrastructure maintenance separate from the application delivery logic. The next time a runner starts acting sluggish, check your df output before you blame the code.