At a glance
Preloop’s distinctive boundary is the server–runner contract. It replaces the control plane and ships a compatible runner, while also accepting the official runner where an external runner is appropriate. See Compatibility for the protocol and workflow boundaries.
Capability comparison
The following rows use behavior implemented in this repository. “Not assessed” means this repository does not contain evidence for the alternative, not that the alternative lacks the capability.Checked-in benchmark snapshot
The repository includes one 39-entry result file for each local runner. The table reports the rawpassed field; it is not a service-level guarantee and the files do not include complete host/setup provenance.
The Preloop result file contains two records with
passed: true and a non-zero exit code. Treat the passed field as the harness’s recorded result rather than recomputing a correctness score from process exit codes. The benchmark artifacts are useful for reproducing scenario differences; they are not a promise that every workflow completes identically on every host.
The benchmark also shows why a single “fastest runner” number is misleading: cancellation, service containers, caches, and Docker actions have very different setup and execution costs. Use the per-scenario duration_ms fields in the checked-in result files when you need a workload-specific comparison.
Which boundary fits
Use Compatibility for the current limitations before selecting a workflow or host strategy. For installation and runner-specific operations, see Runner overview and Control plane deployment.