One line in, twice the speed out
Cloud runners for GitHub Actions
Managed, dedicated runners that replace ubuntu-latest with a single label change. Faster hardware, unlimited cache, half the cost.
Dedicated vCPU
No shared cores, no noisy neighbours, no run-to-run variance you cannot explain.
Local NVMe
Direct-attached scratch disk instead of network storage. Checkout, install and test all get faster.
Instant start
Warm pools mean a job starts in about three seconds rather than waiting on a cold VM boot.
Every OS
Linux x64 and arm64, macOS on Apple silicon, Windows Server, and GPU tiers.
Cloud runners are the core product. You change the runs-on label, and every other line of your workflow stays exactly as it is — same actions, same secrets, same permissions model, same logs in the same place.
What actually makes it faster
- Dedicated CPU, so a build gets the whole core rather than a time slice
- Local NVMe, so file-heavy steps stop waiting on network storage
- A cache that restores at 1 GB/s with no size cap
- Warm pools, so queue time stops being part of your build time
- runs-on: ubuntu-latest+ runs-on: runnerhut-8vcpu-ubuntu-2404Common questions
- Do I have to change anything besides runs-on?
- No. The same actions, secrets, permissions model and logs all work unchanged. If a provider asks you to rewrite steps or swap out actions, migrating away from them later costs the same effort again.
- What happens if a runner is unavailable?
- Jobs queue rather than fail. Capacity is regional, so a shortage in one region does not silently spill into another — that is what makes region pinning enforceable.
- Can I mix runnerhut and GitHub-hosted runners?
- Yes. runs-on is per job, so different jobs in one workflow can use different providers. Moving one job first and comparing timings is the recommended migration path.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.