Migrate from Blacksmith to WarpBuild

Moving GitHub Actions workflows from Blacksmith to WarpBuild is a runs-on label change plus a replacement for any useblacksmith/* action steps in the file. Nothing else in the workflow changes: the same steps run, the same secrets resolve, and the same GitHub events trigger the jobs.

This page carries the label map, a full workflow example, what happens to caches, a compatibility table with the unsupported rows stated plainly, guidance for running both platforms side by side, and the rollback steps. Every Blacksmith fact links to the page that states it, checked on 2026-08-13.

Still weighing the decision? WarpBuild vs Blacksmith covers the two platforms dimension by dimension, and Blacksmith alternatives covers the wider option set.

Prerequisites

• A GitHub organization. WarpBuild registers runners in the Default runner group (id 1) of your GitHub organization, per the public repos doc. Blacksmith carries the same constraint from the other side: their docs state that Blacksmith is limited to GitHub organizations and is not available for personal repositories.
• Organization owner access, to install the WarpBuild GitHub app and, for public repositories, to check Allow public repositories on runner group 1.
• A WarpBuild account. Sign up at app.warpbuild.com, then install the GitHub app from the WarpBuild dashboard. The app cannot be installed from the GitHub marketplace directly, per the quick start.
• An inventory of vendor-specific steps. Search your workflows for useblacksmith/ and for blacksmith- labels before you start. The count of the first tells you how much work this is; the count of the second tells you how many lines change.
• Your GitHub organization IP allowlist, if you use one. Their network allowlisting doc publishes the control-plane addresses their platform needs. Leave those entries in place until the parallel run ends.
• Any third-party allowlists pointing at a Blacksmith static IP, if you bought that add-on, need re-pointing before the last workflow moves.

Secrets and permissions need no migration. Workflow secrets stay in GitHub. The only new secret is WARPBUILD_API_KEY, and only if you drive WarpBuild Docker builders from runners that are not WarpBuild runners.

The Label Change

The most common Blacksmith label is blacksmith-2vcpu-ubuntu-2404, which is what their quickstart maps ubuntu-latest to and what their Migration Wizard produces by default. The diff for that job is two lines:

 jobs:
   test:
-    runs-on: blacksmith-2vcpu-ubuntu-2404
+    runs-on: warp-ubuntu-latest-x64-2x
     steps:
       - uses: actions/checkout@v4

The full label map, from their published runner list to the WarpBuild runner catalog. <n> is one of 2, 4, 8, 16, 32 unless a note says otherwise.

Sizes are matched on vCPU count. Check RAM and disk against the runner catalog for memory-bound jobs before you assume a like-for-like swap.

A Full Workflow Example

Before, on Blacksmith, with their Docker builder, their checkout action, and the transparent dependency cache their docs describe:

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

jobs:
  build:
    runs-on: blacksmith-4vcpu-ubuntu-2404
    steps:
      - uses: useblacksmith/checkout@v1

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

      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ hashFiles('**/package-lock.json') }}
          restore-keys: npm-

      - run: npm ci
      - run: npm test

      - uses: useblacksmith/setup-docker-builder@v2
        with:
          cache-key: web-app

      - uses: useblacksmith/build-push-action@v2
        with:
          context: .
          push: true
          tags: ghcr.io/acme/web:${{ github.sha }}

After, on WarpBuild:

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

jobs:
  build:
    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-${{ hashFiles('**/package-lock.json') }}
          restore-keys: npm-

      - run: npm ci
      - run: npm test

      - uses: Warpbuilds/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/acme/web:${{ github.sha }}
          profile-name: web-app-builder

Four changes: the label, the checkout action back to upstream, the cache action to the WarpBuild drop-in, and one Docker step instead of two. The profile-name value is a builder profile you create once on the Docker builders page.

Cache Migration

Blacksmith's caching surface is broad, and the migration work is proportional to how much of it a repository uses. Their features, what their docs say happens, and the WarpBuild path:

What to expect on the first run. Every cache key starts cold on the new platform. Blacksmith's own Docker docs set the same expectation in the other direction, stating that the first Docker run after a cache-backend change is an uncached run. Judge the migration on runs three and later, once dependency caches, layer caches, and any snapshots have hydrated. A pilot that gets measured on run one measures cache warming rather than the platform.

Compatibility Table

Run Both Platforms Side by Side

A parallel run is the honest test, and both platforms support it because the routing decision lives in the workflow file.

1. Pick a narrow, representative subset. One busy repository, or one job inside a matrix, gives a clean read. Leave everything else on its current labels.
2. Keep the Blacksmith GitHub app installed on every repository that still carries a blacksmith-* label. Their quickstart documents the failure mode: org-level runner registration can hand their runners jobs from repositories they never provisioned for, which causes queuing. This is the one parallel-run gotcha that bites teams.
3. Wait out the cold runs. Give each side at least three runs after the caches warm before you compare anything.
4. Compare the same numbers on both sides. WarpBuild Reports publishes per-job duration, queue time by runner label, and cost per repository, with CSV export. Their GitHub Actions analytics dashboard publishes p99 job duration and cost by repository. Export both and compare the same workflows over the same week.
5. Watch queue time separately from run time. A platform that runs a job quickly and queues it for minutes has not made your pipeline faster.

Billing During a Parallel Run

Running two platforms means paying two platforms for the overlap. Four things to plan for.

Per-minute charges accrue on both sides. Check current rates on the WarpBuild pricing page and on their pricing page. This page restates no vendor's rates as numbers, because both change.

Their free minute allowance keeps working while you test. Blacksmith publishes 3,000 free minutes per month per organization, denominated in x64 2vCPU minutes with published conversion ratios for other families, and those minutes reset monthly. Whatever stays on their labels draws from that pool first.

WarpBuild pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. Signup includes $10 free credits, which covers a meaningful slice of a pilot before any invoice appears.

Storage-shaped meters keep billing until the data goes away. Their sticky disks and Docker layer cache are priced per GB per month on their pricing page, and both auto-evict after a period of inactivity (7 days for sticky disks, 8 days for the layer cache). Deleting the workflow steps stops new writes; existing volumes age out on their own schedule.

One question for your own account: pay-as-you-go carries no published base subscription or seat fee, and committed-spend and annual contracts do exist on their side, since those are the qualifier for their Premium Support plan. Check whether your account has a term commitment before you plan a full cutover.

Rollback

Reverting is the same one-line change in the other direction, and it can be done the same day.

1. Change runs-on back to the blacksmith-* label on the affected jobs.
2. Restore any useblacksmith/* steps you removed: the Docker builder pair, sticky disks, and the checkout action.
3. Confirm the Blacksmith GitHub app is still installed on those repositories. Leaving it installed for the whole parallel-run period is why this stays a one-line revert.
4. Expect one cold run per cache key on the way back, with one exception: their sticky disks evict after 7 days of inactivity and their Docker layer cache after 8 days, so a rollback inside a week may still find warm state.

There is no data to export, no account to close, and no configuration living outside the workflow file. Reversibility is the reason to run a pilot rather than a big-bang cutover.