# What WarpBuild GitHub Actions runners are, and how they work

> How WarpBuild GitHub Actions runners work: the runner tags and rates, a cache that needs its own action, separate Docker builders, and BYOC at $0.002.

Source: https://latchkey.dev/learn/runners/warpbuild-runners-explained  
Updated: 2026-09-20

Warpbuild github actions runners are ephemeral VMs you adopt by installing the WarpBuild bot from its dashboard and putting a Runner ID in `runs-on`. Three things set them apart from the rest of the category: a bring-your-own-cloud mode at a flat $0.002 a minute, Docker builders sold separately by the minute, and a cache that needs its own action instead of intercepting `actions/cache`.

WarpBuild sells three products that overlap: cloud runners on its own hardware, Docker builders you attach to a job, and the same runners deployed inside your AWS, GCP or Azure account. The runners are drop-in replacements for GitHub-hosted ones, with the same tooling in the images and the same GitHub Actions around them.

Everything here was read from warpbuild.com on 20 September 2026 and is dated on the page. For the head-to-heads, [WarpBuild against Blacksmith](/learn/runners/warpbuild-vs-blacksmith) and [Depot against WarpBuild](/learn/runners/depot-vs-warpbuild) carry the comparison tables.

## Getting on: a bot, then a Runner ID

The install order is what catches people. The WarpBuild bot cannot be installed from the GitHub Marketplace: sign up at the WarpBuild dashboard first and install it from there, granting access to the repositories that will use the runners. Then change `runs-on` to a Runner ID from the dashboard, or let the "Select workflows to Warp" flow edit the workflows for you.

Runners are ephemeral VMs, freshly allocated for a job and destroyed when the workflow completes, and the Linux and Windows images carry the same tooling as GitHub-hosted runners.

```.github/workflows/ci.yml
jobs:
   build:
-    runs-on: ubuntu-latest
+    runs-on: warp-ubuntu-latest-x64-2x      # 2 vCPU, 8 GB, 150 GB SSD
```

## The runner tags, and what each one costs

Tags read as platform, architecture and size: `warp-ubuntu-latest-x64-8x` is an 8 vCPU Ubuntu 24.04 machine. Every standard Linux tier carries 150 GB of SSD regardless of size, the 12 vCPU Apple-silicon tier carries 300 GB, and arm64 is priced 25% below x64 at every step.

| Family | Sizes | Rate at the smallest size | Rate at the largest |
| --- | --- | --- | --- |
| Ubuntu x64, 22.04 to 26.04 | 2 to 32 vCPU | $0.004 at 2 vCPU, 8 GB | $0.064 at 32 vCPU, 128 GB |
| Ubuntu arm64, 24.04 and 26.04 | 2 to 32 vCPU | $0.003 at 2 vCPU, 8 GB | $0.048 at 32 vCPU, 128 GB |
| Ubuntu 26.04 arm64 on Apple silicon | 6 and 12 vCPU | $0.08 at 6 vCPU, 14 GB | $0.16 at 12 vCPU, 28 GB |
| Windows Server 2022 and 2025 | 4 to 32 vCPU | $0.016 at 4 vCPU, 16 GB | $0.128 at 32 vCPU, 128 GB |
| macOS on M4 Pro | 6 and 12 vCPU | $0.08 at 6 vCPU | $0.16 at 12 vCPU |
| Docker builders | 16 to 192 vCPU | $0.06 at 16 vCPU, 32 GB | $0.88 at 192 vCPU, 384 GB |

Four published details are worth carrying into a migration. Windows 2-vCPU runners were removed on 8 June 2026, so the Windows ladder now starts at 4 vCPU, and cloud spot runners were removed the same day, leaving BYOC as the route to spot capacity. The arm64 Ubuntu 24.04 image sets its working directory to `/runner/_work` rather than GitHub's `/home/runner/work/`, which breaks any script that hardcodes the GitHub path. Nested virtualization is available on x64 through a dynamic label but not on arm64 or macOS, so Android emulator jobs have one place to run. And the macOS runners are mid-change: the published table lists 14 GB at 6 vCPU and 28 GB at 12, with a note that until 1 October 2026 they carry 22 GB and 44 GB at unchanged prices.

## Caching is an action, not an interception

This is the clearest difference between WarpBuild and its closest competitor. Blacksmith redirects the standard cache actions transparently; WarpBuild asks you to swap `actions/cache@v4` for `WarpBuilds/cache@v2`, which it documents as a fully compatible drop-in with the same inputs and the same `cache-hit` output, plus `WarpBuilds/cache/restore` and `/save` for split workflows. It is a one-line change per cache step rather than zero, and it is a line you have to remember to revert if you ever leave.

The cache itself is described as unlimited and is enabled by default on all Linux runners. Two limits are published rather than hidden: it is not supported on Windows runners, and it is metered, at $0.20 per GB-month for storage plus $0.0001 for every cache write or restore operation. A 50 GB cache with 10,000 operations in a month is $10 plus $1, which is small but not zero, and it is the shape of pricing Blacksmith does not have at all.

```The cache step change WarpBuild needs
- uses: actions/cache@v4          # on GitHub-hosted
+ uses: WarpBuilds/cache@v2        # on WarpBuild
  with:
    path: ~/.npm
    key: ${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
```

## Docker builders are a separate purchase

A WarpBuild Docker builder is not the runner: it is a much larger machine, from 16 vCPU with 100 GB of disk up to 192 vCPU with 2 TB, that your job attaches to and that is billed by the minute on its own meter, from $0.06 to $0.88. Each builder profile is shared across the jobs that use it, with no hard concurrency limit.

The arithmetic before enabling one: 200 builds a month at three minutes each on the 16 vCPU builder is 600 builder minutes, or $36 on top of the runner minutes. Worth it if it turns a 12-minute build into 3, money for nothing if the Dockerfile was never the bottleneck. Snapshot restore is priced separately again at $0.04 a job, with snapshot storage at $0.025 an hour.

## BYOC: the same runners inside your cloud account

Bring your own cloud is where WarpBuild goes furthest. Depot sells deployment into your own AWS account on its Business plan, and Blacksmith sells nothing of the kind, while WarpBuild publishes AWS, GCP and Azure on its standard rate card. You connect a cloud account, which creates an IAM role or service account; you define a Stack, which is a region, a VPC, subnets and an object storage bucket used for cache, image layers and logs; and you create custom runners whose Runner IDs are prefixed `warp-custom-`. The dashboard drives all three steps.

WarpBuild charges $0.002 a minute for Linux and Windows runners in BYOC mode, and says caching and every other add-on is free there. Read that as the WarpBuild fee: the instances run in your account, so the VM time lands on your own cloud bill, which its pricing page does not itemize. Against the $0.004 managed rate you are trading half the vendor fee for your own spot capacity, quotas and region choice, plus that bill.

## Concurrency, billing granularity and what is not published

- Concurrency is unlimited on generally available Linux and Windows runners; features still in beta may not be. High concurrency on macOS is a conversation with sales.
- Billing granularity is per minute, stated in its own FAQ, so there is no per-second advantage the way there is at Depot.
- No free allowance is published. The FAQ mentions hitting "free usage or credit limits" without naming a number, so a budget should assume zero free minutes until support confirms otherwise.
- SOC2 Type II with an annual audit, a public trust center, and SAML SSO priced at $250 a month.
- Enterprise adds a 99.9% SLA backed by credits, warm pools that WarpBuild says start jobs in under 10 seconds, custom AMIs, region-specific infrastructure, and a guarantee of 40% below actions-runner-controller on Kubernetes.

## Best at, and where it falls short

Best at: breadth from one dashboard. Managed runners, Docker builders to 192 vCPU, Linux on Apple silicon, which Namespace also sells, and a BYOC mode on three clouds, where Depot offers AWS alone and only on its Business plan. Its arm64 rate of $0.003 is the cheapest published arm64 here apart from Blacksmith's $0.0025.

Where it falls short: the cache needs an action swap and does not work on Windows, no free tier is published, Windows starts at 4 vCPU so the cheap tier other vendors sell does not exist, managed spot is gone, and the arm64 working-directory disparity is a real migration trap. Billing is per minute, so short jobs round up as they do on GitHub.

## What a Latchkey user would notice

WarpBuild sells four things we do not: arm64, Windows, macOS and a BYOC mode whose $0.002 fee is below our $0.0025 a minute, before your cloud bill. Its managed x64 rate of $0.004 is 60% above ours at the same 2 vCPU and 8 GB.

The other difference is the one both rate cards leave out. WarpBuild gives a failing job faster hardware and, on Enterprise, a faster start; it does nothing about the failure itself. On a Latchkey runner a registry timeout or an out-of-memory kill is diagnosed and retried inside the same job, which is described in [self-healing](/documentation/self-healing).

## FAQ

### How do I install WarpBuild on my repositories?

Sign up at the WarpBuild dashboard first, because the GitHub bot cannot be installed from the GitHub Marketplace. The signup flow redirects you to the bot installation, where you grant access to the repositories that will use the runners. After that, change `runs-on` to a Runner ID from the dashboard, or use the "Select workflows to Warp" button to have it edited for you.

### Does the WarpBuild cache work with actions/cache?

Not directly. You replace `actions/cache@v4` with `WarpBuilds/cache@v2`, which WarpBuild documents as a fully compatible drop-in with the same inputs and outputs, and there are matching `restore` and `save` actions. The cache is enabled by default on Linux runners, is not supported on Windows runners, and is billed at $0.20 per GB-month plus $0.0001 per write or restore.

### What are WarpBuild Docker builders, and do I need one?

They are separate machines from 16 to 192 vCPU that your job attaches to for Docker builds, billed on their own meter from $0.06 to $0.88 a minute, with each builder profile shared across the jobs using it. You need one when the image build is the slow part of the pipeline. If it is not, the builder adds a second meter to a job that was never bottlenecked on it.

### Do WarpBuild runners support Windows and macOS?

Both. Windows Server 2022 and 2025 run from 4 to 32 vCPU at $0.016 to $0.128 a minute, with a Visual Studio 2026 image variant, and the 2-vCPU Windows runners were removed on 8 June 2026. macOS runs on M4 Pro at 6 and 12 vCPU for $0.08 and $0.16. Note that the cache is not supported on Windows runners and macOS cannot run Docker.

## References

- [WarpBuild cloud runners: tags, sizes, images, concurrency and the published caveats](https://www.warpbuild.com/docs/ci/cloud-runners)
- [WarpBuild pricing: runner rates, cache and Docker builder meters, BYOC](https://www.warpbuild.com/pricing)
- [WarpBuild caching and the WarpBuilds/cache action](https://www.warpbuild.com/docs/ci/caching)
- [WarpBuild BYOC setup: cloud account, Stack and custom runners](https://www.warpbuild.com/docs/ci/byoc)
- [Latchkey runner sizes, rates and plans](https://latchkey.dev/pricing)

---

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