Skip to main content
Preloop retries transient transport and infrastructure failures, but does not retry configuration errors indefinitely. The pool also caps VM concurrency by host memory so the control plane retains headroom.

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):
Warm pool size is capped by 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.