Migrate from ARC to WarpBuild

Moving GitHub Actions jobs from Actions Runner Controller to WarpBuild is two pieces of work with very different sizes. The workflow change is one line per job. The cluster change is a decommissioning project you can take at your own pace, because ARC and WarpBuild runners coexist without conflict.

This page maps the gha-runner-scale-set configuration surface to WarpBuild runner configuration, shows the runs-on diff and a full workflow, covers caching, the parallel run, rollback, and the teardown order for the cluster deployment.

Prerequisites

• A WarpBuild account and the GitHub App installed. Sign up at app.warpbuild.com, then install the WarpBuild GitHub bot from the dashboard and grant access to the repositories you plan to move. The bot cannot be installed from the GitHub Marketplace directly (quick start).
• Organization owner access on GitHub, the same level ARC needed. WarpBuild registers its runners in your organization's Default runner group, id 1. If your workflows run in public repositories, check "Allow public repositories" on that group (public repos). If your organization uses a non-default runner group, confirm the group selected in WarpBuild has access to the repository (common issues).
• Your ARC values.yaml files. You need the scale-set values for the mapping table below, and the controller values if you customized flags or the image repository.
• A cloud account, only if you want BYOC. For runners inside your own AWS, GCP, or Azure account, connect the cloud account, create a stack that pins region, VPC, and object storage, and define a custom runner (BYOC docs). Skip this if WarpBuild-hosted runners are acceptable.
• GitHub Enterprise Server or GitHub Enterprise Cloud with data residency needs the enterprise app flow instead of the default install, which is available on the Enterprise plan (GHE setup).

TODO(verification): no published figure exists in the repo for expected time to first green build. Add one once a measured number is available.

Map Your Scale Set Configuration

Read the left column out of your values.yaml. Chart keys and their documented meanings come from the gha-runner-scale-set chart and the gha-runner-scale-set-controller chart at chart version 0.14.2, read on 2026-08-13.

Change the runs-on Label

An ARC workflow targets the scale set by its Helm installation name. The quickstart installs arc-runner-set, so workflows read:

jobs:
  build:
    runs-on: arc-runner-set

Multi-label targeting looks like this when runnerScaleSetLabels is set to [linux, gpu, private-network]:

jobs:
  build:
    runs-on: [linux, gpu, private-network]

Both forms are documented in use ARC in a workflow. The WarpBuild replacement is a single label:

 jobs:
   build:
-    runs-on: arc-runner-set
+    runs-on: warp-ubuntu-latest-x64-8x

For BYOC, the label is the Runner ID from the custom runners page, including the required prefix:

 jobs:
   build:
-    runs-on: [linux, private-network]
+    runs-on: warp-custom-ci-stack-runner

Size mapping is direct: an ARC PodSpec requesting 8 CPU and 32 GB maps to warp-ubuntu-latest-x64-8x (8 vCPU, 32 GB, 150 GB SSD). ARM64 jobs map to the warp-ubuntu-latest-arm64-* family, and the full label list with vCPU, memory, storage, and per-minute price is in the cloud runners docs.

Full workflow example

name: ci

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-8x
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Restore dependency cache
        uses: WarpBuilds/cache@v1
        with:
          path: ~/.npm
          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-npm-

      - run: npm ci
      - run: npm test
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/postgres

  build-arm:
    runs-on: warp-ubuntu-latest-arm64-8x
    steps:
      - uses: actions/checkout@v4
      - run: make build

The service container block is unchanged from the GitHub-hosted form. On ARC the same block requires containerMode set to dind or kubernetes, and Kubernetes mode has an open issue about service containers (issue 1768, open since 2022-09-01).

Cache Migration

What you have on ARC. ARC ships no dependency cache of its own. Dependency caching for ephemeral runners has been an open request since 2023-07-07, and image caching is on GitHub's out-of-scope list for ARC support. In practice ARC teams either use actions/cache against the GitHub Actions cache service and accept its quota and locality, or self-host a cache: an S3 or MinIO bucket behind a cache action, a registry mirror for base images, or a persistent volume the runner pods reuse in Kubernetes mode.

What replaces it. WarpBuild runners include a cache that is enabled by default on Linux runners. Swap the action and keep the same key and path arguments:

-      - uses: actions/cache@v4
+      - uses: WarpBuilds/cache@v1
         with:
           path: ~/.npm
           key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}

WarpBuilds/cache is a drop-in replacement for actions/cache@v4 and supports the split restore and save forms as well (caching docs). Container layer caching is available on hosted runners and on all three BYOC clouds, and remote Docker builders provide dedicated build VMs with a persistent layer cache for image-heavy pipelines.

What to expect on the first runs. Cache entries do not transfer between platforms. The first run of each workflow after the switch writes a fresh cache, so compare durations from the second run onward. If you self-hosted a cache for ARC, keep it reachable until the moved workflows stop referencing it, then remove it during decommissioning.

One action to leave alone. Snapshot runners capture a runner VM mid-workflow and boot later jobs from it, which is a different lever from dependency caching. Add snapshots after the migration is stable rather than during it (snapshot runners).

Run ARC and WarpBuild Side by Side

Both platforms register runners with the same GitHub Actions API, and jobs go wherever the runs-on label points. There is no conflict, no shared state, and no ordering requirement.

1. Start with one noisy workflow. Pick a workflow that runs often and fails visibly, so signal arrives in hours rather than weeks.
2. Move it on a branch, then merge. One runs-on change plus the cache action swap.
3. Compare the second run onward. Job duration, queue time, and failure rate. First runs write a cold cache, so exclude them.
4. Move in batches by runner size. Every job that requested the same PodSpec resources on ARC moves to the same WarpBuild label together.
5. Leave the ARC scale sets installed and idle. With minRunners at zero, an idle scale set consumes no runner pods while remaining ready for a rollback.
6. Track spend on both sides. Your cluster keeps its cost while it stays warm. WarpBuild bills per minute by runner type with no base subscription fee, no platform fee, and no seat fee, and signup includes $10 in free credits, which usually covers the validation batches. Rates are on the pricing page.

Secrets and permissions do not change. Repository and organization secrets, OIDC federation, and GITHUB_TOKEN permissions behave as they do on any self-hosted runner, because the runner still registers against your organization. What disappears is the Kubernetes secret that held your PAT or GitHub App private key.

Rollback

Rollback is a revert of the runs-on line, valid as long as the ARC deployment is still installed. That is the reason the decommissioning section comes last.

1. Revert the commit that changed runs-on, or change the label back by hand.
2. If you drained the scale set already, restore maxRunners and minRunners to their previous values and reapply the Helm release.
3. Leave the cache action swap in place or revert it; either works, since a cold cache is the only cost.

Keep the cluster warm for at least one full release cycle after the last workflow moves, including whatever periodic and scheduled workflows only run weekly or monthly. Those are the jobs that discover a gap after everything else looks green.

Decommission the ARC Deployment

Do this after the full workflow set has run green on WarpBuild, including scheduled workflows. The order below follows GitHub's documented teardown sequence, which is published as the upgrade procedure and applies equally to removal.

1. Drain the queue. Set maxRunners: 0 and minRunners: 0 on each scale set. GitHub documents this state: "If you set both properties to 0, Actions Runner Controller will not create new runner pods when new jobs are available and assigned." Confirm no jobs are still routing to the scale set before continuing.

2. Uninstall every scale-set release. helm uninstall each gha-runner-scale-set installation, one per scale set, and wait for resource cleanup. Watch for pods stuck in Terminating, which is a documented pattern in issue 3010 and issue 4155; the repository troubleshooting guide documents finalizer removal for the legacy equivalent.

3. Uninstall the controller. Remove the gha-runner-scale-set-controller release only after the scale sets are gone.

4. Remove the CRDs. Delete the CRDs in the actions.github.com API group, and, if legacy ARC was ever installed in this cluster, the actions.summerwind.net group as well. Helm does not remove CRDs for you.

5. Delete the leftovers the charts do not own. Each installation generates resources named after the installation with fixed suffixes, documented in the ARC components reference:

6. Revoke the GitHub credentials. Delete the GitHub App installation ARC used, or revoke the classic PAT. Enterprise-level ARC runners required a classic PAT, so check for one at the enterprise level as well (auth docs).

7. Remove the webhook, only if you ran legacy ARC. Webhook-driven scaling is a legacy-mode feature that installs a separate webhook server through githubWebhookServer.enabled=true, optionally exposed by a NodePort or an ingress (legacy autoscaling docs). Remove that server, its ingress, and the matching GitHub organization or repository webhook. The modern scale-set mode uses an outbound long-poll listener and registers no inbound webhook, so a modern deployment has nothing to remove here. cert-manager is likewise a legacy-mode dependency; the modern charts do not require it.

8. Reclaim the cluster. Delete the node groups or node pools that existed only for runner pods, the storage class and persistent volumes provisioned for Kubernetes mode, the private registry mirror of the controller and runner images, and the log and metric pipelines that only carried ARC telemetry. This step is where the cluster bill actually falls.

9. Clean the GitHub side. Remove empty runner groups that existed only for ARC scale sets, and delete offline self-hosted runner registrations left over from stuck pods.

Compatibility

Questions about a row in this table, or a cluster shape not covered here? Slack support channels are available on demand, and /compare/arc documents the dimension-by-dimension comparison behind these choices. If ARC and WarpBuild are not the only two options on your list, managed alternatives to ARC covers the wider field.