VM Snapshot

A VM snapshot is a saved copy of a virtual machine's disk, and in some implementations its memory and CPU state, recorded at one point in time. A machine started later from that copy comes up with the filesystem exactly as it stood at capture, so the work already done on that disk is present before the first command runs.

In GitHub Actions the appeal is direct. A job that installs the same dependency tree on every run repeats work that a previous machine already finished, and a snapshot lets a later job begin from a machine where that work has already happened.

DefinitionCopy Anchor Link

A virtual machine reads and writes a virtual disk, which the hypervisor backs with a file or a block device. A snapshot records the contents of that disk at an instant. The record can be a full copy of every block, though implementations more often store a pointer to an earlier copy plus the blocks that changed since it, which is why the second snapshot of a machine is usually far smaller than the first.

Most systems capture the disk without pausing the machine, using copy-on-write. Once the capture starts, new writes go to a fresh layer while the frozen blocks stay readable, so the snapshot is consistent with the disk at the instant it began rather than with the disk as it looks when the capture finishes. Some implementations expose dependent delta chains; managed cloud snapshot services can manage those dependencies internally. For example, deleting an earlier EBS snapshot does not invalidate later snapshots.

Two kinds of capture exist, and the difference decides what a restored machine can do.

A disk-only snapshot records the virtual disk alone. Its consistency depends on capture coordination: without quiescing applications it may be crash-consistent, while coordinated capture can provide stronger application consistency. Block storage snapshots from the major clouds work this way, including Amazon EBS snapshots and Google Compute Engine disk snapshots (checked on 2026-08-13).

A full state snapshot adds the contents of RAM, the CPU registers, and virtual device state. A machine restored from one resumes mid-instruction with its processes still running. This kind is common in desktop hypervisors and in live migration, and it is rare in build infrastructure because the captured memory is large and a resumed process holds stale network connections.

The practical consequence for a build machine is a short list of what survives a disk-only capture.

Four neighboring terms get used interchangeably and should not be.

• Image. A prepared disk built by a pipeline and published as a versioned artifact for many machines to boot from. A snapshot is captured from one running machine rather than built from a definition, and it is usually short lived.
• Backup. A retained recovery copy governed by a backup policy. Some snapshots can serve as backups, but recovery guarantees depend on storage independence, retention, and consistency.
• Checkpoint. A full state capture taken so execution can resume from the same instant. Every checkpoint is a snapshot; most snapshots are disk-only and are not checkpoints.
• Clone. A new machine created from a snapshot or an image. The snapshot is the record; the clone is the machine that reads it.

Because a snapshot occupies storage for as long as it is kept, providers charge for it by time and expire it on a retention window. That turns the interesting question from whether a snapshot can be taken into how often it should be refreshed and how long the captured state stays close enough to the current commit to be worth booting.

ExampleCopy Anchor Link

WarpBuild snapshot runners are supported only on WarpBuild Cloud Ubuntu runners. BYOC, Windows, and macOS are not supported; snapshot labels on those platforms are silently ignored.

The pattern in GitHub Actions is a capture after the expensive preparation step, followed by later jobs that boot from the captured disk. This workflow installs a dependency tree, builds, tests, removes credentials, then captures the machine under an alias:

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

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-2x;snapshot.key=web-deps
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npm run build
      - run: npm test
      - name: Remove credentials before capture
        run: |
          rm -rf $HOME/.ssh $HOME/.aws
          git clean -ffdx
      - uses: WarpBuilds/snapshot-save@v1
        with:
          alias: web-deps

The label suffix and the capture action follow the syntax in the snapshot runners documentation, checked on 2026-08-13.

The first run finds no saved disk for the alias web-deps, so the machine boots the base image and every step does its full work. The cleanup removes untracked and ignored workspace files, including a typical node_modules directory. The snapshot can retain ~/.npm outside that workspace and tracked repository data; it does not preserve files the cleanup deleted. The next run boots that captured disk, so the machine reaches its first step with the state below already in place.

Two details decide whether the pattern holds up. The capture takes whatever is on disk, so an SSH key or a cloud credential file written during the job lands in the saved copy and reaches every machine that later boots it. The example cleanup removes common credential locations, but it is not an exhaustive secret scrub: inspect every tool and path that may have written credentials. The captured tree ages against the repository: once a lockfile changes, the versions the install step asks for sit outside the captured cache and the step fetches them again, so a stale alias quietly stops helping and needs a fresh capture.

Related TermsCopy Anchor Link

• Snapshot runners and the label options that select them: the snapshot.enabled and snapshot.key label suffixes, the platforms that accept them, and the retention window.
• What carries over in a runner snapshot: the state a later job finds on disk and the state it has to rebuild.
• Warm caches and what keeps a cache warm between jobs: the broader idea a snapshot is one implementation of.
• Snapshot runners documentation: capture syntax, cleanup guidance, and the supported platforms.
• Cloud runners documentation: the runner labels a workflow can point runs-on at.
• WarpBuild pricing: per minute rates by runner type.