Guide · sources checked October 19, 2026

How to stop reinstalling dependencies on every GitHub Actions run

Why every job starts from an empty machine, and three ways to stop paying for the same installs again.

In short

Each GitHub-hosted runner is a new virtual machine (single-CPU runners are the exception), so installs repeat unless you save them. The usual fix is dependency caching: actions/setup-node and similar setup actions have a cache option, and actions/cache does it for anything else. If you also want tools and Docker images ready, use a custom runner image or a runner with warm starts. Vitko Runners has warm starts: one step, vitko-inc/checkpoint@v1, after your setup, and later jobs start with the setup already in place. Vitko sells that runner, in private beta, so read the comparison with that in mind.

Why installs repeat

GitHub describes each GitHub-hosted runner as a new virtual machine, apart from single-CPU runners, which run in a container on a shared machine (About GitHub-hosted runners). A new machine has none of the packages a previous job downloaded, so every job installs them again unless something saves them between jobs.

Three ways, side by side

Ways to avoid reinstalling dependencies in GitHub Actions
	Dependency cache	Custom runner image	Warm starts on Vitko Runners
What is kept	Package downloads for the key you choose	Whatever you bake into the image	Installed tools, package caches and packages in the runner’s home, and Docker images
What you add	A `cache` option or a cache step	An image-building pipeline you maintain	One step after your setup
Your install step	Still runs, using the restored cache	May no longer be needed	Still runs, and finds its work done
Limits	Removed after 7 days without use; 10 GB per repository by default	You rebuild the image when dependencies change	Ubuntu 24.04 x64, private beta

1. Dependency caching

Most setup actions can cache for you. actions/setup-node accepts cache: npm, yarn or pnpm. It caches the package manager’s global data, not node_modules, and keys the cache on your lockfile (actions/setup-node).

- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: npm
- run: npm ci

Rules worth knowing, from GitHub’s documentation: a run can restore caches from its own branch or the default branch, not from sibling branches; entries not accessed in over 7 days are removed; the default limit is 10 GB per repository (Dependency caching reference).

2. A custom runner image

If you need tools installed beyond what a cache holds, GitHub-hosted runners support custom images, and since June 2026 an image can be built on top of another custom image (GitHub changelog, June 18, 2026). You maintain the pipeline that builds the image and rebuild it when your dependencies change. See GitHub’s documentation for the plans and runner types that support it.

3. Warm starts on Vitko Runners

Put one step right after your setup. Everything before it is saved from runs of your default branch, and later jobs of the repository start with it in place. Your setup steps still run, but find their work done.

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 test

Saved: installed tools and toolchains, package manager caches and packages in the runner’s home (npm, pnpm, Yarn, pip, uv, cargo, Go, Maven, Gradle and others), and Docker images. Your workspace is not saved; checkout fetches it fresh.
Saved only from default-branch runs. Pull requests, including from forks, never save anything.
Steps before the checkpoint must not use secrets other than GITHUB_TOKEN. If they do, nothing is saved and the job continues normally.
On any other runner the step does nothing and never fails your job, so one workflow runs everywhere.

Full reference: Warm starts. Source: github.com/vitko-inc/checkpoint. Price: $0.002 a minute, billed per second, with 2,000 free minutes a month (pricing).

How do I stop reinstalling dependencies in every GitHub Actions run?

Cache them. Most setup actions have a cache option (for example actions/setup-node with cache: npm), or you can use actions/cache with a key built from your lockfile. The next run restores what an earlier run saved instead of downloading everything again. Custom runner images and runners with warm starts go further by also preparing tools and Docker images.

How long does GitHub keep a dependency cache?

GitHub removes cache entries that have not been accessed in over 7 days, and the default limit is 10 GB per repository. Caches made on a pull request branch cannot be restored by other pull requests.

Is there a managed GitHub Actions runner with warm starts?

Yes. Vitko Runners has warm starts, in private beta: jobs start with your toolchains, packages and Docker images already in place. You add one step, vitko-inc/checkpoint@v1, after your setup. On any other runner the step does nothing.

Does a warm start run pull request code in the saved setup?

No. On Vitko Runners the setup is saved only from runs of your default branch. Pull requests, including ones from forks, never save anything; they start from the default branch’s setup and install whatever their changes need.

What are the limits of warm starts on Vitko Runners?

Ubuntu 24.04 on x64 only, private repositories, in private beta. Steps before the checkpoint must not use secrets other than GITHUB_TOKEN, or nothing is saved. A setup script (.vitko/setup.sh) cannot use Docker yet; the checkpoint step can save Docker images.

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.

Join the private beta All runners compared