Migrate from Depot to WarpBuild

Moving GitHub Actions jobs from Depot runners to WarpBuild runners is a runs-on label change plus a caching change. This page has the label mapping for Linux, Windows, and macOS, the cache features that do and do not have a WarpBuild equivalent, a compatibility table with the unsupported rows stated plainly, the parallel run plan, and the rollback steps.

Still evaluating? WarpBuild vs Depot has the dimension table, and Depot alternatives covers the wider field. Every Depot fact below links to the page that states it, checked on 2026-08-13.

Prerequisites

• GitHub organization owner permissions, to install the WarpBuild GitHub app from the WarpBuild dashboard. The app cannot be installed from the GitHub Marketplace directly; sign up first, then install from the dashboard. See the quick start.
• Nothing new on repository ownership. Depot's docs already require that "your repository must be owned by a GitHub organization (not a personal account)", per their GitHub Actions overview, so a repository running Depot runners today already satisfies any organization prerequisite.
• Public repositories need one org setting. WarpBuild registers runners into the organization's Default runner group, and GitHub disables self hosted runners in public repositories by default. Check Allow public repositories on that runner group. See public GitHub repos.
• A list of the labels you use today. Grep your workflows for runs-on: depot- and count the distinct values. That list is the whole scope of the mechanical part of this migration.

Signup includes $10 in free credits, which covers a parallel run on most repositories. Per minute rates by runner label are on the pricing page.

The runs-on Diff

Adoption in either direction is one line per job.

 jobs:
   build:
     name: Build
-    runs-on: depot-ubuntu-24.04-8
+    runs-on: warp-ubuntu-latest-x64-8x
     steps:
       - uses: actions/checkout@v4

runs-on is evaluated per job, so a single workflow file can send some jobs to the new labels and leave the rest where they are. That is what makes the parallel run below cheap.

Label Mapping

Depot publishes a six rung size ladder for every Linux and Windows family: 2 CPU with 8 GB, 4 with 16, 8 with 32, 16 with 64, 32 with 128, and 64 with 256, per their runner types page. WarpBuild publishes five rungs on Linux, from 2 vCPU with 8 GB up to 32 vCPU with 128 GB, in cloud runners. Map by vCPU and memory, and read the notes on the rows where the ladders differ.

Linux x64

Ubuntu 26.04 has no Depot label at time of writing and is available on WarpBuild as warp-ubuntu-2604-x64-2x through -32x.

Linux ARM64

WarpBuild deprecated its Ubuntu 22.04 ARM64 images on March 31, 2025, so a 22.04 ARM job moves to 24.04 or 26.04. Also note that the WarpBuild Ubuntu 24.04 ARM64 image sets the work directory to /runner/_work rather than GitHub's /home/runner/work/, which matters for any step with a hardcoded path.

Windows

Two traps on this platform. WarpBuild removed its 2 vCPU Windows runners on June 8, 2026, so the smallest Windows rung is 4 vCPU and a 2 CPU job sizes up. And warp-windows-latest-x64-* currently means Windows Server 2022, while depot-windows-latest means Windows Server 2025, so map by the explicit version label rather than by latest. Visual Studio 2026 is available on the transitional warp-windows-2025-vs2026-x64-* labels; the other Windows Server 2025 labels carry Visual Studio 2022.

macOS

All three Depot macOS labels share one hardware shape. WarpBuild publishes two sizes on macOS 15 and 26 and one on macOS 14, so a job that was memory bound at 24 GB has a larger rung available, and a job that was CPU bound at 8 CPUs should be tested on the 12 vCPU label rather than assumed equivalent.

Full Workflow Example

A Node build with caching and a macOS job, after the migration. The runs-on values and the two cache related action swaps are the whole diff.

name: ci

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-8x
    steps:
      - uses: actions/checkout@v4

      - uses: WarpBuilds/setup-node@v6
        with:
          node-version: 22
          cache: npm

      - run: npm ci
      - run: npm test

  build-ios:
    runs-on: warp-macos-26-arm64-12x
    steps:
      - uses: actions/checkout@v4

      - name: Restore derived data
        uses: WarpBuilds/cache@v1
        with:
          path: ~/Library/Developer/Xcode/DerivedData
          key: ${{ runner.os }}-derived-${{ hashFiles('**/Package.resolved') }}
          restore-keys: |
            ${{ runner.os }}-derived-

      - run: xcodebuild -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' test

Cache Migration

This is the part of the migration that is not a label change, so read it before you plan the cutover.

What happens to your Depot cache. Depot pre-configures their runners so that any action using the GitHub Actions cache API writes to Depot Cache instead of GitHub's, transparently, for actions/cache, actions/setup-node, actions/setup-python, actions/setup-java, and anything else on that API. Their cache integration docs state it plainly. That substitution is a property of running on their labels, so it ends the moment the label changes. Cache contents are not portable to another provider and no export path is documented on depot.dev, verified absent on 2026-08-13. Entries age out under the retention policy on their cache overview, and storage is billed as an hourly sampled monthly average, so a cache left in place during a parallel run keeps accruing.

What you configure on WarpBuild. WarpBuild Cache is a drop-in action swap rather than a transparent interception. Replace actions/cache@v4 with WarpBuilds/cache@v1, and replace actions/setup-* with the matching WarpBuilds/setup-* action, which uses WarpBuild Cache under the hood for toolchains and package manager dependencies. Caching is enabled by default on Linux runners. See caching and setup actions.

Expect cold caches for a run or two. This is reasoning rather than a vendor statement: because the two caches are separate stores keyed independently, the first job on a new label finds nothing and populates from scratch. Budget one or two slower runs per cache key, not a slower week.

Depot cache features and their WarpBuild equivalents

One behavioral difference deserves a second read. Depot states that cache entries from main and other branches share one namespace, so any job can read any entry. WarpBuild cache is scoped by key, version, and branch, following the GitHub Actions cache matching rules. If your restore-keys were written on the assumption that a feature branch inherits main caches without the standard fallback, expect lower hit rates on the first pull request builds and adjust the keys.

Compatibility Notes

Secrets and Permissions

Nothing moves. Secrets and variables for GitHub Actions runners live in GitHub on both platforms, so a runners to runners migration does not touch them. The permission changes are limited to two things: installing the WarpBuild GitHub app, which requires organization owner permissions, and the Allow public repositories setting on the Default runner group if any public repository uses the runners.

Cloud credentials obtained through OIDC are unaffected, because the trust relationship is between your cloud and GitHub's OIDC issuer rather than the runner vendor.

Parallel Run and Validation

runs-on is per job, so run both platforms at once on the same repository.

1. Pick two or three workflows that run often and block nobody, such as unit tests on pull requests.
2. Move one job in each to a warp- label and leave its siblings where they are.
3. Let a week of real traffic go through, then compare queue time and total duration in each vendor's own dashboard. WarpBuild queue timings and per job metrics are on the Reports page.
4. Watch the failure modes that are specific to a platform change: hardcoded runner paths, tools present in one image and absent in the other, and cache keys that assumed the old scoping.

Carry one caveat from Depot's own parallel run guidance, because it applies to any side by side validation: "Be mindful of workflows that write to external systems (deploys, artifact updates) since they will execute twice." Keep deploy jobs and anything that publishes artifacts on one platform at a time.

Billing During the Parallel Run

You pay both platforms during the overlap. Plan the window around the billing shapes.

On the Depot side, per their pricing page checked 2026-08-13: plans bill monthly on the 1st, and proration applies to mid month signup rather than to cancellation, so a cancelled plan runs to the end of its month. Included allowances are per month and do not roll over. Included minutes are consumed at the size multiplier published on their runner types page, so a parallel run on large runners burns the allowance faster than elapsed time suggests. Their docs state that included monthly minutes are not a hard cap, and self imposed usage caps are the control for that during a migration month. Storage is billed as an hourly sampled monthly average across cache and registry, so leaving cache in place during the overlap keeps accruing.

On the WarpBuild side, billing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, so the parallel run costs exactly the minutes it uses, against the $10 in signup credits first. Per minute rates by label are on the pricing page, and per job costs land in the Reports billing tab as they accrue.

The cheap sequence: start the parallel run early in a billing month, cap usage on the platform you are leaving, cut over before the next 1st, and cancel after the last job has moved.

Rollback

Reversibility is the reason to start with one job.

1. Revert the pull request that changed the runs-on values. Depot documents adoption as a one line change to the runner label on their GitHub Actions overview, so going back is the same one line change in the other direction.
2. Revert the cache action swap in the same pull request if you made it there, so actions/cache and actions/setup-* return and the transparent interception resumes on their labels.
3. Leave the old GitHub app installed and the old plan active until the parallel run ends. No teardown is needed to keep the option open; the cost of keeping it is the monthly plan charge.
4. Expect cold caches again on the way back, for the same reason they were cold on the way over.

Steps 1 and 2 are a single pull request, so a rollback is a same day operation as long as the app and the plan are still in place. Decommission only after you have run a full week without reaching for this section.

Expected Time to First Green Build

Signup, app installation, and the first label change fit in one working session on a repository whose workflows you already know. The realistic schedule for a full migration is one afternoon for the label mapping and the first green job, one week of parallel running for confidence, and one pull request to move the rest. Slack support channels are available on demand if a job behaves differently on the new labels.