From 9c1db08e9482092ed9b149506171ef7054f580f9 Mon Sep 17 00:00:00 2001 From: Anthony Ettinger Date: Fri, 25 Sep 2026 02:22:21 +0000 Subject: [PATCH] ops: nightly prune of docker build cache older than a week MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Build cache is the biggest non-database consumer on a box that builds its own images, and this one does: deploy-app.sh builds here so NEXT_PUBLIC_* never leave the box, and the other properties on dev2 build here too. In one day that cache went 0 -> 38 GB, was pruned by hand, and was back to 11.5 GB within hours — twice firing a disk alarm that had nothing to do with the databases. until=168h is the conservative part. Only cache older than a week is discarded, so nothing a current or recent build would reuse is touched and rebuild speed is preserved. A bare `prune -f` would slow the next build of every property on the box, which is why this is age-filtered rather than total. Agreed with the nichedb session first, since they are the heavier build user on shared infrastructure and a policy that slows their rebuilds is not mine to impose. Verified on dev2: the exact command reclaims 0B today, because nothing is yet a week old, and leaves the 11.5 GB working cache intact — which is the behaviour that matters. Co-Authored-By: Claude Opus 5 (1M context) --- ops/selfhost/server/setup-supabase.sh | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/ops/selfhost/server/setup-supabase.sh b/ops/selfhost/server/setup-supabase.sh index e14c8d4..0de5790 100755 --- a/ops/selfhost/server/setup-supabase.sh +++ b/ops/selfhost/server/setup-supabase.sh @@ -241,6 +241,29 @@ CRON # Seed the baseline so the first cron run already reports a rate. "$dest" || true echo " installed $dest (every 15 min); growth record: /var/log/dev2-disk.log" + + install_builder_prune +} + +# Docker build cache is the biggest non-database consumer on a box that builds +# its own images, and this one does: deploy-app.sh builds here so NEXT_PUBLIC_* +# never leave the box, and other properties build here too. In one day that +# cache went 0 -> 38 GB, was pruned, and was back to 11.5 GB within hours, +# twice firing a disk alarm that had nothing to do with the databases. +# +# `until=168h` is the conservative part: only cache older than a week is +# discarded, so nothing a current or recent build would reuse is touched. +# Rebuild speed is preserved; only genuinely stale layers go. A bare +# `prune -f` would slow the next build of every property on the box. +install_builder_prune() { + log "Nightly docker build cache prune (older than 7 days)" + cat > /etc/cron.d/docker-builder-prune <<'CRON' +# Discard docker build cache older than a week. Age-filtered on purpose: the +# problem is accumulation over time, not the working set. +17 4 * * * root docker builder prune -f --filter until=168h >>/var/log/docker-prune.log 2>&1 +CRON + chmod 644 /etc/cron.d/docker-builder-prune + echo " installed /etc/cron.d/docker-builder-prune (04:17 daily)" } # ------------------------------------------------------------- 2. supabase