Skip to content
Latchkey LogoLatchkey home

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.

Per-minute bars: GitHub $0.006, WarpBuild x64 $0.004, arm64 $0.003, Latchkey $0.0025, BYOC $0.002
Five ways to buy one minute of a 2 vCPU Linux runner, read 20 September 2026. The BYOC bar is the WarpBuild fee only; those instances also appear on your own cloud bill.

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.

.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.

FamilySizesRate at the smallest sizeRate at the largest
Ubuntu x64, 22.04 to 26.042 to 32 vCPU$0.004 at 2 vCPU, 8 GB$0.064 at 32 vCPU, 128 GB
Ubuntu arm64, 24.04 and 26.042 to 32 vCPU$0.003 at 2 vCPU, 8 GB$0.048 at 32 vCPU, 128 GB
Ubuntu 26.04 arm64 on Apple silicon6 and 12 vCPU$0.08 at 6 vCPU, 14 GB$0.16 at 12 vCPU, 28 GB
Windows Server 2022 and 20254 to 32 vCPU$0.016 at 4 vCPU, 16 GB$0.128 at 32 vCPU, 128 GB
macOS on M4 Pro6 and 12 vCPU$0.08 at 6 vCPU$0.16 at 12 vCPU
Docker builders16 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.

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?
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.

Related guides

References

Add-ons metered per operation, or included. Latchkey is $0.0025/min at 2 vCPU with the cache in the price. Start free → 30-day trial · No credit card