WarpBuild vs Namespace for GitHub Actions runners

By Kaveh Alemi·Latchkey

WarpBuild vs Namespace lands on the same Linux number twice: a 2 vCPU runner with 8 GB is $0.004 a minute on WarpBuild and $0.004 prepaid on Namespace. The decision is made everywhere else, and mostly in two places: Namespace is a third cheaper on macOS, and the two meter their caches in units that behave nothing alike.

WarpBuild sells managed cloud runners at a published per-minute rate with no plan fee, a bring-your-own-cloud mode at $0.002 a minute inside your own AWS, GCP or Azure account, and remote Docker builders as a separately billed product. Cache is an add-on with its own meters rather than an allowance, and every add-on is free under BYOC.

Namespace sells compute in unit minutes across devboxes, Docker builds and runners. A unit is 1 vCPU with 2 GB of RAM for a minute times a platform multiplier, prepaid rates sit inside a plan and overage rates are half again as much outside it, and caches are sold as volumes billed by GB-hour and GB-day with plan allowances on top. It also sells Bazel, Turborepo and Gradle remote caches as products of their own.

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.

WarpBuild, Namespace and Latchkey side by side (read 21 September 2026)

Where the Linux tie breaks

The headline rates are identical at the two Linux sizes both vendors sell, so the tie has to break somewhere else, and it breaks on which column you are actually in. Namespace's $0.004 is the prepaid rate, available only inside a plan; its overage rate is $0.006, which is 50% more and level with GitHub-hosted. WarpBuild's $0.004 has no plan behind it and no cheaper column to reach.

So the comparison is really between a commitment and a flat rate. If you can forecast usage, Namespace matches WarpBuild on Linux and hands you a lower macOS rate as well. If you cannot, Namespace overage is half again what WarpBuild charges, and the flat rate wins.

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 sub-ten-second cold start with warm pools on Enterprise. Namespace argues from hardware: AMD EPYC for amd64, AmpereOne or Apple silicon for arm64, Apple M4 Pro for most macOS work with some on M2 Pro. Both are vendor statements with no shared workload behind them, and neither transfers.

The structural difference that does transfer is what happens when you widen a matrix. WarpBuild advertises unlimited concurrency; Namespace caps it by plan and counts it in vCPU, so 64 vCPU on Team is thirty-two 2 vCPU jobs or eight 8 vCPU ones and not both. A matrix that fans out to fifty jobs on 4 vCPU machines needs 200 vCPU of headroom, which is past the Business tier. That is a planning number, not a speed number, and it is the one to check first.

Cost: the same month, where macOS decides it

The workload every comparison here uses: 10,000 Linux minutes at 2 vCPU plus 2,000 macOS minutes on a private repository. Both vendors sell macOS, so both rows are complete, which is rarer in this corpus than it should be.

Namespace takes this month by $10 and the entire margin is macOS. Its 6 vCPU Apple silicon shape prices at $0.06 a minute inside a plan against WarpBuild's $0.08, which on 2,000 minutes is a $40 swing, and it is the only thing offsetting a $100 plan fee that WarpBuild does not charge. Take macOS out and WarpBuild wins outright: $40 flat against a $100 plan that 40,000 unit minutes does not fill. 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.

Then the caches, where the two are furthest apart and neither is obviously better. WarpBuild bills storage by the GB-month and every operation individually. Namespace bills a cache volume in two units at once: GB-hours while it is attached to a running instance, and GB-days for the storage itself, with real free allowances on the paid plans.

Work one case. Keep a 50 GB cache and attach it to instances for 100 hours in a month. On WarpBuild that is 50 GB at $0.20, which is $10, plus operations. On Namespace it is 5,000 GB-hours of snapshot, exactly the Team allowance, plus 1,500 GB-days of storage against 3,000 free, so it is zero on Team and $17.20 on Developer. The Namespace bill is free until you cross an allowance and then climbs on two axes; the WarpBuild bill is small and linear from the first gigabyte. Which is cheaper depends on how long your volumes stay attached, which is a number most teams have never measured.

Reliability

WarpBuild publishes the stronger set of commitments and prices them: SOC 2 Type II with annual audits and penetration testing, a contractual 99.9% uptime SLA backed by credits, region-specific infrastructure where the data stays in a chosen region, SAML SSO at $250 a month and SCIM provisioning. Namespace publishes limits rather than promises: 32, 64 and 160 vCPU of Linux concurrency by plan, macOS on its own ladder, and a maximum job duration of 3 hours on Developer, 5 on Team and up to 24 above that.

Those are answers to different questions, and the job-duration cap is the one that catches people out. GitHub's own limit is 6 hours, so a long integration suite that runs comfortably on GitHub-hosted can be cut short on the Namespace Developer plan, and the failure looks like a timeout rather than a billing limit. GitHub Actions job timed out covers how to tell a platform cap from a hung test.

Neither vendor repairs a job that failed mechanically. Both bill the minutes the failed attempt burned and both bill the re-run, and on Namespace the failed attempt also consumed unit minutes from a plan you prepaid.

When to choose WarpBuild

• You cannot forecast usage. A flat $0.004 with no plan beats an overage rate of $0.006, and there is no commitment to get wrong.
• You want the runners inside your own cloud. BYOC at $0.002 a minute with every add-on free has no equivalent on the Namespace price list.
• You are fanning out wide. Unlimited advertised concurrency against a vCPU cap by plan is the difference between a matrix that runs and a matrix that queues.
• You need SOC 2 Type II, a contractual SLA or data residency in a named region, and you need them written down.
• Your Docker builds are large enough to want a 16 to 192 vCPU remote builder rather than a per-build charge.

When to choose Namespace

• Your bill is mostly macOS. At $0.06 a minute prepaid for a 6 vCPU machine Namespace is a quarter under WarpBuild and below GitHub-hosted too, and on an iOS pipeline nothing else on this page is worth as much.
• You can sit inside a plan. Prepaid is a third under overage at every Linux row, and the plan minutes are the purchase rather than a fee on top of one.
• You want cache as a volume rather than a key-value store. A cache volume that reattaches is a different tool from a cache that uploads and downloads, and it suits large working sets that never fit a tarball.
• You already run Bazel, Turborepo or Gradle remote caches and would rather buy them from the vendor running your compute.
• Your Docker builds are numerous and small. A metered build at $10 per 1,000 past the plan allowance is cheaper than a builder minute if each build is short.

Switching: the exact diff

Both are runs-on changes. Namespace encodes the shape in the label and takes a suffix to attach a cache volume; WarpBuild names a size. Run both on the same workflow for a fortnight before you decide, because the two things that will actually decide it, your macOS share and how long your cache volumes stay attached, are numbers you do not have yet.

 jobs:
   test-on-warpbuild:
-    runs-on: ubuntu-latest
+    runs-on: warp-ubuntu-latest-x64-4x
     steps:
       - uses: actions/checkout@v7
       - run: pnpm install && pnpm test

   test-on-namespace:
-    runs-on: ubuntu-latest
+    runs-on: nscloud-ubuntu-24.04-amd64-4x16-with-cache
     steps:
       - uses: actions/checkout@v7
       - run: pnpm install && pnpm test

The verdict

These two are level on Linux and the tie breaks on two questions you can answer today. What share of your bill is macOS, and can you commit to a plan? If the answer is a lot and yes, Namespace is the better buy: $0.06 a minute for a 6 vCPU Apple silicon machine is under WarpBuild and under GitHub, and on an iOS pipeline that single row outweighs everything else on this page. If the answer is not much, or you cannot forecast, WarpBuild wins on a flat rate with no plan fee and an overage rate that does not exist, and bring-your-own-cloud at $0.002 a minute with free add-ons is a floor Namespace does not have a product for. The caches are a genuine coin toss until you measure how long your volumes stay attached. Neither vendor repairs the job that failed for a reason unrelated to your code, and on a prepaid plan that failed attempt has already spent minutes you bought in advance.

Frequently asked questions

Related guides

References

• WarpBuild pricing: cloud runners, BYOC, Docker builders and add-on meters (verified 2026-09-21)
• Namespace pricing: unit minutes, shape tables, cache volumes and plan allowances (verified 2026-09-21)
• Namespace runner labels, shapes and cache volumes (verified 2026-09-21)
• GitHub Actions documentation