Fastest GitHub Actions Runners: CPU Speed

This guide compares Linux GitHub Actions runner CPU performance, queue times, and pricing across official GitHub runners, self-hosted solutions, and third-party providers. Real-world benchmarks show how each option performs to help select the optimal runner.

TL;DR

How to read: leaderboard and deep dive use the configured CPU/queue percentiles (p50/p50). Higher CPU is better, lower queue is better. Price is normalized $/min.

Providers included

Leaderboard

Last updated: Apr 28, 2026

Benchmarks use Linux runners only, the Passmark single-thread metric, and the last 30 days of data.

How to choose a GitHub Actions runner

• If you want the lowest price, compare $/min.
• If you want speed, look at the configured CPU percentile (currently p50 single‑thread).
• If you want the lowest queue, look at the configured queue percentile (currently p50). GitHub is usually best, followed by Warpbuild and Namespace.
• If you want predictability, favor providers with stable hardware (some Hetzner‑based fleets can vary CPUs).
• If you want control, pick self‑hosted (RunsOn, AWS CodeBuild) and keep data in your cloud account. RunsOn keeps runners inside your AWS VPC; see networking options.

Deep dive (full data)

Methodology & data sources

• Leaderboard and deep dive use the configured CPU/queue percentiles (currently p50/p50). CPU is Passmark single-thread; queue is time-to-start in seconds.
• Data window is the last 30 days before the last updated date.
• Pricing is normalized to $/min.
• Providers can vary hardware over time (especially Hetzner-based fleets).

Observations

Performance takeaways

• Namespace, Blacksmith, and RunsOn lead x64 single‑thread performance.
• Namespace leads arm64; RunsOn and Warpbuild follow. GitHub’s newer Cobalt CPUs are closer but not consistently available.
• GitHub uses older CPUs overall, especially on x64.

Reliability & Scaling

• GitHub queue times are very good for standard runners. Used to be minutes for larger ones, but GitHub has improved their queue system.
• AWS provides better scalability than Hetzner-based providers.
• Third-party SaaS providers may require manual requests for higher vCPU concurrency, sometimes with extra fees. Same for static egress IPs. Self-hosted runners like RunsOn and AWS CodeBuild are not affected by this.
• Variable CPU models on some providers (for example Ubicloud tiers) can impact reproducibility.

Security & infra notes

• GitHub Actions runners are managed by GitHub and run on Azure. Access to private resources often requires secrets or OIDC.
• RunsOn is fully self-hosted in your AWS account with a dedicated GitHub App; IAM policies and networking are fully under your control.
• AWS CodeBuild is managed by AWS, runs in your account, and uses a shared GitHub App for registration.
• Namespace, Blacksmith, Warpbuild, Ubicloud, and Depot are SaaS providers; some offer BYOC, but the control plane and runner registration are not fully under your control.

Gaps

• Detailed concurrency/scaling tests are still missing; they matter for high-volume CI/CD (thousands of jobs/day). RunsOn routinely handles more than 1M jobs every day.

Note: this analysis is valid as of February 2026. Things change quickly in this space, so make sure you do your own research as well.