Runners
Linux x64 GitHub Actions runners
Dedicated AMD and Intel vCPU runners from 2 to 64 cores, with NVMe scratch disks and a persistent cache on every job.
Specifications
- vCPU
- 2 – 64, dedicated
- Memory
- 4 GB per vCPU
- Scratch disk
- Local NVMe, 150 GB – 2 TB
- Images
- Ubuntu 22.04, 24.04
- Cold start
- ~3s
- Cache
- Unlimited, 1 GB/s restore
Runner labels
runnerhut-2vcpu-ubuntu-2404runnerhut-4vcpu-ubuntu-2404runnerhut-8vcpu-ubuntu-2404runnerhut-16vcpu-ubuntu-2404runnerhut-32vcpu-ubuntu-2404runnerhut-64vcpu-ubuntu-2404
Standard GitHub-hosted Linux runners give you 2 shared vCPUs and a 14 GB SSD. Shared is the operative word: your build competes with whatever else landed on that host, which is why the same job takes 4 minutes on one run and 9 on the next.
runnerhut Linux runners are dedicated. The vCPUs are yours for the duration of the job, the scratch disk is local NVMe rather than network-attached, and the cache is restored over a 1 GB/s link instead of the throttled path actions/cache uses.
Switching
jobs: build:- runs-on: ubuntu-latest+ runs-on: runnerhut-8vcpu-ubuntu-2404 steps: - uses: actions/checkout@v4 - run: make testChoosing a size
Bigger is not automatically faster. A test suite that never saturates 4 cores runs at the same wall-clock time on 16 and costs four times as much. Start one size up from your current runner, look at the CPU utilisation chart in the dashboard, and stop when the curve flattens.
| Workload | Start with | Why |
|---|---|---|
| Node/TS unit tests | 4 vCPU | Jest and Vitest parallelise well but are I/O bound |
| Go build + test | 8 vCPU | The compiler scales nearly linearly |
| Rust release build | 16 vCPU | codegen units keep every core busy |
| Docker image build | 8 vCPU | Usually cache- and network-bound, not CPU-bound |
| Monorepo full CI | 32 vCPU | Only if your task graph is genuinely parallel |
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.