Platform / Runners
Product 04Drop-in GitHub Actions runners on up to 3x faster hardware.
Change one line and your jobs run on gaming-class CPUs and the latest dedicated AMD hardware — up to 3x faster, with no cap on how many run at once. Every job gets its own microVM, and every run is measured as it happens.
Why it exists
GitHub-hosted runners run on shared, older hardware, cap how many jobs run at once, and tell you little about where the time went. Self-hosted runners add machines to maintain. preloop gives every job a fast, fresh machine, runs as many as you push, and shows you what each one cost.
The mechanism, in the order a job meets it.
preloop resolves expressions, expands matrices and assigns each job to a pool member that matches its labels. It prefers the least-loaded eligible runner.
Pool members are created ahead of demand, paused and parked. A job claims one at start, which resumes it with the right labels. A job never waits on a boot.
Each job runs in its own microVM with its own kernel and filesystem, built from the official GitHub runner image. No shared Docker daemon, no persistent home directory.
Before any secret or OIDC token reaches the job, the machine is checked against the pinned image digest. Enforce mode fails closed on a mismatch.
The machine is deleted when the job ends, and the next job gets a fresh one. A failing job can pause for debugging instead.
Each capability is part of the product today.
Jobs run on a mix of gaming-class CPUs, chosen for single-thread speed, and the latest dedicated AMD hardware for parallel builds and test suites.
No concurrency cap and no queue for a free slot. Every job you push starts on its own machine.
See duration, queue time, cost and failure rate for every workflow, job and step as runs happen, and find the jobs that slow your pipeline down.
Every job runs in its own microVM, isolated by hardware virtualization rather than a shared kernel. It gets its own kernel, filesystem and network, and nothing from one job can reach another. The machine runs exactly one job and is destroyed with it.
Members are created from a prepared runner image and kept paused. Claiming one resumes it, so provisioning time leaves the critical path.
preloop checks the running machine against the digest the job pinned. Log-only and enforce modes are per tenant; enforce fails closed.
Each built runner-image digest carries an immutable SBOM, a package inventory, Trivy vulnerability and secret findings, and a preflight checklist — queryable per digest, with diffs between two digests.
Jobs use the same actions, expressions and outputs as GitHub. The runner is the official protocol, so workflows drop in unchanged.
Sample / yaml
name: ci
on: [push, pull_request]
jobs:
test:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm test`plp ci migrate` writes this line for you; everything else stays your workflow.
It is destroyed, and the next job gets a fresh one. A failing job can pause for debugging instead.
The running machine is compared to the image digest the job pinned before secrets or OIDC tokens reach it. Enforce mode fails closed on a mismatch.
Start
We will set it up with you and show you what changes.