Dependency caching (Fast Cache)

Latchkey Fast Cache saves and restores dependency caches in a single streaming request, with storage in the same region as your runner and zero configuration.

Latchkey Fast Cache (latchkey-dev/cache-action@v1) is a lightweight GitHub Action for saving and restoring dependency caches (node_modules, package registries, build artifacts) on Latchkey managed runners. Repeat runs skip installs your pipeline has already done.

Why it is fast#

• Cache data moves in a single streaming HTTP request instead of the serial chunk pattern actions/cache@v4 uses: no per-chunk round trips, no temp files.
• Compression and decompression are multi-threaded (zstd), and uploads and downloads run as parallel transfers.
• Storage lives in the same region as your runner, so the bytes never travel far.
• Every save and restore prints its timing in the job log, so you can measure the difference on your own builds.

Add it to a workflow#

Add two steps: one with action: restore and one with action: save. Each takes a key and one or more path entries (newline or space separated; ~ is supported). The restore step exposes a cache-hit output so you can skip install steps when the cache lands.

jobs:
  build:
    runs-on: latchkey-medium
    steps:
      - uses: actions/checkout@v4

      - name: Restore dependencies
        id: cache
        uses: latchkey-dev/cache-action@v1
        with:
          action: restore
          key: deps-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
          path: node_modules

      - name: Install dependencies
        if: steps.cache.outputs.cache-hit != 'true'
        run: npm ci

      - name: Save dependencies
        uses: latchkey-dev/cache-action@v1
        with:
          action: save
          key: deps-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
          path: node_modules

Switching from actions/cache#

Safe defaults#

• A restore failure never fails the job: you get a warning, cache-hit reads false, and the run continues.
• Save is skipped automatically when the key already exists, so identical caches are never re-uploaded.
• Caches are isolated per organization and automatically versioned by operating system; encode finer isolation (like OS versions) in your cache key.

What you see in job logs#

Caching you do not have to find#

The AI Scan detects which caches your project needs and lists them in the proposed runner configuration, and AI optimization PRs can add or replace caching steps for you, ready to merge. Teams that never hand-tune caching still get it.