Migrate from Namespace to WarpBuild

Moving GitHub Actions workflows from Namespace to WarpBuild is a label change plus the removal of the Namespace specific actions a workflow picks up over time. Namespace documents its own adoption as changing the runs-on field to a Namespace profile or label (their GitHub Actions docs), and the move back out has the same shape.

This page covers the label map, the cache equivalents by name, a full workflow example, the compatibility table including what has no equivalent, how to run both providers at once, what happens to billing during the overlap, and how to roll back.

Still deciding? WarpBuild vs Namespace has the dimension by dimension comparison, and Namespace alternatives covers the wider provider set.

Prerequisites

Three things before the first job moves.

1. A WarpBuild account. Sign up at app.warpbuild.com, which includes $10 in free credits. Pricing is purely usage based with no base subscription fee, no platform fee and no seat fee (pricing).
2. The WarpBuild GitHub bot installed on the organization, with access to the repositories you plan to move (quick start). If you are not a GitHub organization owner, an owner approves the install. This mirrors the Namespace GitHub App install, which their migration docs describe the same way (their migration docs).
3. A list of the Namespace features your workflows actually use. Grep the repository for nscloud, namespace-profile, namespacelabs/ and NSC_ to get it. That list is the real switching surface, and the compatibility table below covers each item.

Secrets, OIDC and GITHUB_TOKEN permissions carry over unchanged, because the workflows keep running on GitHub Actions against the same repository. Expect the first green build on the first push after the label change, once the bot has repository access.

The Workflow Change

A single job moves in one line.

 jobs:
   build:
-    runs-on: nscloud-ubuntu-24.04-amd64-8x16-with-cache
+    runs-on: warp-ubuntu-latest-x64-8x

A job on a Namespace runner profile changes the same way.

 jobs:
   integration:
-    runs-on: namespace-profile-large-builder
+    runs-on: warp-ubuntu-latest-x64-16x

Label Map

Namespace machine labels take the form nscloud-{os}-{arch}-{shape} with optional -with-cache, -with-features and -with-builders suffixes, and only one nscloud label is allowed in a runs-on field (runner configuration). WarpBuild labels carry the size in the label itself (runner catalog).

Match the vCPU count first, then read the RAM column. At the same vCPU count, the WarpBuild Linux and Windows machines carry more memory than the Namespace standard shapes.

Namespace machine shape values are published in their runner configuration reference and machine shapes docs. WarpBuild labels, sizes and per minute rates are in the runner catalog.

The last macOS row needs a note. The warp-macos-26-arm64-6x and warp-macos-26-arm64-12x images carry Xcode 27.0 with the macOS 27 SDKs and the iOS 27.0, tvOS 27.0, watchOS 27.0 and visionOS 27.0 simulator runtimes (runner catalog), so a job pinned to a newer host image for the current Apple SDKs lands on macOS 26 here with the same toolchain. GitHub's upstream macOS 27 runner image is in beta, and a dedicated WarpBuild macOS 27 image follows once that image is released.

Label suffixes and companion labels map like this:

A Full Workflow

Before, on Namespace, using their checkout action, their cache action and a cached label:

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

jobs:
  test:
    runs-on: nscloud-ubuntu-24.04-amd64-8x16-with-cache
    steps:
      - uses: namespacelabs/nscloud-checkout-action@v8
      - uses: namespacelabs/nscloud-cache-action@v1 # keep whichever version your repository pins
        with:
          cache: pnpm
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: pnpm install --frozen-lockfile
      - run: pnpm test

After, on WarpBuild:

name: build
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: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm test

The cache enabled setup actions accept the same inputs as their upstream counterparts and store dependencies in WarpBuild cache, which is why the separate cache step disappears. Workflows that cache arbitrary paths keep an explicit step and use WarpBuilds/cache@v1, a drop-in replacement for actions/cache@v4:

      - uses: WarpBuilds/cache@v1
        with:
          path: |
            target
            ~/.cargo/registry
          key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
          restore-keys: |
            ${{ runner.os }}-cargo-

Cache Migration

Cache contents do not move between vendors. Namespace Cache Volumes are local NVMe volumes attached to their machines (cache volumes docs), and Namespace itself states that the volumes need workloads to run before they are filled and widely available (pricing FAQ). The same warm up applies on the way in to WarpBuild: the first run of each cache key is cold, and steady state runs are the ones worth comparing.

Namespace names eleven cache surfaces in their caching documentation. Here is each one and what WarpBuild has.

Two more surfaces sit next to the cache list. Namespace Remote Builders map to WarpBuild remote Docker builders, which run outside the GitHub Actions runner with a persistent layer cache and are selected with a builder profile name in Warpbuilds/build-push-action. The Namespace container registry has no WarpBuild equivalent, so images stored there move to your own registry before the last job leaves.

Compatibility Notes

Run Both Platforms Side by Side

runs-on is evaluated per job, so a repository can run both providers at once with no coordination. The useful shape of a trial:

1. Pick the workflow with the longest queue plus run time.
2. Move one job in it to a warp- label and leave every other job on its Namespace label.
3. Let it run for a week so the cache warms and the comparison covers steady state rather than first run timings.
4. Compare the same job across providers on the same branch, then decide.

Nothing in the Namespace documentation forbids running jobs on both platforms, verified on 2026-08-13. Their runner configuration reference does forbid more than one nscloud label in a single runs-on field, which matters only while a job still points at them (runner configuration).

Billing During the Parallel Run

Namespace bills a prepaid plan fee plus overage on a monthly cycle, and states that plan changes apply immediately with prepaid charges prorated (billing and limits). A team mid contract on a paid plan keeps paying that base fee for the rest of the period while the parallel run happens, so the overlap costs the Namespace plan fee plus the WarpBuild minutes.

WarpBuild has no base subscription fee, no platform fee and no seat fee, so the parallel run costs only the minutes the moved jobs consume, and the $10 in signup credits covers the first ones. Per minute rates by runner label are published on the pricing page, and Namespace publishes their own rates on their pricing page.

Rollback

Rollback is the same one line change in reverse, and it lands the same day.

 jobs:
   build:
-    runs-on: warp-ubuntu-latest-x64-8x
+    runs-on: nscloud-ubuntu-24.04-amd64-8x16-with-cache

Reverting the pull request restores the label and any Namespace specific actions in one operation. Two things to know before you revert:

• Namespace publishes no rollback guide. Verified absent on 2026-08-13 on their migration docs and GitHub Actions docs. The mechanical symmetry comes from the forward move being a runs-on change in the first place.
• Caches restart cold on the way back too, because Namespace cache volumes are theirs and WarpBuild cache entries are ours. Whichever direction you move, budget for one warm up cycle.

Keeping the Namespace account active during the trial period is what makes the revert a same day operation instead of a re-onboarding.

After the Move

Once the last job leaves Namespace, retire the Namespace GitHub App install and any workload identity federation configured for their runners, and move images out of their container registry.

From there, the WarpBuild surfaces worth adopting next are snapshot runners for workflows with expensive setup, remote Docker builders for container heavy pipelines, and BYOC if the runners should sit inside your own AWS, GCP or Azure account. Slack support channels are available on demand, and the compliance posture is SOC 2 Type 2 with evidence at trust.warpbuild.com.