What Happens to Runner Disks After a Job?

Answer

The disk is destroyed with the job. Each WarpBuild runner has its own encrypted storage volume that is created on demand and destroyed after each build, and the virtual machine that carried it is destroyed on the same schedule and never handed to a second job, both stated in the runner security documentation.

That answers the security question and the debugging question at once. Nothing you write to the disk survives the job, so a credential file left behind by a login step goes away with the volume, and so does the build output you forgot to upload. One feature departs from that rule on purpose, and it is the only one: snapshot runners save the disk as an image under an alias you name.

Disk size varies by label, and every size in the catalog follows the same lifetime.

Sizes from the runner catalog, checked on 2026-08-13. The per-job volume applies across all four platforms.

Detail

The two documented statements behind the answer

The security documentation records the disk lifetime in two separate paragraphs, and a reviewer will want both.

Compute isolation: each runner runs in its own virtual machine, the machines are created on demand and destroyed after each build, and they are ephemeral and never reused. Storage protection: each runner has its own encrypted storage volume, created on demand and destroyed after each build, and when caching is enabled the cache is encrypted and stored in a location only your runner can reach.

Put together, there is no host that ran your build this morning and someone else's build this afternoon, and no warm pool holding a working tree from an earlier run. That property is what container based self-hosted setups such as ARC have to configure and then keep configured, and GitHub's own self-hosted runner guidance warns about untrusted code on machines that outlive a job. The attestation behind the platform is SOC 2 Type 2, requested through trust.warpbuild.com. The security review checklist puts these statements in the order reviewers ask for them.

What it means for secrets written to disk during a job

Secrets reach the runner as environment variables, and steps then write them to files. A docker login step writes .docker/config.json. A cloud credential action writes a profile under $HOME/.aws. A cluster login writes a kubeconfig. actions/checkout writes a token into .git/config unless you pass persist-credentials: false.

Every one of those files lives exactly as long as the volume does. WarpBuild does not access or store build secrets; they stay in your source code repository and reach only the runner environment for the duration of the job.

The residual risk is a later step that copies a credential off the disk before the disk goes away. Three paths do that, and each is under your control:

• A cache step writes whatever path names into cache storage, which outlives the job by design. Name package manager download directories, and keep home directory dotfiles out of the list.
• An artifact upload sends named files to GitHub, where they follow your repository retention setting.
• A snapshot save writes the entire disk into an image, covered next.

Do GitHub Actions runners store my source code walks each persisted surface with its retention number, and ephemeral storage defines the underlying term.

The snapshot exception, stated precisely

A snapshot is a saved image of the runner disk at the instant the WarpBuilds/snapshot-save action ran. The snapshot runners documentation sets out four facts worth reading as one unit:

• What it captures. The disk as it stood at the save, including the working tree, dependency trees, compiler caches, and any credential file still present. The /tmp directory is the documented exception, since it is cleaned on reboot.
• How long it lives. Snapshots are temporary and deleted after 15 days, rather than at the end of the job.
• How access is scoped. The alias is a plain string in a runs-on label, so the scope is whoever can get that string into a workflow run. On public repositories the documentation warns that others may access the snapshot using the alias in a pull request workflow run. On private repositories, runners are provisioned at the organization level and GitHub may allocate a runner intended for snapshot jobs to a different job within the organization.
• Where it applies. Snapshot labels work on WarpBuild Cloud Ubuntu runners, and are silently ignored on BYOC, Windows, and macOS runners.

The mitigation is a cleanup step immediately before the save, which is the one place the disk lifetime is your responsibility instead of the platform's.

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

permissions:
  contents: read

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-4x;snapshot.enabled=true
    steps:
      - uses: actions/checkout@v5
        with:
          persist-credentials: false

      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Show what the image is about to hold
        run: |
          df -h /
          du -sh node_modules ~/.npm 2>/dev/null || true

      - name: Remove credentials from the disk
        run: |
          rm -rf $HOME/.ssh $HOME/.aws
          git clean -ffdx

      - name: Save snapshot
        uses: WarpBuilds/snapshot-save@v1
        with:
          alias: "web-app-main"
          fail-on-error: false

snapshot.enabled=true boots from the base image every time, so the published disk is rebuilt from a known starting point on each merge rather than accumulating whatever earlier runs left behind. df -h and du -sh before the cleanup give you a record in the job log of how large the image is going to be, which is the number the storage charge follows. Snapshot runners covers the restore side and the label syntax.

What a preserved disk costs

Snapshot storage bills at $0.025 per snapshot-hour and each restore at $0.04 per job, from the pricing page, checked on 2026-08-13. Because storage bills by the hour an alias exists, the monthly line depends on how many aliases you keep alive rather than how many jobs run.

The restore column is flat because it bills per job, so the alias count is the lever on both the cost line and the retention line. Runners with no snapshot label carry neither charge, and their disks end at the job with nothing to bill and nothing to retain.

Related Questions

Is the runner disk wiped or destroyed at the end of a job?

Destroyed. Each runner has its own encrypted storage volume that is created on demand and destroyed after each build, and the virtual machine holding it is destroyed on the same schedule and never handed to a second job, per the runner security documentation. There is no wipe step to trust, because the volume itself goes away. The security review checklist records the same statement in questionnaire form.

What happens to a secret a step wrote to the runner disk?

It goes with the volume. A registry token in .docker/config.json, an AWS profile under $HOME/.aws, or a kubeconfig written mid-job lives as long as the volume does, and WarpBuild does not access or store build secrets. The exception is a later step that copies the file somewhere else, such as a cache entry, an uploaded artifact, or a snapshot image, which is what do GitHub Actions runners store my source code covers surface by surface.

What does a snapshot preserve, and who can boot from it?

A snapshot preserves the whole runner disk at the instant the save action ran, apart from /tmp, which is cleaned on reboot. It is stored under an alias and deleted after 15 days. Anyone who can put that alias in a runs-on label can boot from it, so on public repositories the snapshot runners documentation warns that others may access the snapshot using the alias in a pull request workflow run. Run the documented cleanup before every save, and see snapshot runners for the label syntax and ephemeral storage for the term the rest of the catalog follows.