chadtmiller.com/knotless

Switch repository

Loading…

What changes

After each build, deploy.sh build prunes buildkit's cache down to the 20 GB used most recently (docker builder prune --max-used-space 20GB). setup.sh's daily knotless-prune service does the same after its image prune.

Why

buildkit keeps every layer it has built and has no cap of its own. It held 49 GB of prod's 150 GB disk on 2026-10-31, the day the disk filled and knotless.dev answered 502. The cargo registry and target/ cache mounts, which keep deploys fast, are about 5 GB and are read by every build, so they always count among the most recently used and survive the prune. The cap could have gone in the daemon's builder.gc config instead, but changing that means restarting dockerd. The host has no live-restore, so that restart would take serve and pages down.

How it was checked

Applied by hand on the prod host: updated the service file and ran the prune. It freed 26 GB, the cache mounts stayed (docker buildx du --filter type=exec.cachemount), and the disk went from 78% to 61%. The deploy step first runs at the deploy after this lands.

Shortcomings

A layer older than the 20 GB kept gets rebuilt if a later build needs it again, which is rare given how often main deploys.

🤖 Generated with Claude Code

This adds docker builder prune -f --max-used-space 20GB after each build in deploy.sh. It also adds the same prune to the daily knotless-prune service in setup.sh, with matching README and comment updates. I found nothing that must change.

• The prune runs after the candidate image is built, so it can't remove layers the current build needs. It doesn't touch images.
• || true means a prune failure never fails a deploy. The cost is that a broken prune goes unnoticed, which fits the disk-full incident this addresses.
• The change touches no crate sources, so the change-file rule doesn't apply.

Your note that the cache mounts survived the manual prune on prod is the evidence for the 20 GB cap. Nothing in this pull changes the already-provisioned host's service file. You said you updated it by hand, so that host is covered.