Do Snapshot Runners Replace the Cache?

No. A cache action and a snapshot runner solve different problems: a cache moves selected directories in and out of a clean machine over the network, while a snapshot runner boots the job from a disk image an earlier run left behind. Many GitHub Actions pipelines run both, with the snapshot carrying the toolchain and the cache carrying the dependencies derived from a lockfile.

Answer

The two mechanisms differ in what they address and in what they carry.

A cache action names paths. You give it a path list and a key, it uploads those paths at the end of a run and downloads them at the start of the next one, and everything outside the list stays as the base image left it. The WarpBuild caching documentation covers the action inputs, and GitHub's dependency caching reference covers how keys and restore-keys resolve.

A snapshot names a machine. You append snapshot.key=<alias> to the runs-on label, the job boots from the disk saved under that alias, and the apt packages, container images in the local Docker store, compiler state, and generated outputs a previous run left anywhere on that disk are present at step one. The snapshot runners documentation is the reference for the labels, the save action, and the 15-day snapshot lifetime.

That difference produces a workload split.

Platform scope narrows both mechanisms in that last row, though not by the same amount. Snapshot labels applied to a runner type that does not support them are silently ignored, so the job runs with no snapshot behavior and no error. The cache action's restriction is narrower: the WarpBuild caching documentation lists WarpBuild Windows runners as the one unsupported platform.

Detail

Restore time: archive transfer against machine boot

A cache restore is a network transfer followed by a decompress into the named paths. Its duration tracks the size of the archive, so a pull request that changes one file still pays the full restore for a multi-gigabyte dependency tree, and the save on the way out pays a compress and an upload.

A snapshot boot replaces the base image the machine starts from. Boot times for snapshot runners can be slower than the default runners and take 45 to 60 seconds, per the snapshot runners documentation. That figure does not move with the amount of state on the disk, which is the whole shape of the comparison: transfer cost grows with the payload, boot cost is flat. The more setup work a machine holds, the better the flat number looks.

The corollary matters for small payloads. A 200 MB package tree restores quickly and reconciles cleanly against a lockfile, and paying a machine boot to carry it is the wrong trade. Warm cache covers what keeps a cache resolving in the first place, and the persistent caches guide walks the full decision.

What each mechanism costs

Both mechanisms bill on top of the per-minute rate of the runner you selected. Rates below are from the pricing page, checked on 2026-08-13.

Put those on one repository month to see the scale. Assume 880 workflow runs in the month, an 8 GB cache entry held for the month, and one snapshot alias alive for the full 720 hours.

The snapshot fees are the larger line, so the question is whether the snapshot removes more runner minutes than it costs. Divide the $0.04 restore fee by the runner rate to see what it buys: 10 minutes on warp-ubuntu-latest-x64-2x at $0.004 per minute, 5 minutes on warp-ubuntu-latest-x64-4x at $0.008, 2.5 minutes on warp-ubuntu-latest-x64-8x at $0.016, and 1.25 minutes on warp-ubuntu-latest-x64-16x at $0.032. A snapshot that removes 20 minutes of apt and toolchain installation clears that bar on every size. A snapshot that removes 90 seconds clears it only on the larger sizes.

A workflow that runs both

The split below gives each mechanism the state it handles well. The snapshot carries system packages and the toolchain, refreshed on merges to the default branch. The cache carries node_modules, keyed on the lockfile hash so it tracks dependency changes per commit.

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

jobs:
  build:
    runs-on: >-
      ${{ github.ref == 'refs/heads/main'
        && 'warp-ubuntu-latest-x64-4x;snapshot.enabled=true'
        || 'warp-ubuntu-latest-x64-4x;snapshot.key=toolchain-main' }}
    steps:
      - uses: actions/checkout@v5

      - name: Install system toolchain
        run: |
          if [ -z "$WARPBUILD_SNAPSHOT_KEY" ]; then
            sudo apt-get update
            sudo apt-get install -y libvips-dev protobuf-compiler
          fi

      - name: Restore dependencies
        uses: WarpBuilds/cache@v1
        with:
          path: node_modules
          key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}
          restore-keys: ${{ runner.os }}-node-

      - name: Install dependencies
        run: npm ci

      - name: Build and test
        run: |
          npm run build
          npm test

      - name: Cleanup credentials
        if: github.ref == 'refs/heads/main'
        run: |
          rm -rf $HOME/.ssh $HOME/.aws
          git clean -ffdx

      - name: Save snapshot
        if: github.ref == 'refs/heads/main'
        uses: WarpBuilds/snapshot-save@v1
        with:
          alias: "toolchain-main"
          fail-on-error: false

Three details make the combination work.

The WARPBUILD_SNAPSHOT_KEY environment variable is set on a machine that booted from a snapshot, so the guard skips the apt step on restored runners and runs it on the clean default-branch build that produces the image.

The cleanup step removes credentials before the save, which the documentation recommends because a snapshot disk carries whatever files were on it. git clean -ffdx also removes gitignored paths such as node_modules, which suits this layout: those files belong to the cache, and leaving them out keeps the snapshot to the toolchain.

fail-on-error: false keeps a failed capture from failing the merge build. The next run boots from the previous image or from the base image, and the pipeline stays green.

Related Questions

Can a snapshot runner replace my cache action entirely?

Only when every piece of state you carry forward lives on the runner disk and changes at the same rate as the snapshot alias. Dependency trees that move with a lockfile on most pull requests belong in a cache action keyed on the lockfile hash, because a cache key changes per commit while a snapshot alias changes when the workflow that saves it runs. The persistent caches guide covers the boundary case by case.

Which restores faster, a cache entry or a snapshot?

A cache restore is a network transfer plus a decompress, so its duration scales with the size of the archive. A snapshot boot is documented at 45 to 60 seconds regardless of how much the disk holds, so the larger the prepared environment, the better the snapshot compares. The snapshot runners hub lists the Ubuntu labels that accept the feature.

What do a cache and a snapshot each cost on WarpBuild?

WarpBuild cache storage is $0.20 per GB-month and each cache write or restore is $0.0001. Snapshot restore is $0.04 per job and snapshot storage is $0.025 per snapshot-hour. Both sit on top of the per-minute rate of the runner you selected, from the pricing page, checked on 2026-08-13. Warm cache defines the term the first line item is billed against.