Enforce build resource and cache policy on the execution host #808

Parent

Build runner spec (#798)

What to build

Make the host's build resource policy operate on real Dockerfile and Railpack workloads through the shared executor, locally and on a selected Machine. Reuse Docker/BuildKit controls and existing builder ownership rather than adding a cache service or custom resource scheduler.

Acceptance criteria

• Expose optional build CPU limits in cores and memory limits in bytes through execution-host configuration, disabled by default. Validate configuration and ensure a build request cannot raise host policy. Keep these settings independent of Service runtime limits and out of the ordinary build/deploy flag surface.
• Apply configured limits to actual preparation and build processes, including Railpack preparation and every platform solve, using upstream Docker/BuildKit controls. Configuration of a wrapper process alone is insufficient evidence. Report observed limit/launch failures accurately and preserve ordinary cleanup and unknown-termination rules.
• Support a retained-cache budget and minimum free-disk target using BuildKit garbage collection, retaining pinned upstream defaults when unconfigured. State in user-facing configuration help that these are retention/GC targets rather than hard peak disk quotas. Do not invent an eviction algorithm or promise independent cache-mount reuse without evidence.
• Provide explicit cache clearing through host administration and serialize it against active builder/cache ownership. Clear only Ployz-owned builder cache, preserving unrelated Docker data and usable completed images. A local CLI and remote daemon using the same retained state cannot clear or reuse it concurrently.
• Keep builder containers ephemeral and cache persistent across their removal/recreation. Keep one active Build in v1; do not add configurable concurrency, cache replication, or a daemon requirement for ordinary local building.
• Use rung-1 configuration/admission-policy checks and rung-2 executor tests for unchanged request ceilings and safe clearing ownership. Register rung-4 real workload checks for CPU/memory enforcement on Dockerfile and Railpack preparation/build, cache reuse after builder recreation, configured retention behavior, and clearing that leaves unrelated labeled test data untouched. These checks exercise both local and selected-Machine invocation where ownership differs.

Blocked by

• #801 — Build and deploy Railpack applications locally
• #802 — Build a Dockerfile on an explicitly selected Machine