Latchkey vs WarpBuild for GitHub Actions runners
On managed runners Latchkey is $0.0025 a minute at 2 vCPU against WarpBuild at $0.004, but that is not the comparison most WarpBuild users are making: its bring-your-own-cloud mode runs in your own AWS, GCP or Azure account at $0.002 a minute, which is cheaper than both. The question is whether you want to own the cloud account the jobs run in.
WarpBuild sells managed GitHub Actions runners at $0.004 a minute for 2 vCPU and 8 GB, adopted by installing its bot from the WarpBuild dashboard rather than the GitHub marketplace and setting runs-on to a runner ID such as warp-ubuntu-latest-x64-4x. It also sells a bring-your-own-cloud mode at $0.002 a minute where the machines run in your own cloud account, publishes arm64 at $0.003, and ships Windows and macOS runners. Its cache is metered separately at $0.20 per GB-month plus a charge per write or restore.
Latchkey sells managed runners only, at $0.0025 a minute for 2 vCPU and 8 GB, in its own AWS estate, with a self-healing agent that repairs transient failures inside the run. There is no BYOC mode, no arm64, no Windows and no macOS, and the cache is not metered separately.
Every cell below was read from the vendor's own public pricing or documentation page on 20 September 2026. Where a vendor does not publish a number, the cell says "not published" instead of carrying a guess.
WarpBuild and Latchkey, read 20 September 2026
| WarpBuild | Latchkey | |
|---|---|---|
| Price per minute, 2 vCPU Linux x64 | $0.004 (2 vCPU, 8 GB RAM) | $0.0025 (2 vCPU, 8 GB RAM, 100 GB disk) |
| Price per minute, 4 vCPU Linux x64 | $0.008 (4 vCPU, 16 GB RAM) | $0.005 (4 vCPU, 16 GB RAM, 100 GB disk) |
| Bring your own cloud | $0.002/min running in your own AWS, GCP or Azure account | Not offered |
| Free tier | Not published. Sign-up needs no card until you reach a usage or credit limit | 30-day trial, then 2,000 included minutes a month on Developer, 4,000 on Launch, 6,000 on Scale |
| Billing granularity | Per minute, in its own words: "CI runners are billed on a per-minute basis" | Per minute |
| Runner sizes and OS | 2 to 32 vCPU on Linux x64 and arm64; Windows from 4 to 32 vCPU; macOS M4 Pro at 6 and 12 vCPU; Linux on Apple silicon at 6 and 12 vCPU | 2, 4, 8 and 16 vCPU, Ubuntu 24.04 on x86_64 only. arm64, Windows and macOS are not offered |
| Cache: type, limit, persistence | Metered: $0.20 per GB-month of storage plus $0.0001 per write or restore; snapshot restore $0.04 a job and $0.025 an hour of snapshot storage | Size not published. latchkey-dev/cache-action@v1 swaps one line for actions/cache, keeping path, key and restore-keys; entries are isolated per organization, versioned by OS, kept 14 days; a failed restore warns rather than failing the job |
| Docker build acceleration | Remote BuildKit builders on their own meter, 16 vCPU at $0.06/min to 192 vCPU at $0.88, driven by Warpbuilds/build-push-action@v7; the shared cache is eventually consistent with a 10-day TTL | latchkey-dev/docker-cache-action@v1, layers held in a Latchkey-managed private registry per organization |
| Concurrency limits | Advertised as unlimited job concurrency; the no-queue guarantee and an SLA behind it are Enterprise features | Not published; warm-pool capacity varies by plan |
| Where jobs run | WarpBuild's own cloud, or your AWS, GCP or Azure account under BYOC | Latchkey's own AWS estate on m6a-class hosts, one job per runner, private network, destroyed after the job |
| Self-healing or retries | Not offered | Built in: transient failures are diagnosed and retried inside the run |
| Setup change required | Sign up, install the WarpBuild bot from its dashboard rather than the GitHub marketplace, then set runs-on to a runner ID such as warp-ubuntu-latest-x64-4x | A runs-on label change. GitHub organization accounts only |
The BYOC rate is the real comparison
Comparing managed rate to managed rate, Latchkey is $0.0025 against $0.004 and wins by 37.5%. That is the headline and it is also the least interesting number on this page, because WarpBuild publishes a bring-your-own-cloud rate of $0.002 a minute that is cheaper than both, and a large share of the teams evaluating WarpBuild are evaluating it for exactly that.
BYOC is not free money. You are paying WarpBuild $0.002 a minute for the orchestration and paying your cloud provider separately for the instances, so the all-in number depends on your own committed-use or savings-plan discounts and on how well the pool is kept warm. It also puts the machines inside your account, which is the point for anyone with a data residency or network egress constraint that a third-party estate cannot satisfy.
Latchkey has no equivalent and is not going to pretend otherwise. If running jobs inside your own cloud account is a requirement rather than a preference, this comparison ends here and WarpBuild is the answer.
Where the cache meters differ
WarpBuild meters the cache: $0.20 per GB-month of storage plus $0.0001 per write or restore, with snapshot restore at $0.04 a job and $0.025 an hour of snapshot storage. That is transparent and it is also a second bill line that scales with how cache-heavy your pipeline is, which the per-minute rate does not tell you about.
Latchkey does not meter the cache separately, and also does not publish a size limit, which is the weaker half of that trade: you cannot plan capacity against a number nobody has published. Entries are isolated per organization, versioned by OS and kept 14 days, and a failed restore warns rather than failing the job.
On Docker specifically, WarpBuild sells remote BuildKit builders on their own meter from $0.06 a minute at 16 vCPU. If your builds lean on that, add it to the comparison before the per-minute rate, because it can be the larger number.
Speed
Not benchmarked yet; the runner benchmark report will replace this section. We have not run the same workload on these runners ourselves, and until we have, there is no number here worth quoting.
The cheap way to get a real answer is to point one slow job at each candidate for a week, because runner selection is per job and the Actions run log gives you the timings for free.
Cost: one worked month
Ten thousand Linux minutes a month at 2 vCPU on a private repository comes to $40 on WarpBuild managed, $20 on WarpBuild BYOC plus whatever the instances cost in your own account, and $25 on Latchkey.
Latchkey's own plan is $5 to $49 a month on top of that compute, and its 2,000 to 6,000 included minutes are not netted off, so the figure is gross on both counts.
WarpBuild publishes no free tier, so there is no allowance to net off on that side. The ranking at this volume is BYOC first on the WarpBuild invoice, Latchkey second, WarpBuild managed third, and the BYOC number is incomplete until you add your own cloud bill.
Reliability
WarpBuild advertises unlimited job concurrency, with the no-queue guarantee and the SLA behind it sold as Enterprise features. Latchkey does not publish a concurrency limit and its warm-pool capacity varies by plan, which is less to go on.
Neither vendor publishes an uptime figure on its public pricing page. The documented difference is again failure handling: WarpBuild does not offer automatic diagnosis or retry, Latchkey repairs transient failures on the runner during the job.
When to choose WarpBuild
Choose WarpBuild if you want the jobs inside your own cloud account, which is the only mode either vendor offers that satisfies a residency or egress constraint. Choose it if you need arm64, Windows or macOS, because Latchkey sells none of them. Choose it if you want an SLA and a no-queue guarantee you can put in a contract, and you are willing to be on its Enterprise tier to get one.
When to choose Latchkey
Choose Latchkey if you want managed Linux x64 runners at the lowest published rate of the two and you do not want a second cloud account to operate. Choose it if your cache and Docker usage is heavy enough that WarpBuild's separate meters would add a bill line you would rather not model. Choose it if the cost you are actually trying to remove is re-running builds that failed for transient reasons, because that is the one thing here neither WarpBuild mode does.
Switching
Switching is a label change on the jobs you choose, not a migration. Leave the rest of the workflow alone, move one slow job first, and read the timings out of the run log before you move the others.
jobs:
build:
- runs-on: warp-ubuntu-latest-x64-4x
+ runs-on: latchkey-medium
steps:
- uses: actions/checkout@v4The verdict
On managed Linux x64, Latchkey is the cheaper machine and the only one that repairs a failing step in-run, and if that is the whole of your requirement it is the straightforward pick. But WarpBuild is not really competing there: its BYOC mode at $0.002 a minute inside your own cloud account, plus arm64, Windows and macOS, is why teams shortlist it, and Latchkey answers none of that. Compare managed to managed only if BYOC is genuinely not something you want to run.