# WarpBuild vs GitHub hosted runners, and its three meters

> WarpBuild vs GitHub hosted runners: managed, bring-your-own-cloud and Docker builders priced separately, against one bundled metered bill.

Source: https://latchkey.dev/learn/runners/warpbuild-vs-github-hosted-runners  
Updated: 2026-09-21

WarpBuild vs GitHub hosted runners is a comparison between one bundled bill and three separate meters. GitHub charges $0.006 a minute for a 2 vCPU Linux runner with the cache, the artifacts and the operations folded in; WarpBuild charges $0.004 for the runner, prices Docker builders from $0.06 a minute as a different product, and meters cache storage, cache operations and snapshots as add-ons.

GitHub-hosted runners are the default. On a private repository the standard Linux x64 runner is 2 vCPU with 8 GB at $0.006 a minute, Linux arm64 is $0.005, Windows is $0.010 and macOS is $0.062, with included minutes by plan, 10 GB of cache per repository and artifact storage pooled with GitHub Packages. On a public repository the standard runners are free.

WarpBuild sells three things from one account, and it matters which one a quoted price refers to. Managed cloud runners run in WarpBuild's cloud at $0.004 a Linux minute. Bring-your-own-cloud runners run inside your own AWS, GCP or Azure account at $0.002 a minute to WarpBuild, with the compute on your cloud bill and the add-ons free. Remote Docker builders are a separate product billed by the minute from $0.06 for a 16 vCPU builder up to $0.88 for 192 vCPU with 2 TB of disk.

Every cell below was read from the vendor's own public pricing or documentation page on 21 September 2026. Where a vendor does not publish a number, the cell says "not published" instead of carrying a guess.

## Comparison

|  | WarpBuild | GitHub-hosted | Latchkey |
| --- | --- | --- | --- |
| Price per minute, 2 vCPU Linux x64 | $0.004 managed (2 vCPU, 8 GB RAM), or $0.002 under BYOC inside your own cloud account | $0.006 on a private repository, free on a public one | **$0.0025** (2 vCPU, 8 GB RAM, 100 GB disk) |
| Price per minute, 4 vCPU Linux x64 | $0.008 managed (4 vCPU, 16 GB RAM), or $0.002 a minute under BYOC at any size | $0.012 for the 4-core larger runner | **$0.005** (4 vCPU, 16 GB RAM, 100 GB disk) |
| Free tier | Not published as an allowance. Sign-up needs no card until you reach a usage or credit limit | 2,000 minutes a month on Free and 3,000 on Pro and Team, 50,000 on Enterprise Cloud, plus unlimited free standard runners on public repositories | 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, rounded up per job, charged to the repository owner | Per minute |
| Runner sizes and OS | 2 to 32 vCPU on Linux x64 and arm64, arm64 at three quarters the x64 rate; Windows from 4 vCPU; macOS M4 Pro at 6 and 12 vCPU; Linux on Apple silicon at 6 and 12 vCPU | Standard 2-core Linux and Windows, 3 or 4-core macOS, and larger runners to 96 vCPU on paid plans | 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 rather than allowanced: $0.20 per GB-month of storage plus $0.0001 for every write or restore, with snapshot restore at $0.04 a job and snapshot storage at $0.025 an hour. Free under BYOC | 10 GB per repository included, configurable higher at $0.07/GB/month; entries unused for 7 days removed, oldest evicted first once the limit is hit | 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 Docker builders as a separate product, 16 vCPU at $0.06/min up to 192 vCPU with 2 TB of disk at $0.88/min, driven by `Warpbuilds/build-push-action@v7`, with a builder profile shared across jobs and no hard concurrency limit | `type=gha`, which writes layers into the same 10 GB per-repository store `actions/cache` uses | `latchkey-dev/docker-cache-action@v1`, layers held in a Latchkey-managed private registry per organization |
| Concurrency limits | Advertised as unlimited job concurrency, with a contractual no-queue guarantee and a 99.9% SLA only on Enterprise | By plan: a documented cap on concurrent jobs per account, separate for macOS | Not published; warm-pool capacity varies by plan |
| Where jobs run | WarpBuild's own cloud, or your AWS, GCP or Azure account under BYOC, with region-specific infrastructure on Enterprise | Microsoft Azure, in GitHub's own subscription | 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 | Not offered | Built in: transient failures are diagnosed and retried inside the run |
| Setup change required | Change the `runs-on` label for managed runners; BYOC additionally deploys into your own cloud account | None. `runs-on: ubuntu-latest` is the default | A `runs-on` label change. GitHub organization accounts only |

## One bundled meter against three unbundled ones

The rate comparison is easy and slightly misleading. WarpBuild is a third cheaper than GitHub at every Linux size, $0.004 against $0.006 at 2 vCPU and $0.008 against $0.012 at 4 vCPU, and cheaper again at $0.002 under bring-your-own-cloud. That is the part every comparison prints.

The part worth checking is what each rate includes, because GitHub bundles things WarpBuild sells separately. GitHub gives you 10 GB of cache per repository with no charge for reads or writes. WarpBuild charges $0.20 per GB-month of cache storage and $0.0001 for every single write or restore operation, and prices snapshot restore at $0.04 a job on top. None of those are large, and they are meters GitHub does not run at all, so a like-for-like month has to add them.

| Meter | WarpBuild managed | WarpBuild BYOC | GitHub-hosted |
| --- | --- | --- | --- |
| Runner minute, 2 vCPU Linux | $0.004 | $0.002 plus your own cloud bill | $0.006 |
| Cache storage | $0.20 per GB-month | Free | 10 GB free per repo, then $0.07 per GB-month |
| Cache write or restore | $0.0001 per operation | Free | No charge |
| Snapshot restore | $0.04 per job | Free | Not offered |
| Snapshot storage | $0.025 per hour per snapshot | Free | Not offered |
| Docker build | $0.06 to $0.88 a minute on a separate builder | Same builder rates | Runs on the runner minute you already bought |
| Artifact storage | Still GitHub: artifacts do not move with the runner | Still GitHub | Pooled with Packages, then $0.25 per GB-month |

> Rates from the WarpBuild pricing page and the GitHub Actions billing reference, both read 21 September 2026. The networking add-on on WarpBuild, a Tailscale integration, is listed as free on managed and BYOC alike.

## 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 fortnight, because runner selection is per job and the Actions run log hands you the timings for free.

WarpBuild advertises 2 to 10x faster builds and a cold start under ten seconds with warm pools, the second of which is an Enterprise feature. GitHub publishes no speed claim at all, because it is the thing everyone else measures against. Neither statement is a number you can carry to your own repository.

What is measurable for free is your own queue time, and it is the axis where the two genuinely differ in kind. GitHub caps concurrent jobs by plan; WarpBuild advertises unlimited concurrency and sells the contractual no-queue guarantee separately on Enterprise. If your pipeline fans out to a hundred matrix jobs and half of them sit queued, that is a concurrency cap rather than a slow runner, and [job stuck queued waiting for a runner](/learn/failures/job-stuck-queued-waiting-for-runner) is the page that tells the two apart before you buy anything.

## Cost: the same month, with the add-ons counted

The workload every comparison here uses: 10,000 Linux minutes at 2 vCPU plus 2,000 macOS minutes on a private repository. WarpBuild sells macOS, so unlike several vendors in this corpus its row is complete.

|  | 10,000 Linux minutes at 2 vCPU | 2,000 macOS minutes | Monthly total |
| --- | --- | --- | --- |
| WarpBuild managed | $40 at $0.004/min | $160 at $0.08/min for the 6 vCPU M4 Pro | $200 before cache metering |
| WarpBuild BYOC | $20 at $0.002/min, plus your own cloud bill | Not offered under BYOC: $160 managed | $180 plus your cloud bill |
| GitHub-hosted | $60 at $0.006/min | $124 at $0.062/min | $184 |
| Latchkey | $25 at $0.0025/min | Not offered: $124 on GitHub-hosted | $149 plus $5 to $49 a month for the plan |

On Linux minutes WarpBuild is a third under GitHub and BYOC is two thirds under, and on macOS it is 29% dearer than GitHub at $0.08 against $0.062. That is why the month lands at $200 against $184 rather than comfortably below it: this workload is two thirds macOS, and the Linux saving is not big enough to cover a premium on the expensive part. A pipeline with no macOS reverses the result at once, $40 against $60. 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.

Now add the meters GitHub does not run, and the surprise is how small they are at ordinary volumes. A repository holding 20 GB of cache pays $4 a month of storage. A pipeline doing 300 cache operations a day, which is a busy repository, pays 9,000 operations at $0.0001, which is 90 cents. The per-operation charge is not where WarpBuild gets expensive.

Where it does get expensive is the builder, and that is the line to model before you commit. A remote Docker builder is a separate meter at $0.06 a minute for the smallest 16 vCPU profile, so a pipeline running two hundred five-minute image builds a month adds $60, which is more than its entire Linux runner bill in the table above. On GitHub-hosted that build runs on the runner minute you already bought, slower and with a 10 GB shared cache. Those are two different products and the right comparison depends entirely on whether your images are large.

## Reliability

WarpBuild publishes more in this area than most of its peers, and most of it is Enterprise. It states SOC 2 Type II compliance with annual audits and penetration testing, offers a 99.9% uptime SLA backed by credits on a contractual basis, and sells region-specific infrastructure where your data stays in a chosen region with no cloud ingress or egress cost, excluding macOS. GitHub publishes a status page and no Actions SLA on the pages read here.

BYOC changes the reliability question rather than answering it. Runners execute inside your own AWS, GCP or Azure account, which means your network boundary, your quotas and your capacity, and WarpBuild's claim there is a guaranteed 40% infrastructure saving against actions-runner-controller on Kubernetes. Whether that is your comparison depends on whether you were already running ARC, and [migrate from actions-runner-controller](/learn/runners/migrate-from-actions-runner-controller) covers what moving off it involves.

The failure mode neither side addresses is the ordinary one. A dependency mirror times out, a browser binary fails to download, a container is killed for memory: the job dies, the minutes bill, and the re-run bills again. On a pipeline with a separate builder meter running, a failed build burns two meters rather than one.

## When to choose WarpBuild

- Your pipeline is Linux and private. A third off every size with no plan fee and no commitment is the simplest saving on this page.
- You have a cloud account and enough volume to care. BYOC at $0.002 a minute with every add-on free is the cheapest arrangement here, and the compute lands on a bill you may already have committed spend against.
- Your Docker builds have outgrown the runner. A 16 vCPU builder shared across jobs with no hard concurrency limit is a different machine from a 2 vCPU runner doing the same work.
- You need a contractual SLA, SOC 2 Type II or data residency in a named region, all of which GitHub-hosted does not offer for Actions.
- You are queueing. Unlimited job concurrency is the differentiator against a plan-capped account, and it is worth measuring before you buy a faster machine.

## When to stay on GitHub-hosted

- Your repositories are public. Standard runners are free and unlimited there, and no rate beats zero.
- Your bill is mostly macOS. WarpBuild charges $0.08 a minute for a 6 vCPU M4 Pro against GitHub's $0.062, so the expensive part of your bill goes up rather than down.
- You are inside your included minutes and expect to stay there. Three thousand minutes a month on Pro and Team is an allowance you are not paying for.
- You do not want a cache bill. GitHub gives 10 GB per repository with no per-operation charge; WarpBuild meters storage and every read and write, small as those numbers are.
- You want one vendor, one invoice and one support channel when a runner misbehaves at five on a Friday.

## Switching: the exact diff

Managed runners are a label change and nothing else. The Docker builder is a second decision with its own action and its own meter, so make it separately and after you have a baseline, or you will not know which change moved the timing or the bill.

```.github/workflows/ci.yml
jobs:
   test:
-    runs-on: ubuntu-latest
+    runs-on: warp-ubuntu-latest-x64-4x
     steps:
       - uses: actions/checkout@v7
       - run: npm ci && npm test

   image:
-    runs-on: ubuntu-latest
+    runs-on: warp-ubuntu-latest-x64-4x
     steps:
       - uses: actions/checkout@v7
-      - uses: docker/build-push-action@v7
+      - uses: Warpbuilds/build-push-action@v7
         with:
           context: .
+          profile-name: my-builder-profile
```

> The second job is where the separate meter starts. `Warpbuilds/build-push-action@v7` sends the build to a remote builder profile billed from $0.06 a minute, so the image job stops consuming the runner rate in the first job and starts consuming a builder rate instead.

## The verdict

For a private Linux pipeline WarpBuild is straightforwardly cheaper than GitHub-hosted, a third off at every size with nothing to commit to, and bring-your-own-cloud at $0.002 a minute with free add-ons is the lowest managed-runner arrangement in this corpus if you already have a cloud account worth putting it in. Read the rest of the rate card before you model a month. Its macOS minute is dearer than GitHub's, which matters a great deal on a pipeline that builds iOS, and cache storage, cache operations and snapshots are meters GitHub does not run, even though at ordinary volumes they add single-digit dollars. The remote Docker builder is the line that can double a small bill, and it is also the reason to buy WarpBuild in the first place if your images are large. On a public repository GitHub-hosted is free and none of this arithmetic applies. Neither of them repairs a job that failed for a reason unrelated to your code, and with two meters running that failed job costs twice.

## FAQ

### How much do WarpBuild runners cost?

Managed Linux x64 runners are $0.004 a minute at 2 vCPU with 8 GB and double at each size step to $0.064 at 32 vCPU. Linux arm64 is three quarters of that, $0.003 at 2 vCPU. Windows starts at 4 vCPU for $0.016, macOS M4 Pro is $0.08 at 6 vCPU, and bring-your-own-cloud is $0.002 a minute at any Linux size with the compute on your own cloud bill.

### What is WarpBuild BYOC and what does it change?

Bring-your-own-cloud runs the runners inside your own AWS, GCP or Azure account. You pay WarpBuild $0.002 a minute instead of $0.004, every add-on including cache becomes free, and the compute appears on your cloud invoice rather than WarpBuild's. WarpBuild advertises a guaranteed 40% infrastructure saving against actions-runner-controller on Kubernetes for that arrangement.

### Does WarpBuild charge for GitHub Actions cache?

On managed runners, yes, on three meters: $0.20 per GB-month of cache storage, $0.0001 for each write or restore operation, and $0.04 per job for a snapshot restore with snapshot storage at $0.025 an hour. Under BYOC the add-ons are free. GitHub charges nothing for cache operations and includes 10 GB per repository before its $0.07 per GB-month storage rate.

### Are WarpBuild Docker builders billed separately from the runners?

Yes, and it is the easiest line to miss. A remote builder is its own product with its own per-minute rate, from $0.06 for 16 vCPU with 32 GB and 100 GB of disk up to $0.88 for 192 vCPU with 2 TB. Each builder profile is shared across jobs using it with no hard concurrency limit, so two hundred five-minute builds a month is $60 on top of whatever the runners cost.

## References

- [WarpBuild pricing: cloud runners, BYOC, Docker builders and add-on meters (verified 2026-09-21)](https://www.warpbuild.com/pricing)
- [GitHub Actions billing: per-minute rates, storage rates and plan allowances (verified 2026-09-21)](https://docs.github.com/en/billing/concepts/product-billing/github-actions)
- [GitHub Docs: dependency caching limits, eviction and the 10 GB repository allowance (verified 2026-09-21)](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching)

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt