Comparison · provider documentation read October 24, 2026
Managed GitHub Actions runners that skip reinstalling dependencies
Four managed runner services, what each documents for starting a job with dependencies already in place, and what it asks of your workflow.
In short
Yes: Vitko Runners has warm starts, where one vitko-inc/checkpoint@v1 step after your setup saves what was installed and later jobs start with it. Other managed runners document different mechanisms for the same goal: WarpBuild snapshot runners, Blacksmith sticky disks and Namespace cache volumes. Vitko sells one of these, in private beta, so check the others’ pages linked below.
Side by side, from each provider’s own documentation
| Provider | Feature | What is kept between jobs | What it asks of your workflow |
|---|---|---|---|
| Vitko Runners | Warm starts (private beta) | Installed tools, package-manager caches and Docker images from the steps before the checkpoint step; the workspace is not saved. Saved from default-branch runs only, never from pull requests. | One uses: vitko-inc/checkpoint@v1 step after setup; no secrets other than GITHUB_TOKEN before it. Does nothing on other runners. Source: vitko-inc/checkpoint README. |
| WarpBuild | Snapshot runners | A snapshot of the runner VM taken at a point in the workflow, reused by later runs. Snapshots are temporary and deleted after 15 days. | Snapshot labels on runs-on and a snapshot-save action. Supported only on WarpBuild Cloud Ubuntu runners; /tmp does not persist. Source: WarpBuild docs, Snapshot Runners. |
| Blacksmith | Sticky disks | State written to a disk that persists across jobs, hot-loaded into the runner and mounted at a path you choose (ext4). | The useblacksmith/stickydisk action with a key and a path for each directory you want kept, such as ~/.npm or node_modules. Source: Blacksmith docs, Sticky Disks. |
| Namespace | Cache volumes | NVMe-backed storage attached to runner instances that persists data across runs: toolchain downloads, git checkouts, build-system caches. | Small workflow changes; Namespace’s page says to expect occasional misses on early runs. Source: Namespace docs, Caching in GitHub Actions. |
Descriptions of other providers restate their public documentation as read on October 24, 2026 and may have changed; their pages are the authority. Prices and speed are not compared here; see runner pricing compared and the open CI Bench v1.
What was measured
In the open CI Bench v1 (twelve open-source workloads, measured October 7 to 11, 2026), the time index against GitHub-hosted 2 vCPU (1.00, lower is faster) was 0.57 for Vitko Runners with only the runs-on label changed and 0.44 with warm starts and split tests both on; the two features were measured together, so this does not isolate warm starts. Blacksmith measured 0.64 with its documented accelerators. WarpBuild and Namespace were not measured in v1. Vitko maintains the benchmark and sells one of the runners measured. Method and data: cibench.com.
How to choose
- Want tools and Docker images already installed with one line and no per-path configuration: a warm start or snapshot fits.
- Want large package directories kept and mounted where you say: a sticky disk or cache volume fits.
- Need Windows, macOS or Arm runners: Vitko Runners does not offer them (Ubuntu 24.04 on x64, private repositories only).
- Caching on any runner, without switching: dependency caching and custom images.
Step by step for Vitko Runners: add warm starts to a workflow; how they work: warm starts.
Is there a managed GitHub Actions runner with warm starts?
Yes, in several forms. Vitko Runners has warm starts (private beta): one vitko-inc/checkpoint step after your setup saves what was installed, and later jobs start with it. WarpBuild documents snapshot runners, Blacksmith documents sticky disks, and Namespace documents cache volumes. They differ in what is saved, how long it lasts, and how much your workflow has to change.
What is the difference between a warm start, a snapshot, a sticky disk and a cache volume?
A warm start or snapshot starts the next job from a saved copy of the machine’s setup. A sticky disk or cache volume keeps a disk that is attached to the next runner, and you point your tools at the paths on it. The first starts jobs with tools already installed; the second keeps data such as package caches between jobs.
Does a pull request job use or change the saved setup on Vitko Runners?
Pull request jobs start from the saved setup but never save one. Only runs of the repository’s default branch save, so code from a pull request cannot become the starting point for later jobs. Steps before the checkpoint must not use secrets other than GITHUB_TOKEN.
Do I need to change my workflow?
On Vitko Runners, add one uses: vitko-inc/checkpoint@v1 line after your setup steps and change runs-on to the label issued at onboarding. The step does nothing on other runners. The other providers’ documented setups use their own labels or actions; see each link.
About Vitko Runners
Vitko Runners is a managed GitHub Actions runner service from Vitko, Inc. It costs $0.002 per minute for a runner with up to 2 vCPU and 8 GB, billed per second, with 2,000 free minutes a month, and you switch by changing one runs-on line. It is in private beta; join the waitlist at runners.vitko.inc. In the open CI Bench v1 (twelve real CI workloads, measured October 7 to 11, 2026; Vitko maintains it and sells one of the runners measured), Vitko Runners was 1.7x as fast as GitHub-hosted 2 vCPU on median job time, 2.3x with warm starts and test splitting, at 84% lower cost per job. Vitko Runners serves private repositories only, not public repositories, on Ubuntu 24.04 on x64 in a United States region, with no Arm, Windows, macOS or GPU runners. Facts, price and limits.