Fastest GitHub Actions runners: what is actually published

By Daniel Zoghalchali·Latchkey

Every list of the fastest GitHub Actions runners you will find, including this one, is built on numbers somebody else measured. Latchkey has not benchmarked these vendors against each other, so nothing here is ranked by a speed this site measured: what follows is the hardware each vendor publishes, the one cross-vendor benchmark that exists and who runs it, and the method for settling it on your own pipeline in an afternoon.

"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 honest state of the evidence in September 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. A neutral benchmark from this site is planned and does not exist yet, so nothing below is presented as one.

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 nine providers on Linux runners: Passmark single-thread, disk throughput, and a 4 GB actions/cache save and restore. It states its method, gives p50 and p90 over the last 30 days from 15 samples on most rows and 4 to 23 across the table, and was updated on 2 September 2026. 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 rows at 2 vCPU, read 2026-09-20: 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 provider ranked second.

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 M5 Max with some on M4 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 "2-10x faster builds" and a cold start under 10 seconds from warm pools. Latchkey publishes a warm pool on its Launch and Scale plans, from $19 a month rather than its $5 one, and a roughly 10-second cold start, which is our own claim and is not benchmarked here either.

Cache and disk are where most of the minutes actually go

The same publisher times a 4 GB save and restore on a separate page, updated 8 July 2026, and that table does not flatter it. Blacksmith is fastest at 25 seconds with its own cache action and 32 seconds with actions/cache; Namespace does 27 seconds on the standard action and Avrea 35, both ahead of RunsOn at 38. GitHub takes 89 seconds. At the far end, WarpBuild takes 142 seconds with its own action and 649 with the standard one. 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, 25 GB 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: GitHub-hosted starts in about 6 seconds at p50 while the third-party fleets take 11 to 24. 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.

Ceilings matter here 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 and Namespace 32, 64 or 160 Linux vCPUs; 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

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 Avrea and Blacksmith, in a suite run by RunsOn, which places its own families among them. If it is a large cache, the measured save and restore times put Blacksmith and Namespace ahead of everything benchmarked, 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.

Frequently asked questions

Related guides

References

• RunsOn benchmarks: cross-provider Passmark single-thread and queue times, updated 2 September 2026 (verified 2026-09-20)
• RunsOn benchmarks: 4 GB cache save and restore across providers, updated 8 July 2026 (verified 2026-09-20)
• Depot GitHub Actions runners: EPYC Genoa and Graviton4, cache throughput, per-second tracking (verified 2026-09-20)
• Blacksmith runners: Firecracker boot times, colocated cache throughput and regions (verified 2026-09-20)
• GitHub Actions limits: concurrent jobs by plan and cache storage per repository (verified 2026-09-20)
• GitHub Actions documentation