# Fastest GitHub Actions runners: what is actually published

> The fastest GitHub Actions runners, judged only on published hardware and published benchmarks, with who ran each number and when it was read.

Source: https://latchkey.dev/learn/runners/fastest-github-actions-runners  
Updated: 2026-09-20

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](/learn/runners/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.

| Runner label in the suite | Single-thread, p50 | Queue to first step, p50 | Processor the run reported |
| --- | --- | --- | --- |
| `nscloud-ubuntu-24.04-amd64-2x8` (Namespace) | 4,686 | 11s | AMD EPYC |
| `blacksmith-2vcpu-ubuntu-2404` | 4,357 | 15s | AMD EPYC, Hetzner |
| `warp-ubuntu-2404-x64-2x` (WarpBuild) | 3,754 | 11s | AMD Ryzen 9 7950X3D |
| `ubicloud-premium-2-ubuntu-2404` | 3,581 | 24s | AMD Ryzen 9 7950X3D |
| `ubuntu-24.04` (GitHub-hosted) | 2,268 | 6s | AMD EPYC 7763, Azure |

> Left out of the table, not out of the ranking. Avrea, on dedicated hardware, scores 4,423 at a 12-second queue, which is second of everything in the suite and above Blacksmith; StarSling on Oracle Cloud scores 3,347 at 12 seconds. Neither is priced elsewhere on this site. Both self-hosted entries run in your own AWS account and they bill differently: RunsOn charges a flat annual license with no meter and leaves the EC2 time on your AWS bill, while AWS 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-09-20). RunsOn's own families score 4,266 at 21 seconds and 3,808 at 22; CodeBuild sits at 2,137. Ubicloud's standard tier, the slower of its two, is 2,925. Depot and Latchkey are not in the suite at all, so nothing here ranks either of them on CPU. Every figure here is from the page's deep-dive table, the one that publishes percentiles and sample counts; its leaderboard disagrees on one row, giving WarpBuild 3,788 at a 12-second queue against the deep dive's 3,754 at 11.

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

> The Namespace hardware, plan concurrency and cache-volume figures on this page come from namespace.so/pricing and its GitHub Actions documentation, both read 2026-09-20, 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 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.

```.github/workflows/ci.yml
- 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.

```.github/workflows/bake-off.yml
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](/learn/failures/exit-code-137-in-github-actions) or [a cache service 503](/learn/failures/github-actions-cache-service-503-429), 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.

## 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, read 2026-09-20, Namespace leads x64 single-thread at 4,686, with Avrea at 4,423 and Blacksmith at 4,357, against GitHub-hosted at 2,268. 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 4,357 against 2,268 for GitHub-hosted. 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 run from 11 to 24 seconds against about 6 for GitHub-hosted, and a cold fleet at peak can be much worse than its median.

## References

- [RunsOn benchmarks: cross-provider Passmark single-thread and queue times, updated 2 September 2026 (verified 2026-09-20)](https://runs-on.com/benchmarks/github-actions-cpu-performance/)
- [RunsOn benchmarks: 4 GB cache save and restore across providers, updated 8 July 2026 (verified 2026-09-20)](https://runs-on.com/benchmarks/github-actions-cache-performance/)
- [Depot GitHub Actions runners: EPYC Genoa and Graviton4, cache throughput, per-second tracking (verified 2026-09-20)](https://depot.dev/docs/github-actions/overview)
- [Blacksmith runners: Firecracker boot times, colocated cache throughput and regions (verified 2026-09-20)](https://docs.blacksmith.sh/blacksmith-runners/overview)
- [GitHub Actions limits: concurrent jobs by plan and cache storage per repository (verified 2026-09-20)](https://docs.github.com/en/actions/reference/limits)

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt