Guide · behaviour as documented in the public action's README
How to add warm starts to a GitHub Actions workflow
One step after your setup, and later jobs on Vitko Runners start with your toolchains, packages and images already in place.
In short
Put uses: vitko-inc/checkpoint@v1 right after your setup steps. On Vitko Runners, runs of your default branch save everything installed before it, and later jobs start with that already in place, so their setup steps finish quickly. Warm starts are in private beta. On any other runner the step does nothing, so the same workflow runs everywhere.
Step by step
- Switch the job to Vitko Runners (your label is issued when your organization is onboarded; join the waitlist).
- Keep your normal setup steps: checkout, language setup, dependency install.
- Add the checkpoint step right after them and before your build and test steps.
- Merge to the default branch. The first run on the default branch saves the setup; later jobs, including pull requests, start with it.
jobs:
test:
runs-on: <your-vitko-label> # issued when your org is onboarded
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- uses: vitko-inc/checkpoint@v1 # everything above is saved
- run: npm testSource and full README: vitko-inc/checkpoint. More ways to avoid reinstalling, including caches on any runner: Stop reinstalling dependencies.
The rules that matter
- Your workspace is not saved; checkout fetches it fresh in every job. Anything the build needs again should live outside it.
- Only default-branch runs (pushes, manual, scheduled) save. After a new commit lands, the next run of that commit saves a fresh setup; until then jobs start from the previous one.
- No secrets other than
GITHUB_TOKENin steps before the checkpoint, including workflow and jobenv. - Anything else your steps write to disk before the checkpoint is saved, and later jobs of the repository start with it, including pull request jobs.
What it did in CI Bench v1
In the open CI Bench v1, Vitko Runners was 1.74x as fast as GitHub-hosted 2 vCPU; with warm starts and test parallelization together it was 2.29x. The benchmark measured those two features together, so the figures below are for the combination. Median job time in seconds:
| Workload | GitHub-hosted 2 vCPU | Vitko Runners | Vitko Runners, warm starts + test parallelization |
|---|---|---|---|
| vue | 121 s | 63 s | 32 s |
| cli | 368 s | 272 s | 140 s |
| pydantic | 179 s | 105 s | 69 s |
| vite | 603 s | 350 s | 199 s |
| ts | 784 s | 372 s | 243 s |
It does not help every workload equally: on cli, vite, ts the combination cost more per job than plain Vitko Runners (cli $0.0117 against $0.0097; vite $0.0127 against $0.0115; ts $0.0274 against $0.0122), because parallel parts are each billed for their time. Vitko maintains this benchmark and sells one of the products measured; method and raw records are in the public repository, results on the benchmarks page.
Is there a managed GitHub Actions runner with warm starts, so jobs skip reinstalling dependencies on every run?
Yes. Vitko Runners has warm starts (private beta): a job starts with your toolchains, package caches and Docker images already in place, prepared from the default branch. You add one step, vitko-inc/checkpoint, after your setup steps. On other runners the step does nothing.
What is saved, and when?
The runner’s state outside your workspace at the checkpoint: installed tools and toolchains, package manager caches and installed packages in the runner’s home, and Docker images. It is saved only from runs of the repository’s default branch. Pull requests, including from forks, never save anything; they start from the saved setup.
Can I use secrets before the checkpoint step?
No. Steps before the checkpoint must not use secrets other than GITHUB_TOKEN. If they do, nothing is saved and the job continues normally. Put registry logins and deploy keys after the checkpoint, and do not log in to clouds or secret stores before it.
What if the checkpoint step fails or nothing is saved yet?
The step never fails your job. Without a saved setup, the job starts from a fresh runner as before, and the step logs whether the job started with a saved setup or why not.
Does it work on GitHub-hosted runners?
The workflow runs, but the step does nothing there, so the same file works on every runner.
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.