Linux x64 Runners for GitHub Actions

WarpBuild runs Linux x64 runners for GitHub Actions in five sizes, 2, 4, 8, 16, and 32 vCPU, priced from $0.004 to $0.064 per minute. A job moves onto one by setting runs-on to a warp-ubuntu-latest-x64-<size> label, and three Ubuntu lines are live at every size: 24.04, 26.04, and 22.04.

Memory scales at 4GB per vCPU across the whole ladder, and storage stays at 150GB SSD from the smallest label to the largest. The x64 images carry the same tooling as GitHub-hosted runners, so a workflow usually changes one line and keeps every step it already had.

This page lists all 15 Linux x64 labels with their shapes and prices, puts each size against GitHub's published rate for the same shape, maps common workloads onto rows in the ladder, and shows the dynamic label modifiers that Linux x64 runners accept. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, so a repository that spans platforms uses one provider and a set of labels.

Catalog

Fifteen Linux x64 labels are live: five on Ubuntu 24.04, five on Ubuntu 26.04, and five on Ubuntu 22.04. The latest labels resolve to the Ubuntu 24.04 line.

The price for a given size is the same on all three Ubuntu lines, so choosing 22.04 over 24.04 for an old toolchain costs nothing extra. The full matrix, including the ARM64, macOS, and Windows lines, is in the cloud runners documentation.

Cloud spot labels were removed on June 8, 2026, so there is no spot row in this catalog. Teams that want spot capacity run BYOC, which runs on AWS, GCP, and Azure and bills the compute through their own cloud account. Terraform support exists for BYOC on AWS.

Image contents

The Linux x86-64 runner images have the same tooling installed as GitHub-hosted runners, which is why actions/setup-node, actions/setup-python, actions/setup-go, and the rest resolve against preinstalled versions instead of downloading a toolchain on every job. GitHub publishes the per-image inventories for Ubuntu 22.04, 24.04, and 26.04, and those lists are indexed from the preinstalled software documentation.

Two additions sit on top of the GitHub inventory. Container images are cached on the runner for faster access, and Tailscale is preinstalled on every image with the daemon left stopped until networking is configured for that runner.

Runner storage is ephemeral and is deleted when the runner terminates. Anything a later job needs goes to an artifact, a cache entry, a registry, or a snapshot before the job ends.

Sizing by workload shape

Memory and disk are fixed functions of the size you pick, so sizing is a decision about vCPU and wall clock. The table below maps common GitHub Actions workloads onto rows in the ladder.

Every row carries 150GB SSD, so disk pressure alone never forces a size bump. When a build fills the disk, the fix is usually pruning Docker layers or scoping the cache rather than moving up the ladder.

The rate doubles at every step of the ladder while the vCPU count doubles too, which makes the arithmetic simple: moving from warp-ubuntu-latest-x64-4x to warp-ubuntu-latest-x64-8x costs the same per job when the larger runner halves the wall clock, and costs less per job when it does better than half. Time one real job at two sizes before standardizing on a size across the repository. The runner size answer page walks through that measurement.

Pricing

Every Linux x64 size is priced below GitHub's published rate for the same vCPU and memory shape. The rates in the table were read from GitHub's Actions minute multipliers reference and checked on 2026-08-13.

The arithmetic behind the fourth column is the difference over the GitHub rate. At 8 vCPU that is (0.022 - 0.016) / 0.022 = 27 percent lower list price; at 32 vCPU it is (0.082 - 0.064) / 0.082 = 22 percent lower list price. The 2 vCPU row compares against GitHub's private-repository ubuntu-latest shape of 2 vCPU and 8GB, which is the shape paying teams run. GitHub gives public repositories a larger free shape, so the 2 vCPU row is not the right comparison for an open source repository.

Two GitHub billing details change the real bill beyond the per-minute number. A plan's included minutes stop applying once a job lands on one of GitHub's larger runners, and larger runner minutes are charged on public repositories as well. Both are documented on GitHub's Actions billing concepts page, checked on 2026-08-13.

Minutes matter as much as the rate. The complete rate card, including cache and snapshot line items, is on the pricing page.

Worked model: a monorepo test suite

A platform team runs 2,500 jobs a month at about 9 minutes each on an 8 vCPU runner, which is 22,500 runner minutes.

• warp-ubuntu-latest-x64-8x at $0.016 per minute: 22,500 x $0.016 = $360.00 per month
• GitHub-hosted 8-core Linux larger runner at $0.022 per minute: 22,500 x $0.022 = $495.00 per month (GitHub pricing, checked 2026-08-13)

The monthly difference is $135.00 on identical minutes, or $1,620.00 across a year, before any change in how long the jobs take. If the team then moves the same suite to warp-ubuntu-latest-x64-16x and the wall clock drops from 9 minutes to 4.5, the bill lands at 11,250 x $0.032 = $360.00, unchanged. Below 4.5 minutes the larger label is the cheaper one per job, and the pipeline returns results sooner. The larger runner cost guide works this crossover through several job mixes.

What the bill does and does not include

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. Signup includes $10 free credits, which covers 2,500 minutes on warp-ubuntu-latest-x64-2x or 625 minutes on warp-ubuntu-latest-x64-8x before a card is charged.

Run as many jobs as your workflows need. Generally available Linux and Windows runners do not have plan-level concurrency caps, so a merge queue that fans out to 200 jobs does not queue behind a seat or a runner group limit.

Configuration

Moving a job onto a Linux x64 runner is a runs-on change. Nothing else in the workflow file has to move.

name: test
on:
  push:
    branches: [main]
  pull_request:

jobs:
  unit-tests:
    runs-on: warp-ubuntu-latest-x64-8x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: npm
      - run: npm ci
      - run: npm run test -- --maxWorkers=8

How the latest labels behave

warp-ubuntu-latest-x64-<size> follows the Ubuntu 24.04 line, and warp-ubuntu-2404-x64-<size> is its explicit alias. The two labels schedule the same machine at the same rate, so a repository can use whichever reads better in review.

The latest pointer moves when the Ubuntu line behind it moves. Teams with reproducibility requirements pin the versioned label instead: warp-ubuntu-2604-x64-16x stays on Ubuntu 26.04 and warp-ubuntu-2204-x64-16x stays on Ubuntu 22.04 through image updates, which turns an OS upgrade into a pull request rather than a surprise on a Tuesday morning.

A practical pattern for a mixed repository is to pin the jobs with native dependencies and leave everything else on latest. That way a base image change can only break the jobs you already know are sensitive to it.

Dynamic label modifiers

Linux x64 runners accept modifiers appended to the label with a semicolon. Three are available on this platform.

jobs:
  android-tests:
    runs-on: warp-ubuntu-latest-x64-16x;nested-virtualization.enabled=true

  api-tests:
    runs-on: warp-ubuntu-latest-x64-8x;snapshot.key=api-deps

  deploy-smoke:
    runs-on: warp-ubuntu-latest-x64-4x;network.name=production-tailnet;snapshot.enabled=true

nested-virtualization.enabled=true provisions the job on hardware that exposes /dev/kvm, which Android emulator and QEMU workloads need. Android emulator jobs also need a permissions step before the emulator action, because the default device permissions keep the runner user from opening the device:

      - name: Enable KVM group perms
        run: |
          echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' \
            | sudo tee /etc/udev/rules.d/99-kvm4all.rules
          sudo udevadm control --reload-rules
          sudo udevadm trigger --name-match=kvm

snapshot.enabled=true boots the runner from the base image and lets the snapshot-save action capture the VM at a chosen point in the workflow. snapshot.key=<alias> boots from an existing snapshot for that alias when one exists and falls back to the base image when it does not. The usual shape is snapshot.enabled=true on main to refresh the snapshot and snapshot.key=<alias> on pull requests to boot from it. Details are on the snapshot runners page.

network.name=<config-name> attaches the runner to a network addon configuration, which is how a job reaches a private service over Tailscale. Modifiers combine on one label, as the deploy-smoke job above shows. A modifier that a runner type does not support is silently ignored, so a shared workflow can carry a modifier that only some jobs use.

Around the runners

Cache is enabled by default on Linux runners, so actions/cache and the caching built into the actions/setup-* family work with no extra configuration.

If the runners have to live in your own cloud account, BYOC runs on AWS, GCP, and Azure with the same label contract, and Terraform support exists for BYOC on AWS. A workflow that already points at warp-ubuntu-latest-x64-<size> keeps its shape when the capacity moves into your account.

Where to go next

• Native Linux ARM64 runners for GitHub Actions: the same five sizes on ARM64 silicon, priced from $0.003 to $0.048 per minute.
• Snapshot runners that boot from a captured VM state: how the snapshot.key label removes repeated toolchain installs.
• Model the cost of larger GitHub Actions runners: the wall-clock crossover between sizes, worked through several job mixes.
• How to choose a GitHub Actions runner size: a short decision procedure with the measurements to take first.
• WarpBuild pricing: the full per-minute rate card and the $10 signup credits.

FAQ

What Linux x64 runner sizes does WarpBuild offer?

Five sizes on each Ubuntu line. 2 vCPU with 8GB at $0.004 per minute, 4 vCPU with 16GB at $0.008, 8 vCPU with 32GB at $0.016, 16 vCPU with 64GB at $0.032, and 32 vCPU with 128GB at $0.064. Every size carries 150GB SSD.

What does warp-ubuntu-latest-x64-8x resolve to?

Ubuntu 24.04 with 8 vCPU and 32GB of memory. Its explicit alias is warp-ubuntu-2404-x64-8x, and the two labels schedule the same machine. Use warp-ubuntu-2604-x64-8x or warp-ubuntu-2204-x64-8x when you want the OS version pinned through image updates.

How much disk does a Linux x64 runner have, and does it persist?

Every Linux x64 label carries 150GB SSD, from the 2 vCPU size to the 32 vCPU size. Runner storage is ephemeral and is deleted when the runner terminates, so anything you need after the job ends goes to an artifact, a cache entry, a registry, or a snapshot.

How do I get /dev/kvm for Android emulator jobs?

Add nested-virtualization.enabled=true to the runs-on label on a Linux x64 runner, then add the KVM group permissions step before the emulator action. Nested virtualization is available on Linux x64 cloud runners and on BYOC instance types that support it.