Warp: six cores for parallel work

When cores are the bottleneck

Warp is the first size where CPU is the headline. It is for workloads that can actually use parallelism: compiling C, C++, Rust or Go; running a test suite across workers; transcoding; a queue consumer pool chewing through jobs; an app server with enough concurrent requests to keep six cores warm. If your graphs show four cores pinned on Turbo or Nitro, this is the next stop.

A CI runner that pays for itself

The most common Warp workload is a self-hosted runner. Hosted CI minutes are cheap until your pipeline is slow and frequent, and then they are neither cheap nor fast. A dedicated runner keeps dependency caches, Docker layers and compiler caches on local NVMe-backed disk between jobs, so the second build of the day skips most of the work the first one did.

Split six cores into job slots deliberately. For a GitLab runner using the Docker executor:

# /etc/gitlab-runner/config.toml (excerpt)
concurrent = 3

[[runners]]
  executor = "docker"
  [runners.docker]
    cpus = "2"
    memory = "4800m"
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]

Three slots of two cores and 4.8 GB each leaves about 1.5 GB for the host. GitHub Actions runners work the same way: install one runner service per slot and give each its own work directory. More detail, including cache layout and cleanup, on the CI runners page.

Telling builds to go wide

Many build systems default to a single job. Set parallelism explicitly so the cores you are paying for are used:

export MAKEFLAGS="-j$(nproc)"
export CARGO_BUILD_JOBS=$(nproc)
export GOFLAGS="-p=$(nproc)"
pytest -n auto
npx jest --maxWorkers=50%

Watch memory when you raise job counts. A C++ link step can take several gigabytes on its own; six of them at once can exhaust 16 GB. If that happens, reduce link parallelism separately, for example with -DCMAKE_JOB_POOLS=link=2 and CMAKE_JOB_POOL_LINK=link.

A forge with CI attached

Teams self-hosting Git with built-in actions often put the forge and one runner on a single Warp. The forge itself (Forgejo or Gitea) is light; the runner does the heavy lifting. With 160 GB of disk you have room for repositories, LFS objects and a few gigabytes of package registry. Read self-hosted Git for a layout that keeps repositories separate from runner scratch space, so a runaway job cannot fill the disk your source lives on.

Keeping 160 GB clean

Runners generate junk at an impressive rate. Schedule cleanup rather than relying on memory:

# /etc/systemd/system/runner-gc.timer
[Timer]
OnCalendar=daily
Persistent=true

# /etc/systemd/system/runner-gc.service
[Service]
Type=oneshot
ExecStart=/usr/bin/docker system prune -af --filter until=72h

Keep three days of images so recent pipelines stay warm, and let the rest go.

Image choice

For build machines, a newer userland often means newer compilers out of the box. Debian 13 Trixie and Ubuntu 24.04 both ship recent toolchains. If you build RPMs or need RHEL compatibility, AlmaLinux 9 is the sensible base.

Neighbouring sizes

• Cores mostly idle, memory comfortable: Nitro at $15 has the same RAM headroom for most services.
• Jobs are memory-starved or you run a large database alongside: Hyper doubles RAM to 32 GB and adds two cores.
• One runner is not enough: two Warps often beat one bigger machine, because a stuck job only blocks half your capacity.

Price

Warp costs $22 a month or $220 a year, in US dollars, which is the currency our checkout uses. There is no setup fee. Like every plan it has unmetered traffic on a 1 Gbps port and a dedicated IPv4.