Skip to content

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-2404
  • runnerhut-4vcpu-ubuntu-2404
  • runnerhut-8vcpu-ubuntu-2404
  • runnerhut-16vcpu-ubuntu-2404
  • runnerhut-32vcpu-ubuntu-2404
  • runnerhut-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

yaml
jobs:
build:
- runs-on: ubuntu-latest
+ runs-on: runnerhut-8vcpu-ubuntu-2404
steps:
- uses: actions/checkout@v4
- run: make test
Change the label. Nothing else in the workflow moves.

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

WorkloadStart withWhy
Node/TS unit tests4 vCPUJest and Vitest parallelise well but are I/O bound
Go build + test8 vCPUThe compiler scales nearly linearly
Rust release build16 vCPUcodegen units keep every core busy
Docker image build8 vCPUUsually cache- and network-bound, not CPU-bound
Monorepo full CI32 vCPUOnly 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.