Preinstalled Software on WarpBuild Runners

Every WarpBuild runner image carries the same preinstalled tooling as the GitHub-hosted runner image it is built from, so the software inventory for any warp- label is the published runner-images readme for that operating system. The documented additions are Tailscale on every image, with the daemon stopped until networking is configured, and Xcode 27.0 with its simulator runtimes on the macOS 26 labels.

This page maps each image family to the readme that lists its software, shows the workflow steps that prove a tool version exists before a job depends on it, and prices the two ways of closing a gap: installing the tool on every run, or baking it into an image. Labels, rates, and image notes were checked on 2026-08-13.

Catalog

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners. Each platform carries more than one image family, and the image selector inside the label is the part that decides the software inventory. The size multiplier changes hardware only, so a 2x and a 32x runner built from the same image ship an identical toolset.

Sources: the preinstalled software documentation and the cloud runner documentation, both checked on 2026-08-13.

What the readme settles and what it does not

A runner-images readme is written per image release. It answers "which Python, Node, Go, and Java versions are on this image today" precisely, and it answers "which versions will be there next month" only until the next rebuild. WarpBuild rebuilds images from the upstream releases and records every rebuild in the changelog, so the readme is the right place to look while writing a workflow and the wrong place to rely on at run time. The step that belongs in the workflow is a version assertion, covered under Configuration below.

Additions on top of the upstream image

Tailscale is preinstalled on all Linux, macOS, and Windows images. The daemon is not started by default and is activated on demand when networking is configured for the runner, so a job that never enables networking sees an installed binary and no running service.

The macOS 26 labels ship Xcode 27.0 (build 27A5194q) with the iOS 27.0 (24A5355p), tvOS 27.0 (24J5289o), watchOS 27.0 (24R5289n), and visionOS 27.0 (24M5291p) simulator runtimes. Xcode 27.0 is a WarpBuild addition on top of the upstream GitHub macOS 26 image while GitHub's upstream macOS 27 runner image is in beta, and a dedicated macOS 27 image follows once that image is released. Pin the bundle path in DEVELOPER_DIR and expect one edit when that switch lands.

The runner configuration also caches container images so pulls resolve faster than a first fetch on a cold image.

Differences worth knowing before you switch a label

• Runner storage is ephemeral and is deleted when the runner terminates. Anything a job installs is gone before the next job starts.
• Linux storage is 150GB of SSD on every size, Windows is 256GB, and macOS is 120GB on the 6 vCPU shape and 270GB on the 12 vCPU shape.
• Ubuntu 24.04 ARM64 images set the work dir to /runner/_work, which differs from GitHub's /home/runner/work/. Scripts that hardcode the GitHub path need a $GITHUB_WORKSPACE reference instead.
• macOS runners do not support nested virtualization and cannot run Docker, so container steps belong in a Linux job. On Linux x64, /dev/kvm access comes from the nested-virtualization.enabled=true label.
• WarpBuild caches are enabled by default on Linux runners and are not supported on Windows runners, where actions/cache covers the same ground.
• The ARM64 Ubuntu 22.04 images were deprecated on March 31, 2025, macOS 13 runners were removed on June 8, 2026, and Windows 2 vCPU runners were removed on the same date.

Pricing

The image does not change the rate. A per-minute price depends only on the machine shape, so Ubuntu 26.04 costs what Ubuntu 22.04 costs at the same size and macOS 26 costs what macOS 14 costs. Moving to a newer image to pick up newer tooling is a scheduling decision rather than a budget one.

Rates come from the pricing page and the cloud runner documentation, checked on 2026-08-13.

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. Signup includes $10 free credits, which is 2,500 minutes on the 2 vCPU Linux x64 shape at $0.004 per minute or 125 minutes on the 6 vCPU macOS shape at $0.08 per minute, which is enough to measure the install step described below on both platforms before any card is charged.

What a missing tool costs per run

When an image lacks something a job needs, the usual fix is a step that installs it on every run. That step is billed as runner time at the label rate, and because storage is ephemeral it repeats on every job. The table prices it on warp-ubuntu-latest-x64-8x at $0.016 per minute, at 880 runs a month, which is 40 runs a weekday across 22 weekdays.

The same six-minute step on warp-macos-26-arm64-6x at $0.08 per minute is $0.48 per run and $422.40 a month at that volume. Multiply by the shard count when a suite fans out, because each shard boots its own runner and repeats the install.

Two alternatives price out against those rows. Caching the installed toolchain costs $0.20 per GB-month of cache storage plus $0.0001 per cache write or restore, so a 2GB toolchain cache is $0.40 a month in storage and $0.088 for 880 restores. Capturing the state with snapshot runners costs $0.04 per snapshot restore and $0.025 per snapshot-hour of storage, so 880 restores plus one snapshot held for a 30-day month is $35.20 plus $18.00. Both land under the $84.48 that a six-minute install charges at the same volume, and both are listed in full on the pricing page.

Configuration

Three edits cover the common cases: record what the image has, fail the job when a required version is absent, and pin versions through setup actions rather than through the image default.

Record and assert the toolchain

name: verify-toolchain

on:
  pull_request:
  workflow_dispatch:

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-8x
    env:
      REQUIRED_NODE_MAJOR: "22"
    steps:
      - uses: actions/checkout@v4

      - name: Record the image toolchain
        run: |
          uname -m
          node --version
          python3 --version
          docker --version
          ls /opt/hostedtoolcache

      - name: Fail early when the Node major version is wrong
        run: |
          major="$(node -p 'process.versions.node.split(".")[0]')"
          if [ "$major" != "$REQUIRED_NODE_MAJOR" ]; then
            echo "::error::image ships Node $major, this workflow requires $REQUIRED_NODE_MAJOR"
            exit 1
          fi

      - uses: actions/setup-node@v4
        with:
          node-version-file: .nvmrc
          cache: npm

      - run: npm ci
      - run: npm test

The record step is worth keeping permanently. It writes the image inventory into the job log, so a build that passed last week and fails today becomes a diff between two logs and an image version from the changelog. The assert step turns silent version drift into a failed step at second five instead of a confusing compile error at minute nine. The setup-node step then pins the version from a committed .nvmrc, which is what stops the job from depending on whatever the image happens to carry.

The equivalent record steps on the other platforms:

      - name: Record the image toolchain on Windows
        shell: pwsh
        run: |
          $PSVersionTable.PSVersion
          dotnet --list-sdks
          & "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" -latest -property catalog_productDisplayVersion

      - name: Record the image toolchain on macOS
        run: |
          xcodebuild -version
          xcrun simctl list runtimes available
          ls /Applications | grep Xcode

When the image is missing something

Three routes close the gap, in ascending order of setup cost.

1. Install in the job. A setup action or the package manager, priced in the table above, with actions/cache keyed on a committed lock file so the download is paid once per dependency change rather than once per run.
2. Capture the installed state. Snapshot runners boot later jobs from a runner VM captured mid-workflow through the snapshot.enabled=true or snapshot.key=<alias> labels, on Linux x64 and Linux ARM64. Snapshots are deleted after 15 days, so the capture job runs on a schedule.
3. Build a custom VM image and run it on BYOC. The custom VM image requirements are specific: a systemd-based distro, curl, wget, bash, jq, and libicu present, and tar, gzip, coreutils, shadow-utils, and systemd left in place. Windows images need aria2 on the system PATH, and Windows AMIs on AWS must be sysprepped before capture. There is no additional cost for using custom VM images. Build custom runner images for GitHub Actions walks the full build and registration path.

Two tools change the calculation here. Remote Docker builders keep container toolchains off the runner image, so a job that only needs docker build does not need a bigger runner image. The Action Debugger opens an SSH session on a paused runner, which is the fastest way to answer "what is actually installed" for a failure that reproduces only in GitHub Actions.

Where to go next

• Linux x64 runners for GitHub Actions covers the Ubuntu image families, shapes, and rates.
• Windows runners for GitHub Actions covers the Windows Server and Visual Studio image split.
• macOS runners for GitHub Actions covers the macOS images and the Xcode versions on each.
• The preinstalled software documentation is the source of record for every readme link above.

FAQ

Is the software on WarpBuild runners the same as on GitHub-hosted runners?

Yes. Each WarpBuild image carries the same tooling as the GitHub-hosted image it is built from, and the preinstalled software documentation links the published runner-images readme for every image family. Two documented additions sit on top: Tailscale is present on all Linux, macOS, and Windows images with the daemon stopped until networking is configured, and the macOS 26 labels ship Xcode 27.0 with its simulator runtimes.

How do I check that a tool version exists before a job depends on it?

Add a step that prints the versions the job needs (node --version, dotnet --list-sdks, xcodebuild -version) and a second step that exits non-zero when the version is wrong. The print step keeps the inventory in the job log, so a break after an image rebuild becomes a diff between two logs rather than a guess.

What are my options when the image is missing a tool?

Install it in the job with a setup action or the package manager, capture the installed state with snapshot runners on Linux, or build a custom VM image and run it on BYOC. There is no additional cost for using custom VM images; the job-time install is billed as runner minutes at the label rate.