What WarpBuild GitHub Actions runners are, and how they work
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 and Depot against 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.
jobs:
build:
- runs-on: ubuntu-latest
+ runs-on: warp-ubuntu-latest-x64-2x # 2 vCPU, 8 GB, 150 GB SSDThe 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.
- 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.
Key takeaways
- Install the bot from the WarpBuild dashboard, not the GitHub Marketplace, then put a Runner ID in
runs-on. - Linux x64 is $0.004 to $0.064 from 2 to 32 vCPU with 150 GB of SSD at every size; arm64 is 25% less.
- Caching needs
WarpBuilds/cache@v2, is Linux only, and is metered at $0.20 per GB-month plus $0.0001 an operation. - Docker builders are a separate meter, 16 to 192 vCPU at $0.06 to $0.88 a minute.
- BYOC is $0.002 a minute for runners in your own cloud account, on top of your own cloud bill.
Frequently asked questions
How do I install WarpBuild on my repositories?
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?
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?
Do WarpBuild runners support Windows and macOS?
Related guides
References
- WarpBuild cloud runners: tags, sizes, images, concurrency and the published caveats
- WarpBuild pricing: runner rates, cache and Docker builder meters, BYOC
- WarpBuild caching and the WarpBuilds/cache action
- WarpBuild BYOC setup: cloud account, Stack and custom runners
- Latchkey runner sizes, rates and plans
- GitHub Actions documentation