Are Snapshot Runners Safe for Public Repositories?

Answer

Yes, provided nothing sensitive is on the snapshot disk when it is saved. The snapshot runners documentation sets out separate handling for public and private repositories, and the public repository rule is explicit: ensure that no sensitive information such as cloud credentials is stored in the snapshot, because others may access the snapshot using the alias in a pull request workflow run.

The isolation model is unchanged by snapshots. Each job still gets its own virtual machine that is created for that job and destroyed when the build ends, and the public repositories documentation states that workflows run inside isolated VMs and provide the same safety as GitHub-hosted runners, which is the property that container based self-hosted setups such as ARC have to build for themselves. What a snapshot changes is the starting disk. Instead of a clean base image, the job boots from the disk an earlier job left behind, so the question shifts from who can reach the machine to what an earlier job wrote on it.

The two documented behaviors sit side by side like this.

Sources for the first two rows and the last row: the snapshot runners documentation, checked on 2026-08-13. The public repository prerequisite comes from the public repositories documentation, and the secrets row from the GitHub secrets documentation.

Detail

The threat model in plain terms

An alias is a string in a workflow file, such as snapshot.key=web-app-main. Anyone who can read the repository can read that string, and on a public repository anyone can open a pull request whose job requests it. The exposure is therefore everything the saving job left on the disk: an AWS profile under $HOME/.aws, a registry token in .npmrc or .docker/config.json, an SSH key, a kubeconfig, a signing key, or a private dependency checked out into the workspace.

Two things are outside that exposure. Repository secrets are held by GitHub rather than by the runner, and GitHub does not pass them to a workflow triggered by a pull request from a fork. WarpBuild does not access or store build secrets either, a control the WarpBuild security documentation states directly, and separately WarpBuild is SOC 2 Type 2, with trust.warpbuild.com as the linked evidence. The gap a snapshot opens is the disk, and the disk is the part your workflow controls.

GitHub's own self-hosted runner guidance warns about untrusted code on machines that outlive a job. A snapshot brings back part of that shape by choice, for one named alias, with a save step you wrote.

The safe pattern: trusted branches save, fork pull requests run clean

Send fork pull requests to a plain runner label and keep snapshot restores for branches inside the repository. The label is an expression, so one job definition covers all three cases.

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

permissions:
  contents: read

jobs:
  build:
    runs-on: >-
      ${{ (github.event_name == 'pull_request' && github.event.pull_request.head.repo.fork)
        && 'warp-ubuntu-latest-x64-4x'
        || (github.ref == 'refs/heads/main'
          && 'warp-ubuntu-latest-x64-4x;snapshot.enabled=true'
          || 'warp-ubuntu-latest-x64-4x;snapshot.key=web-app-main') }}
    steps:
      - name: Checkout
        uses: actions/checkout@v5
        with:
          persist-credentials: false

      - name: Install dependencies
        run: npm ci

      - name: Test
        run: 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: "web-app-main"
          fail-on-error: false

A fork pull request gets warp-ubuntu-latest-x64-4x with no snapshot label at all, which is a clean base image. The default branch uses snapshot.enabled=true, which always boots from the base image, so the published disk is rebuilt from a known starting point on every merge. Branches pushed to the repository itself use snapshot.key and get the warm disk. persist-credentials: false keeps the checkout action from writing a token into .git/config, which is one fewer credential on any disk that later becomes an image.

Maintainers who want the warm path on fork pull requests as well should first make the snapshot boring, meaning it contains dependency trees and compiler caches and nothing that authenticates to anything, and second gate any job that needs a credential behind an environment with required reviewers so approval is a human decision. The open source projects guide covers the wider set of fork trade-offs.

Cleanup before every save

The documented cleanup is two commands, run in the step immediately before the save:

rm -rf $HOME/.ssh $HOME/.aws
git clean -ffdx

git clean -ffdx removes untracked files, including directories and files ignored by .gitignore, so it also removes build output you may have wanted in the image. On repositories where the build directory is gitignored, replace it with targeted deletions of the paths that hold credentials. Setting fail-on-error: false on the save action means a failed capture leaves the pipeline green while the security-relevant cleanup has already run.

Labels, rates, and what this costs to try

Snapshot labels apply to WarpBuild Cloud Ubuntu runners only, and labels on any other runner type are silently ignored. The Ubuntu part of that catalog is the part this page applies to. Snapshot runners sit alongside the rest of the product surface: remote Docker builders, CI observability, an MCP server, and the Action Debugger.

Rates from the pricing page, checked on 2026-08-13. Snapshot restore bills $0.04 per job and snapshot storage $0.025 per snapshot-hour on top of those rates, which is $18.00 for one alias kept alive through a 30-day month. The clean label a fork pull request lands on carries no snapshot line items at all.

Related Questions

Can a fork pull request read a snapshot on a public repository?

Treat it as yes. The snapshot runners documentation warns that on public repositories others may access the snapshot using the alias in a pull request workflow run, so everything on that disk should be considered readable by anyone who can open a pull request. Repository secrets are a separate matter, since GitHub does not pass them to a workflow triggered by a fork pull request, per the GitHub secrets documentation.

What should never be written into a snapshot?

Cloud credential files, registry tokens, signing keys, SSH keys, and any token a login step wrote to disk. Run the documented cleanup, rm -rf $HOME/.ssh $HOME/.aws followed by git clean -ffdx, in the step immediately before WarpBuilds/snapshot-save. The snapshot runners hub covers the save and restore patterns those commands sit inside.

Do private repositories need the same care?

Yes. WarpBuild provisions runners at the organization level, and GitHub may allocate a runner intended for snapshot jobs to a different job in the organization, which can expose snapshot contents to other members of the organization. The same cleanup step before the save covers both cases, and are managed GitHub Actions runners secure covers the isolation model the snapshot sits on top of.