Skip to content
compiler.dev
Get started

GitHub Actions cache key builder

Pick your package manager and get an actions/cache step with the right paths, a lockfile-based key and a restore-keys fallback so installs stay fast and caches never go stale.

Bump to invalidate every existing cache

Workflow step

- uses: actions/cache@v4
  with:
    path: |
      ~/.npm
    key: ${{ runner.os }}-npm-v1-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-v1-

Exact key: ${{ runner.os }}-npm-v1-${{ hashFiles('**/package-lock.json') }}. Fallback prefix: ${{ runner.os }}-npm-v1-

Everything runs in your browser; nothing you type is sent anywhere.

How to use it

  1. Choose your package manager. The cache paths and lockfile pattern fill in automatically.
  2. Decide whether the key includes the OS and CPU architecture, and add a version salt you can bump to bust the cache.
  3. Copy the YAML into your workflow before the install step.

Frequently asked questions

What makes a good cache key?

A prefix that identifies the OS, tool and a salt, followed by a hash of the lockfile. When the lockfile changes the key changes, so you get a fresh cache.

What are restore-keys for?

If there is no exact match, GitHub restores the most recent cache whose key starts with a restore key. Your install then only fetches what changed.

How do I invalidate a bad cache?

Change the version salt in the key, for example from v1 to v2. Old entries age out after 7 days without use.

How big can the cache be?

A repository gets 10 GB of cache in total by default, and least recently used entries are evicted when it fills.

Related tools