Kay

Posted on Nov 15 Originally published at latchkey.dev

Fastest GitHub Actions runners: what is actually published

#githubactions #devops #cicd #cloud

On the only public cross-vendor benchmark, RunsOn's suite last run on 5 November 2026, the fastest 2 vCPU Linux runner on one thread is Namespace at a PassMark score of 4,551, ahead of RunsOn's own runner at 4,245, WarpBuild at 4,034 and Blacksmith at 3,985, against 2,299 for GitHub-hosted. GitHub-hosted still starts a job first, in about 3 seconds at the median against 10 to 27 seconds for the third-party fleets, so the fastest runner depends on whether your job waits on CPU, cache or the queue.

Every provider with a 2 vCPU x64 runner in the only cross-vendor suite published in this market, run by RunsOn, which ranks itself in it. Last run 5 November 2026, read 2026-11-12.

"Fast" is three questions and vendors answer different ones. A long compile is a single-thread CPU question. A Docker build or a 4 GB dependency cache is a throughput question, about NVMe and network rather than clock. A matrix of 60 short jobs is a queue question, where the time goes before the first step runs. A runner that wins one can lose the other two.

The state of the evidence in November 2026: three vendors publish the processor their runners use, one publishes a cross-vendor benchmark that it also competes in, and the rest publish a multiplier in a headline. Latchkey has not benchmarked these vendors against each other, and a neutral benchmark from this site is planned but does not exist yet, so every number below is somebody else's, with who measured it and when.

Prices and shapes for all eight vendors are in GitHub Actions runner alternatives; this page is only about speed, and only about speed somebody has published a number for.

The one cross-vendor benchmark, and who runs it

RunsOn publishes a running comparison of 93 runners from nine providers, 2 to 12 vCPU on x64 and arm64: PassMark single-thread and all-core scores, sysbench, 7-Zip, disk and network, a 4 GB actions/cache save and restore, real builds, and how long jobs wait when 15 start at once. Its CPU chart ranks each provider by the score its jobs reach 9 times out of 10 (p10), so a runner that sometimes lands on older hardware ranks lower, and its last run was 5 November 2026, with 3 to 5 runs per runner since 23 October. It is also published by a vendor that sells runners and ranks its own families in it, which is the first thing to know.

Read with that attached, it is the best evidence anyone publishes. Below are its Linux x64 results at 2 vCPU, read 2026-11-12: GitHub-hosted plus the four managed vendors in the suite this site prices elsewhere, one row each, the faster tier where a vendor has two. The note has everything that rule leaves out, including the runner ranked second.

Runner label in the suite	Single-thread, p10	Queue in a 15-job burst, p50	Processor the run reported
`nscloud-ubuntu-24.04-amd64-2x8` (Namespace)	4,551	10s	AMD EPYC, model hidden
`warp-ubuntu-2404-x64-2x` (WarpBuild)	4,034	13s	AMD Ryzen 9 9950X
`blacksmith-2vcpu-ubuntu-2404`	3,985	10s	AMD EPYC, model hidden
`ubicloud-premium-2-ubuntu-2404`	2,421	27s	AMD Ryzen 9 7950X3D
`github24-2cpu-x64` (GitHub 2-core, the size a private repository gets)	2,299	3s	AMD EPYC 7763 on 53% of jobs, 9V74 on 33%

Left out of the table, not out of the ranking. RunsOn's own m8azn.large scores 4,245 at a 15-second queue, second of everything at 2 vCPU, and Avrea scores 3,853 at 11 seconds; StarSling has no 2 vCPU runner in the suite. RunsOn and AWS CodeBuild both run in your own AWS account and bill differently: RunsOn charges a flat annual license with no meter and leaves the EC2 time on your AWS bill, while CodeBuild charges per build minute, $0.005 for build.general1.small in its own pricing example, rounded up to the minute (aws.amazon.com/codebuild/pricing, read 2026-11-12), and scores 2,257 at a 21-second queue. Depot and Latchkey are not in the suite at all, so nothing here ranks either of them. Scores are from the 2 vCPU view of the CPU page; queue times are from the burst test on the RunsOn benchmark overview, 75 samples per runner, both read 2026-11-12.

What each vendor publishes about its own hardware

Three vendors name the silicon. Depot says its Intel runners use 4th Gen AMD EPYC Genoa and its Arm runners Graviton4, on EBS at 8,000 IOPS and 250 MB/s, with a RAM-disk accelerator in front of the root disk. Namespace says AMD EPYC for Linux and Windows AMD64, AmpereOne or Apple Silicon for arm64, and, for macOS, most workloads on Apple M4 Pro with some on M2 Pro. Ubicloud says EPYC Genoa on standard and Ryzen 9 on premium.

The rest publish an effect rather than a part number. Blacksmith says its fleet is "modern gaming CPUs" with higher single-thread performance than server parts, that jobs boot in Firecracker microVMs in under 3 seconds, and that its colocated cache quadruples throughput to 400 MB/s. WarpBuild advertises "2x faster builds" and a cold start under 10 seconds with warm pools. Latchkey documents one always-on warm latchkey-small runner plus parked capacity on every plan, with a warm pickup in about two seconds; jobs beyond that cold-start, and Latchkey publishes no cold-start time. That is our own claim and is not benchmarked here either.

The Namespace hardware, plan concurrency and cache-volume figures on this page come from namespace.so/pricing, the WarpBuild claims from warpbuild.com/pricing, and the Latchkey ones from latchkey.dev/documentation/runner-provisioning, all read 2026-11-12, rather than from the reference list below, which is full at five.

Cache and disk are where most of the minutes actually go

The same publisher times a 4 GB actions/cache save and restore on a separate page, last run 5 November 2026. At 2 vCPU on x64 its own runner restores fastest, 7 seconds, but only with its Magic Cache on a RAM-backed tmpfs; Blacksmith restores in 11 seconds and Avrea in 12, ahead of RunsOn's disk-backed runners at 17 and 19, then Namespace at 21 and WarpBuild at 29. GitHub takes 63 seconds, behind CodeBuild at 52 and level with Ubicloud premium at 62. Depot is not in that table either, so its throughput claims stay claims.

None of that is a CPU gap, and on a job that restores a large dependency tree it is worth more than any single-thread score here. The published allowances differ as much as the timings: 10 GB per repository with 7-day eviction on GitHub, 25 GB or 250 GB at up to 1,000 MiB/s on Depot with no branch isolation, 25 GB a week on Blacksmith, no published size on Latchkey, and cache volumes billed at $0.0048 per GB-day on Namespace.

- uses: actions/cache@v4
  id: deps
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('**/package-lock.json') }}

- run: echo "cache-hit=${{ steps.deps.outputs.cache-hit }}"
- run: /usr/bin/time -v npm ci 2>&1 | grep -E 'Elapsed|Percent of CPU'

Queue time is what "slow" usually means

In the numbers above, the fastest start belongs to the slowest CPU: when 15 jobs start at once, GitHub-hosted picks each up in about 3 seconds at p50 while the third-party fleets take 10 to 27. On a 12-minute job that is noise. On a matrix of 60 jobs of 40 seconds, a 20-second start is a third of the wall clock, and no faster core fixes it.

The tail matters more than the median. In the same burst test the 90th-percentile wait at 2 vCPU was 9 minutes 8 seconds on Avrea and 12 minutes 30 seconds on WarpBuild, against 5 seconds on GitHub, 12 on Blacksmith and 14 on Namespace. Ceilings matter too, because a queue that is not the vendor's fault still looks like slowness. GitHub allows 20, 40, 60 or 500 concurrent jobs by plan, Namespace 32, 64 or 160 Linux vCPUs and Latchkey 20, 40 or 80 busy runners; Depot, Blacksmith and WarpBuild each publish unlimited concurrency in their own words.

How to settle it on your own pipeline in an afternoon

A matrix running the identical job on four labels beats any published score, because it runs your code on your cache. Take the job with the most minutes, not the one easiest to move.

jobs:
  bake-off:
    strategy:
      fail-fast: false
      matrix:
        runner:
          - ubuntu-24.04
          - blacksmith-2vcpu-ubuntu-2404
          - depot-ubuntu-24.04
          - latchkey-small
    runs-on: ${{ matrix.runner }}
    steps:
      - uses: actions/checkout@v5
      - run: npm ci && npm test

Run it on a schedule for a week rather than once. One run compares queue luck, twenty runs compare runners. Read the median and the 90th percentile separately: a fleet with a good median and a bad tail is the one that makes people re-run jobs by hand.

The speed that no benchmark on this page measures

Every number above times a job that succeeds. A job that fails for a reason unrelated to your code, such as an out-of-memory kill or a cache service 503, bills its own minutes, then the re-run, then the wait for somebody to notice. Where a few percent of runs are retries, that is larger than the gap between first and last in the CPU table.

It is the axis Latchkey competes on, and the one nobody has benchmarked, ours included. Measure it the cheap way: count the re-runs in a month of workflow history and multiply by the average job length.

The short answer

If your critical path is one long single-threaded step, the published evidence points at Namespace first, then WarpBuild and Blacksmith, in a suite run by RunsOn, which places its own runner second. If it is a large cache, the measured restore times put Blacksmith and Avrea ahead of the other managed fleets, with RunsOn's RAM-backed setup faster still, while Depot, which nobody benchmarks, publishes the strongest claims. If it is a wide matrix of short jobs, queue time and concurrency ceilings decide it, and GitHub-hosted starts fastest of anything measured.

And if you do not know which of the three you have, the bake-off above costs an afternoon and settles it with your own code. A neutral cross-vendor benchmark from this site is planned; until it exists, nothing here claims a ranking it did not measure.

FAQ

Which GitHub Actions runner is fastest overall?

No published evidence answers that, because no single suite covers every vendor and the two that dominate the market on Docker builds are absent from the one that exists. In RunsOn's PassMark suite, last run 5 November 2026, Namespace leads 2 vCPU x64 single-thread at 4,551, with RunsOn's own runner at 4,245, WarpBuild at 4,034 and Blacksmith at 3,985, against GitHub-hosted at 2,299. Depot and Latchkey are not in it.

Are Blacksmith runners really 2x faster than GitHub-hosted?

That is Blacksmith's own claim on its own pricing page, not benchmarked here. What is measured elsewhere is consistent with a large single-thread gap: RunsOn's suite puts its 2 vCPU Ubuntu runner at 3,985 against 2,299 for GitHub-hosted, about 1.7 times. Whether that halves your wall clock depends on how much of your job is one thread on a CPU.

How do I improve GitHub Actions performance when running complex workflows?

Find which bottleneck you have before you shop. Time one job with /usr/bin/time -v and read CPU percentage against wall clock, time the cache step on its own, and read the gap between the trigger and the first step for queue time. A complex workflow usually has all three in different jobs, which is why one runner rarely fixes the whole pipeline.

Why is my GitHub Actions workflow stuck in the queued state?

Either the plan ceiling or the fleet. GitHub allows 20 to 500 concurrent jobs by plan and 5 concurrent macOS jobs below Enterprise, and a job waits when the account is at its ceiling. On third-party runners the start itself is slower: the published p50 queue times in a 15-job burst run from 10 to 27 seconds against about 3 for GitHub-hosted, and the 90th percentile on some fleets runs past 9 minutes.

DEV Community