Pool memory guard
The runtime reserves 2048 MiB for the host and control plane. For each VM, it uses the configured memory ceiling (at least 1 MiB):by_memory. On-demand slots use maximum. If host memory cannot be read, on-demand sizing falls back to CPU and warm sizing keeps the configured pool size. A tiny host still runs one job.
A second environment golden consumes another memory budget slot. When no slot is available, the engine boots that job directly from its base image instead of exceeding the cap. A failed bake releases its reservation; a registered golden retains it. Finished VMs are deleted before the next fork is created.
Capacity settings
A pool slot retries transient fork failures twice. If teardown still cannot confirm that a machine is gone after three delete attempts (1, 2, then 4 seconds), the slot continues checking with a 1-to-30-second backoff until shutdown. A later engine start sweeps leftovers.
Control-plane retries
Runner retry behavior
An unbounded retry is intentional for a guest expected to recover, such as service health or a suspended debug session. Fix the underlying dependency or cancel the job rather than waiting for a retry count that does not exist.
Other protocol bounds
The standalone runner client uses a single request with a 30-second default timeout (PRELOOP_CLIENT_TIMEOUT_SECONDS). The guest control bridge accepts up to 256 concurrent connections and closes idle connections after 300 seconds. Set these only when remote-runner traffic requires different limits.