Migrate from WarpBuild, and what the snapshot was doing

By Daniel Zoghalchali·Latchkey

Migrate from WarpBuild and the label is the easy part: every size maps onto a size somewhere else at a comparable rate. What does not map is the part of WarpBuild that is not a runner, which is a metered cache and a snapshot restore priced per job, and those are the lines that decide whether the move saves money or just moves it.

WarpBuild sells two different products under one name, and which one you are on changes the whole migration. The managed runners are an ordinary metered fleet in its cloud. The bring-your-own-cloud mode is a control plane over machines in your own AWS, GCP or Azure account at a flat $0.002 a minute, and leaving that is a decision about your cloud account rather than about a rate.

Either way, three things come off the bill with their features attached: cache storage, cache operations and snapshots. Read those before the label map, because the label map is the trivial half.

The label encodes the vCPU count

WarpBuild labels read warp-<os>-<version>-<arch>-<N>x, where the suffix is the core count rather than a tier number. That is worth stating carefully, because it is an inference rather than a quotation: the rate card prices exactly one macOS shape, 6 vCPU with 14 GB, and the macOS label in the NativeScript/NativeScript workflows is warp-macos-15-arm64-6x, which only lines up if the suffix counts cores. The Linux side behaves the same way, with warp-ubuntu-2404-x64-4x in FuelLabs/fuel-core sitting against a published 4 vCPU with 16 GB row.

Once you read it that way the map is mechanical. Sizes double the same way everywhere and the memory ratio is the standard 4 GB per core, so a WarpBuild size lands on the same shape at every destination up to the point where the destination stops publishing sizes.

Three meters leave the bill, and so do their features

WarpBuild unbundles several things that most vendors either include or do not sell. Its published add-ons are cache storage at $0.20 per GB-month, cache write or restore at $0.0001 per operation, snapshot restore at $0.04 per job and snapshot storage at $0.025 per hour per snapshot. On a large pipeline those are not rounding errors: 20,000 jobs a month each restoring a snapshot is $800 in restores alone.

The useful consequence for a migration is that the saving is easy to compute and is often bigger than the rate difference. The uncomfortable consequence is that the features go with the meters. A destination that includes 25 GB of cache in the price is cheaper and also caps you at 25 GB, where WarpBuild would have sold you 200 GB for $40 a month. Work out which of those is your situation before treating the unbundling as a cost.

Snapshots are the thing with no equivalent

A snapshot restore is a machine that starts with your dependencies already installed, which is a different mechanism from a cache that is downloaded and unpacked after boot. Nothing in the fully managed market sells that as a line item, so if your pipeline leans on it, the honest migration is to rebuild what it was doing rather than to look for a feature that matches.

There are two ordinary replacements and they cover most of what snapshots were used for. A container image with the toolchain and dependencies baked in, referenced from container: on the job, moves the install into an image build that happens once rather than per job. A well-keyed dependency cache covers the rest. Both are slower than a snapshot and neither is metered per job, which is the trade you are making.

jobs:
  test:
    # before
    # runs-on: warp-ubuntu-2404-x64-4x
    # after
    runs-on: latchkey-medium
    container: ghcr.io/acme/ci-base:2026-09   # what the snapshot was doing
    steps:
      - uses: actions/checkout@v5
      - uses: actions/cache@v4
        with:
          path: ~/.cache/pip
          key: pip-${{ hashFiles('**/requirements.txt') }}
          restore-keys: pip-
      - run: pytest -q

Bring-your-own-cloud is a different exit

If your runners are in BYOC mode, the machines are already in your own AWS, GCP or Azure account at a flat $0.002 a minute, and moving to a fully managed vendor takes them out of it. That is a network and compliance decision before it is a price one, and at $0.002 the price argument is thin: only Ubicloud publishes a lower Linux rate.

The like-for-like alternatives in that case are the other vendors that keep compute in your account: RunsOn on a licence from EUR 300 a year with EC2 billed directly by AWS, or Actuated at a flat $150 a month for the first server on hardware you supply. RunsOn alternatives works that camp through in detail. If leaving your own cloud is acceptable, then the managed comparison applies and the rate table above is the whole story.

The pre-flight checklist

Six items, ordered so the two that could stop the migration come first.

• Non-Linux jobs. Grep for warp-windows- and warp-macos-. Neither moves to a Linux-only destination at any price, so decide where they go before anything else.
• BYOC. Establish whether your runners start in your own cloud account. If they do, and that was deliberate, the shortlist is a different one.
• Snapshots. Grep the workflows and the WarpBuild configuration for snapshot usage. Each one becomes a container image or a cache, and that is work rather than a label change.
• Cache size. Read the current cache storage in gigabytes off the bill. Anything above the destination allowance, typically 10 GB on GitHub-hosted or 25 GB on Latchkey, has to stop being cached deliberately.
• Labels. Grep for runs-on:.*warp- and record the core-count suffix for each job. That is the shape to match, and it is the only thing the label tells you.
• Sizes above 16 vCPU. A -32x job has no equivalent at several destinations. Check before you assume the whole matrix moves.

When to stay

Three cases. The compute has to stay in your own cloud account, where the BYOC rate of $0.002 a minute is already better than most metered alternatives and the boundary is the point. You need Windows, macOS or arm64 and want them from one vendor rather than three, which WarpBuild does and most cheap destinations do not. Or snapshots are genuinely load-bearing, and the per-job restore fee is cheaper than the wall clock you would spend reinstalling.

What leaving buys, if none of those holds, is a simpler bill and a lower Linux rate. At the 2 vCPU with 8 GB shape that is $0.0025 against $0.004, a 38% cut, plus whatever the cache and snapshot meters were adding. What it costs is the unbundled features, the platform range, and the sizes above 16 vCPU.

Why nothing here was measured

No runner job backs this page. The claim most worth measuring, what a snapshot restore saves against a container image plus a warm cache, depends entirely on the size of the dependency tree being restored, so a number from our fixture would be a number about our fixture. We would rather name the mechanism than publish a figure that flatters one side.

The label naming rule is the one inference on this page and it is marked as one: it is derived from two public workflow files read against the published rate card, not quoted from a vendor page. If WarpBuild publishes a naming reference that contradicts it, that reference wins over this reading.

Frequently asked questions

Related guides

References

• WarpBuild pricing: managed size rates, the flat BYOC rate, cache and snapshot meters (verified 2026-09-21)
• FuelLabs/fuel-core workflow using a WarpBuild Linux label (verified 2026-09-21)
• GitHub Docs: dependency caching reference, size limit and branch scope (verified 2026-09-21)
• Blacksmith pricing: the arm64 and macOS rates used as destinations above (verified 2026-09-21)
• GitHub Actions documentation