WarpBuild vs GitHub-Hosted Runners: BYOC Changes the Maths
WarpBuild has two products in one price list: managed runners at $0.004/min, and a bring-your-own-cloud mode at $0.002/min where the compute lands on your own cloud bill instead of theirs.
WarpBuild is a drop-in replacement for GitHub-hosted runners with an unusual second mode. In managed mode it prices like the rest of the category. In BYOC mode the runners execute inside your own cloud account and WarpBuild charges $0.002/min for the control plane, with the compute billed to you directly by your provider.
That second mode is the interesting one, and it changes what you are comparing: not a per-minute rate against a per-minute rate, but a control-plane fee plus your own negotiated cloud pricing against a fully managed rate.
Standard GitHub-hosted runners are free and unlimited on public repositories, and public repos get 4 vCPU and 16 GB rather than the 2 vCPU and 8 GB private repositories receive. No paid runner beats free, so everything below assumes a private repository past its included minutes.
Published Linux rates
| Size | GitHub-hosted | WarpBuild managed | WarpBuild arm64 |
|---|---|---|---|
| 2 vCPU | $0.006/min | $0.004/min | $0.003/min |
| 4 vCPU | $0.012/min | $0.008/min | $0.006/min |
| 8 vCPU | $0.022/min | $0.016/min | $0.012/min |
| 16 vCPU | $0.042/min | $0.032/min | $0.024/min |
| 32 vCPU | $0.082/min | $0.064/min | $0.048/min |
| BYOC (any size) | n/a | $0.002/min + your cloud bill | $0.002/min + your cloud bill |
When BYOC actually wins
BYOC is not automatically cheaper. You are trading a single managed rate for a control-plane fee plus compute you procure yourself, so it wins under specific conditions and loses under others.
- You already have committed cloud spend, reserved instances, or a negotiated discount. Then your effective compute rate is below list and the $0.002 control-plane fee is the only markup.
- You need runners inside your own VPC for private service access, data residency, or compliance. No fully managed provider can offer that at any price.
- You have the operational capacity to own capacity planning, image updates, and the incident when the pool does not scale. BYOC moves that work to you.
The ARM rates are the quiet advantage
WarpBuild publishes arm64 at 25% below its own x64 rate at every size, and arm64 against GitHub-hosted arm64 ($0.005/min at 2 vCPU) is a 40% saving. If your builds are architecture-agnostic, that is the largest published difference on this page and the one most teams never evaluate.
Switching, and switching back
Every managed runner in this category is selected by the runs-on label, so adoption and reversal are the same one-line edit. That makes a two-week trial on your slowest job a better decision procedure than any amount of modelling.
jobs:
build:
runs-on: ubuntu-latest # GitHub-hosted
# runs-on: latchkey-small # Latchkey
How to evaluate a managed runner honestly
Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.
- Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
- Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
- Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
- Verify the free tier is recurring. A one-time credit is not a free tier.
The verdict
Public repository: stay on GitHub-hosted.
Private repo, no cloud commitments, no residency requirement: WarpBuild managed is a straightforward 25-33% saving, comparable to the rest of the category rather than distinctive.
Private repo with existing committed cloud spend or a VPC requirement: BYOC at $0.002/min plus your own compute is the strongest structural option here, provided you can own the operational surface it hands back to you.
ARM-capable builds: check the arm64 column before anything else. It is the biggest number on this page.