Skip to content

disk retention on an always-on worker box

nate
Oct 23, 20262 min read

disk retention on an always-on worker box

an always-on box that runs workflow workers, CI and periodic builds fills its disk with a few kinds of output that nothing expires. each kind needs a different retention rule, and the rule belongs to the job that writes it.

what accumulates

  • build outputs kept forever. when the published copy lives in object storage, each local build directory is a reproducible artifact: keep the newest few plus whatever the serving endpoint reports as live, and prune nothing while that endpoint is unreachable.
  • history a job needs in full. the bundles an incremental job computes its starting point from look prunable and are not.
  • package caches. a worker that installs from git on every run grows the uv cache by an environment per run. uv cache prune removes only unreferenced entries and costs the next start; services belong in a persistent venv (uv tool install, or uv sync into a release directory) with the binary exec'd directly, and uv run stays for short-lived work. pruning under a long-lived uv run has its own traps; see uv.
  • model weights. nothing expires them, including ones nobody has loaded in years.
  • /tmp. Ubuntu cleans it only at boot, and a worker box goes weeks between boots. fixed-name scratch files overwritten each run stay stable; uniquely named ones accumulate.

the writer owns retention

the job that writes an artifact owns its retention, decided in the flow next to the write, with its consumers named. a separate janitor flow would have to know every producer's rules, and would delete something a producer still needed.

the box's GPU trouble was driver sourcing and C library versions, not hardware; that material is in NVIDIA inference runtimes.

sources

  • heavypad disk audit, 2026-09-19 and 2026-09-28 (du, lsblk): 878 GB of 1.8 TB used after two months, mostly 446 GB of snapshot builds, 51 GB of weekly bundles, 115 GB of ~/.cache/uv, and 67 GB of model weights
  • uv cache lock and environment-bucket behaviour under a long-lived uv run --with service, 2026-10; uv cache prune --help (--force ignores in-use checks), uv 0.13.4
  • my-prefect-server docs/operations.md, "disk on heavypad"

Did you enjoy this article?

Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.

Across the AtmosphereDiscussions