Measure what a Docker host's disk is actually spent on, plan what can be freed without destroying a rollback target, and free it. The command people reach for is the wrong one: docker image prune — dangling or -a — never touches the BUILD CACHE, and on a host that builds its own images the build cache is usually most of the footprint. On the host this was written against it was 59.5GB of a 77GB reclaim, which no amount of image pruning would have recovered. Three behaviours are deliberate because each one corresponds to a way the obvious command does damage or lies. docker image prune -a removes every image no container references, which is precisely the set of previous versions a rollback needs; this model instead protects the newest keepVersions tags of each repository and removes specific image IDs, so reclaiming space does not quietly cost you the ability to go back. docker builder prune -af deletes the cache that makes the next build fast, and cache that is minutes old is the most valuable cache there is; pruning is therefore age-filtered via --filter until=, so a scheduled run takes cold layers and leaves the working set. And Docker reports sizes as rounded human strings where 1000 versus 1024 is a real 7% at terabyte scale, so parsing is explicit and unit-aware and the freed figure is measured by observing free space before and after rather than by summing estimates. Each method writes its own data instance — usage, plan, reclaim — so an expression always gets the schema it expects rather than whichever method ran last. observe and plan are read-only and safe to schedule at any frequency; reclaim is dry-run unless passed apply: true, and even then never removes an image that any container references, running or stopped. Host key checking is left ON by default — StrictHostKeyChecking=no is available but is not the default, because a model whose entire purpose is running destructive commands as a privileged user is the last place to accept an unverified host key.