Migrate From GitHub-Hosted Runners to WarpBuild

Moving a GitHub Actions workflow from GitHub-hosted runners to WarpBuild is a runs-on label change plus, on Linux, a one-line cache action swap. WarpBuild runners register as self-hosted runners against your GitHub organization, so actions from the marketplace, secrets, environments, and GITHUB_TOKEN behave the way GitHub documents them.

This page carries the label mapping, a full workflow example, cache behavior, the compatibility table including the rows where WarpBuild has no equivalent, billing differences during a parallel run, and the rollback steps. Every GitHub number is linked to the GitHub page it came from and was checked on 2026-08-13.

Still evaluating? WarpBuild vs GitHub-hosted runners has the price and feature comparison, and GitHub Actions larger runner alternatives covers the wider vendor set.

Prerequisites

• A GitHub organization. WarpBuild registers runners in the Default runner group (id 1) of an organization, per the public repository docs. Repositories under a personal account cannot receive the runners.
• A WarpBuild account. Sign up at app.warpbuild.com. Signup includes $10 free credits.
• The WarpBuild GitHub app, installed from the WarpBuild dashboard. The app cannot be installed from the GitHub marketplace; you sign up first and install from the dashboard, per the quick start. Grant it access to the repositories you plan to move, which can be a subset.
• Organization permission to edit runner group settings, if you have public repositories. GitHub disables self-hosted runners in public repositories by default. Enable Allow public repositories on the Default runner group before moving a public repository, per the public repository docs.
• Write access to the workflow files. The only file change is runs-on, plus the cache action on Linux jobs.

Nothing else in the repository changes. No cluster, no runner installation on your machines, and no changes to secrets.

Label Mapping

GitHub-hosted shapes below are the private-repository shapes from GitHub's hosted runners reference and the larger runners reference, checked on 2026-08-13. Public repositories get 4 vCPU and 16 GB on Linux and Windows instead. WarpBuild shapes come from the cloud runner catalog.

Larger sizes exist on every WarpBuild platform: Linux x64 and ARM64 at 2, 4, 8, 16, and 32 vCPU, Windows at 4, 8, 16, and 32 vCPU, macOS at 6 and 12 vCPU. Unlike GitHub's larger runners, no plan gate applies. WarpBuild's largest general runner is 32 vCPU and 128 GB; GitHub's larger runners reach 96 vCPU, per the larger runners reference. For container builds above that, use remote Docker builders, which reach 192 vCPU and 384 GB.

Sizing rule of thumb: start at the same or the next shape up. ubuntu-latest on a private repository is a 2 vCPU machine, so warp-ubuntu-latest-x64-2x is the like-for-like move and warp-ubuntu-latest-x64-4x is the move that also buys headroom.

The Workflow Diff

For most jobs the change is one line:

 jobs:
   build:
-    runs-on: ubuntu-latest
+    runs-on: warp-ubuntu-latest-x64-4x
     steps:
       - uses: actions/checkout@v4

On a matrix that spans operating systems it is three lines:

 jobs:
   test:
     strategy:
       matrix:
-        os: [ubuntu-latest, windows-latest, macos-latest]
+        os: [warp-ubuntu-latest-x64-4x, warp-windows-2025-x64-4x, warp-macos-26-arm64-6x]
     runs-on: ${{ matrix.os }}

A complete workflow after the change, with the WarpBuild cache on the Linux job and the stock GitHub cache left alone on the macOS job:

name: ci

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - uses: WarpBuilds/cache@v1
        with:
          path: ~/.npm
          key: npm-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
          restore-keys: |
            npm-${{ runner.os }}-
      - run: npm ci
      - run: npm test

  ios-build:
    runs-on: warp-macos-26-arm64-6x
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: ~/Library/Caches/org.swift.swiftpm
          key: spm-${{ hashFiles('**/Package.resolved') }}
      - run: xcodebuild -scheme App -destination 'generic/platform=iOS' build

Keep the workflow name, the triggers, the step list, and the actions exactly as they are. The runner label is the contract between GitHub and the machine; everything above and below it stays GitHub's.

Cache Migration

What happens to your existing caches. They stay where they are. GitHub Actions caches live in GitHub, keyed per repository, inside the included 10 GB per repository allowance GitHub publishes on the Actions billing page. Nothing deletes them, and a job that keeps actions/cache@v4 keeps reading and writing them from a WarpBuild runner.

What changes if you switch. WarpBuilds/cache@v1 is a drop-in replacement for actions/cache@v4 with the same inputs, outputs, keys, and restore-key semantics, per the cache documentation and the action repository. The WarpBuild cache is enabled by default on Linux runners and is a separate store from GitHub's, so entries do not carry across.

First-run behavior. The first job after the swap is a cache miss on every key, and it writes the entries it computes. Expect the first run in each cache-key family to look like a cold build, and the second run to look normal. Plan the swap on a day when a slower first build is acceptable.

What you must do. On Linux jobs, replace the uses: line and leave with: untouched. On Windows jobs, keep actions/cache@v4; WarpBuild caches are not supported on Windows runners. On macOS jobs, keep actions/cache@v4 as well.

Cache storage and cache operations are metered on WarpBuild and priced on the pricing page. On BYOC deployments the add-ons are included, because the storage sits in your own cloud account.

Run Both Platforms Side by Side

Move one non-critical workflow first, on a branch, so the job runs in a pull request before anything merges.

For a real side-by-side comparison, duplicate a single job and pin one copy to each platform for a week:

jobs:
  test-github:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./ci/test.sh

  test-warp:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: ./ci/test.sh

Compare pass and fail outcomes first, then wall-clock duration, then queue time. GitHub's own Actions performance metrics break job run time, queue time, and failure rate down by runner type, including self-hosted against GitHub-hosted, which makes it the neutral place to read the comparison. WarpBuild reports the same job data plus OpenTelemetry system metrics from the runner through CI observability.

Two things to watch during the parallel week. First, a duplicated job doubles the concurrency you consume on the GitHub side, and GitHub's standard-runner caps of 20, 40, 60, and 500 concurrent jobs by plan still apply to the GitHub half, per Actions limits. Second, you pay both platforms for the duplicated job, which is covered under billing below.

Compatibility Table

Unsupported rows are listed here rather than buried, because a surprise at migration time costs more than a row in a table.

Billing Differences

Both platforms bill per minute, and GitHub rounds each job up to the nearest whole minute, per the minute multipliers page. All GitHub rates below are quoted from that page with GitHub's own billing SKU strings, checked on 2026-08-13. WarpBuild rates come from the pricing page.

Source for every GitHub rate: docs.github.com actions-minute-multipliers, checked 2026-08-13.

Four billing facts change the arithmetic during a migration.

1. Included minutes stop applying to the moved jobs. GitHub's included allowance is 2,000 minutes a month on Free, 3,000 on Pro and Team, and 50,000 on Enterprise Cloud, per the Actions billing page. Minutes you no longer run on GitHub-hosted standard runners simply go unused; they do not transfer.
2. Larger runners never drew on those minutes anyway. GitHub states larger runners are always charged, even on public repositories. If you were already on larger runners, the whole spend is comparable line for line.
3. The parallel week costs both bills. A duplicated job runs twice, so budget for one extra week of the duplicated job's minutes on each side. Keep the duplicate scoped to one workflow.
4. The last macOS row goes GitHub's way. GitHub's 3 vCPU standard macOS runner at 0.062 per minute is cheaper per minute than the smallest WarpBuild macOS runner at 0.080, and it draws on included minutes. The WarpBuild macOS price advantage applies against GitHub's larger Apple Silicon shape, where 0.080 against 0.102 is 0.022 lower per minute, 22 percent lower list price.

WarpBuild add-ons are metered separately on the pricing page: cache storage, cache operations, snapshot restores, and snapshot storage. Networking add-ons such as Tailscale are $0. On BYOC, runner minutes are $0.002 and the add-ons are included, because the compute bill goes to your own cloud account. Signup includes $10 free credits.

Rollback

Reverting is the same edit in reverse, and it is a same-day operation.

 jobs:
   build:
-    runs-on: warp-ubuntu-latest-x64-4x
+    runs-on: ubuntu-latest

1. Change the runs-on label back to the GitHub-hosted label and merge.
2. If you swapped the cache action, change WarpBuilds/cache@v1 back to actions/cache@v4. Your GitHub cache entries are still there, subject to GitHub's own retention.
3. The next workflow run picks up the reverted label. In-flight jobs finish where they started.

Nothing else needs undoing. GitHub-hosted runners require no installation and no organization-level setup to return to, which is why the workflow diff is the entire migration in both directions. Leaving the WarpBuild GitHub app installed costs nothing, because WarpBuild pricing is purely usage based with no base subscription fee, no platform fee, and no seat fee.

Reversibility is the reason a one-week parallel run is enough validation for most teams: the downside of a bad result is one commit.