The Fastest GitHub Actions Runners in 2026: CPU Benchmarks Are Half the Story

TL;DR: On the only independent CPU benchmark of GitHub Actions runners (runs-on.com, updated monthly), the fastest x64 runners are Namespace (4,454), Avrea (4,441), and Blacksmith (4,406): all roughly 1.9x GitHub's standard runners, which score 2,193 to 2,323. On ARM64, Avrea's Apple M5 Max runners lead at 5,003, 2.7x GitHub's 1,874. Those scores predict cold builds. Warm builds are decided by cache speed, where the gap on real projects runs from 5x to more than 140x.

Avrea is our product, and it appears in this comparison. Read accordingly. Every cross-provider number below comes from a third-party benchmark or a provider's own published data, and all sources are linked.

What makes a GitHub Actions runner fast?

A CI minute goes to five places: queueing for a runner, booting the VM, installing dependencies, running the build and tests, and moving cache in and out.

CPU benchmarks rank one of those. Compile-and-test work is mostly single-threaded, so single-core scores predict it well. But dependency installs and cache transfers are storage and network problems, and queue time is a capacity problem. A runner can win the CPU chart and still lose your afternoon to a slow cache restore.

So this comparison has two halves: the CPU rankings, where independent data exists, and cache performance, which the ranking pages barely touch and which decides most warm builds.

Which GitHub Actions runners have the fastest CPUs?

The best public data is RunsOn's CPU benchmark: PassMark single-thread scores and queue times, measured continuously on 2 vCPU Linux runners across providers, updated monthly. RunsOn sells runners too, so there's a conflict of interest, but the methodology is published and the numbers track what providers report about themselves. As of the July 1, 2026 update:

x64 Linux (PassMark single-thread, median):

Namespace, Avrea, and Blacksmith sit within about 1% of each other. Thirteen points separate first place from second so differences are small. Run-to-run variance is bigger than the gap between them, so the real differences live elsewhere: cache design, observability, pricing structure.

GitHub wins queue time. Six to seven seconds at median is the best in the field. If your jobs finish in under a minute, queue and boot overhead matter more than clock speed, and GitHub-hosted is hard to beat.

RunsOn is the price outlier: about 96% of the leaders' speed at roughly a third of the per-minute cost, if you're willing to run the stack inside your own AWS account on spot instances.

ARM64 Linux:

ARM is where the differences show. Avrea and Namespace run their fast ARM Linux tiers on Apple Silicon, currently the strongest single-thread ARM parts you can buy; the chips measured in July's data are M5 Max (Avrea) and M4 (Namespace). Avrea's 5,003 is the only score above 5,000 and 2.7x GitHub's Cobalt-based runners. Providers on Ampere and Neoverse-N1 hardware land at 1,300 to 1,400, below GitHub's own ARM runners.

Apple Silicon ARM does cost more per minute: $0.012 against GitHub's $0.005. Whether 2.7x the speed is worth 2.4x the price comes down to how long your ARM builds are and how often they run.

Why do GitHub-hosted runners benchmark slow?

GitHub's standard fleet is shared, virtualized Azure capacity across mixed CPU generations: Intel Xeon Platinum 8370C and AMD EPYC 7763 (both 2021 server parts), with some newer EPYC 9V74 in the mix. Multi-tenant server silicon runs conservative clocks, which is why even the newest parts in that rotation score around 2,200 single-thread. RunsOn's summary line: "GitHub runs older CPUs overall, most visibly on x64."

The faster providers have all made the same bet: high-frequency parts chosen for single-thread speed. A 5.7 GHz EPYC 4585PX (Avrea), Ryzen 9 7950X3D (WarpBuild, Ubicloud), bare-metal EPYC (Blacksmith, Namespace), Apple M5 Max (Avrea's ARM and macOS fleets). Compilers, linkers, and test runners are mostly single-threaded, so clock speed lands directly on wall-clock time.

Disk is the other half of the hardware story. Depot measured GitHub runner disks at about 209 MB/s sequential, a platform cap rather than a physical limit, and our own kernel benchmark measured 222 MB/s. Dedicated runners with local NVMe read at multiple GB/s. When npm writes 80,000 small files or ccache reads compiled objects back, that gap compounds fast.

Credit where it's due: standard runners on public repositories are free and unlimited, at 4 vCPU, which stays the right default for low-volume open source. The January 2026 price cut (up to 39%) also made hosted runners cheaper than they were. The gap that didn't move is speed.

Why can cache speed matter even more than CPU?

Because most builds aren't cold. On a typical PR, most dependencies haven't changed, most Docker layers are identical to yesterday's, and most compiled objects could be reused. Whether your runner can exploit that determines more of your wall-clock time than its clock speed does.

Across every project we've benchmarked, faster hardware alone bought a consistent 2x to 3x on cold builds. Warm caches bought 5x to more than 140x.

Avrea's cache proxies run on the same hardware as the runner, so a 1 GB actions/cache restore that takes 14.10 seconds on GitHub takes 2.89 seconds on Avrea, 354 MB/s vs 73 MB/s, with a much tighter spread between runs. That layer alone is a 4.9x difference on a 1 GB restore, and the gap is similar at smaller sizes (3.9x at 100 MB, 6.6x at 10 MB).

The bigger wins come from the layer GitHub doesn't have at all. On an ephemeral GitHub runner, a golang, ccache, or Nix build recompiles from scratch every run, warm or not, because there's nowhere for the compiler cache to live. Avrea runs a framework-native build cache (Bazel, Turborepo, Go, ccache, sccache, Gradle, Maven, Nix, and Xcode on macOS) plus pull-through package proxies (npm, pip, Cargo, Go modules, Maven, NuGet) on the same machines. That's what produces the order-of-magnitude numbers below.

What do these gaps do to real build times?

We publish head-to-head benchmarks on public open-source projects: same vCPU and RAM on both sides, cold means cache disabled, warm means a populated cache, and warm speedups are measured against GitHub's cold time because GitHub has no equivalent cache for these tools. We have written in-depth comparisons on some of the runs in our blog.

The other published results fill in the middle of the range: Ghostty with Nix at 27.2x, ripgrep with sccache at 8.1x, Kafka with Gradle at 6.6x. Cold, cache-disabled runs across all of these land between 2x and 3x, which is what the CPU and disk numbers predict.

The React row is the control group. Yarn classic has no remote cache to hit, so the 2.1x is pure hardware, and it's the floor. How far above that floor you get depends entirely on how cacheable your workload is: compiler caches (ccache, sccache), content-addressed build systems (Bazel, Nix, Turborepo), and dependency stores all cache well.

Which GitHub Actions runner should you choose?

You can stay on GitHub-hosted if you're a public repo or a low-volume team. Free 4 vCPU runners for public repos, the best queue times in the field, and zero vendor overhead.

If you've outgrown GitHub-hosted, and you don't want the maintenance that comes with self-hosting there are multiple 3rd party options. Avrea, our own entry, shows up on both halves of this comparison: the fastest ARM64 runners measured (M5 Max, 5,003) and x64 within 0.3% of the top score on the hardware side, and the colocated three-layer cache behind the 39.7x to >140x warm numbers above. You also get per-step CPU and memory metrics and SSH into running jobs. macOS runs on the same M5 Max fleet with Xcode caching, at $0.08/min against GitHub's $0.102 M2 option.

Then there's the part that isn't about speed at all: the AI features. Failing Test Auto-Fix reads the logs, the diff, and the test's history, classifies what broke (regression, flake, environment drift, dependency mismatch), and writes the fix. Pipeline Optimization flags slow jobs, cache misses, and oversized runners, each with a proposed change. Dependency Upgrades tests every upgrade against your actual build instead of just bumping versions. As AI tools push more code through CI, a green check matters less than what the run hands back.

How do you benchmark runners on your own workload?

Skip the synthetic scores and test your actual build. Duplicate your slowest workflow file, point the copy at the new runner, and run both against each other.

Run the new one at least twice before judging: the first run shows the hardware difference, the second shows the cache. Compare warm against warm, and look at p95 rather than the median, since the slow runs are the ones your team remembers. Start with one repo; rollback is a one-line revert.

For the wider decision (hosted vs self-hosted vs third-party, security, migration mechanics), we wrote a separate guide to GitHub Actions runners.

On Avrea the test costs nothing: 3,000 free minutes per month, and the migration is one label:

runs-on: avrea-ubuntu-latest   # was: ubuntu-latest

Sign up at console.avrea.com and run your heaviest workflow twice.

Frequently asked questions

What is the fastest GitHub Actions runner in 2026? On independent CPU data (runs-on.com, July 2026): for x64 Linux, Namespace (4,454), Avrea (4,441), and Blacksmith (4,406) are within about 1% of each other, all roughly 1.9x GitHub's standard runners. For ARM64, Avrea's Apple M5 Max runners lead at 5,003. On warm real-world builds, runners with colocated caching beat GitHub's cold times by 5x to more than 140x, and cache design matters more than the CPU ranking.

How much faster are third-party runners than GitHub-hosted? About 2x on cold builds, from CPU and disk alone; that holds across published benchmarks (2x to 3x on real projects). ARM and MacOS can be more than 5x faster. With framework-level caching (ccache, Bazel, Turborepo, Nix), warm builds run 6.6x to more than 140x faster than GitHub cold, because GitHub's ephemeral runners have no persistent build cache at all.

Why are GitHub-hosted runners slow? Shared, virtualized 2021-era CPUs that score around 2,200 PassMark single-thread (the fastest third-party runners score 4,400 to 5,000); disk throughput capped around 210 MB/s vs multiple GB/s on local NVMe; and a cache that restores over the network at roughly 73-150 MB/s. GitHub does have the best queue times (6-7s) and free 4 vCPU runners for public repos.

Is the GitHub Actions cache slow? Measurably, yes. Independent tests put it at 100-150 MB/s (a 1 GB restore took 14.1 seconds in our testing), storage is 10 GB free per repository with 7-day eviction, and the API rate-limits at 200 uploads per minute, which Docker type=gha builds can exhaust. Providers with colocated caches restore the same 1 GB in 3-5 seconds.

Do faster GitHub Actions runners require workflow changes? No. Third-party runners are drop-in: you change the runs-on: label and keep your YAML, actions, secrets, and triggers. Existing actions/cache steps keep working and get served from the provider's faster cache. Self-hosting is the option that requires real setup.

What about macOS runners? The CPU benchmark excludes macOS, so compare hardware generations: GitHub offers M1 (standard, $0.062/min) and 5-core M2 (XL, $0.102/min), most third-party fleets run M4-class chips, Namespace lists M4 Pro and M5 Max, and Avrea runs 8-core M5 Max at $0.08/min with Xcode caching. If you build for Apple platforms, benchmark one real Xcode workflow; generation gaps show up directly in build times.

When is GitHub-hosted the right choice? Public repositories (4 vCPU runners, free and unlimited), teams with a handful of short builds a day, and anyone for whom queue time dominates job time. The switch is worth evaluating once engineers visibly wait on CI, or once AI coding tools push your PR volume past what your runners absorb.