A co-located cache backend that accelerates actions/cache transparently - no workflow changes, no size caps. Restore dependencies in seconds instead of waiting on downloads.

Restore dependencies in seconds. Stop paying for time spent waiting on downloads.

On Monk CI, the GitHub Actions cache API is served from a backend co-located with your runners. Your existing actions/cache steps - and the built-in caching in setup-node, setup-python, and friends - are intercepted and served locally. Restore and save steps that previously took 30–60 seconds complete in under 3 seconds, with no workflow changes.

Getting Started

There's nothing to install. Run your job on a Monk CI runner and your existing cache steps are automatically faster:

jobs:
  build:
    runs-on: monkci-ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - run: npm ci

The same key and restore-keys you already use work unchanged - Monk CI just serves them from a faster, co-located store.

The only requirement is that the job runs on a Monk CI runner (e.g. runs-on: monkci-ubuntu-latest). The acceleration is transparent - you do not swap the action or add any configuration.

Built-in setup-action caches

Caching wired into the setup-* actions is accelerated the same way - no extra steps needed:

- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: npm # restored from Monk CI's co-located cache

This works for setup-node, setup-python, setup-go, setup-java, and any action built on the standard cache API.

Third-party cache actions

Popular community cache actions (Swatinem/rust-cache, actions/cache/restore, and similar) are built on the same underlying cache protocol, so they're accelerated automatically too - keep using whatever your workflow already has.

How It Works

Co-located backend - Cache nodes sit on the same high-speed network as the runners. A restore is a local network read, not a round trip to a remote object store on the public internet.

Transparent interception - Monk CI is fully compatible with the GitHub Actions cache API. Requests from actions/cache and the setup-* actions are served from the co-located store with no code changes.

Persistent across runs - Cache entries persist across workflow runs and are available to all jobs in the same repository. Anything cached on a previous run is immediately available on the next.

Automatic invalidation - Keys follow the same key / restore-keys pattern as actions/cache. Entries are invalidated when the key changes, so a stale dependency set is never silently restored after a lock file update.

No size limits - There are no per-repository or per-organization cache caps. Large monorepos and multi-language projects work without manually pruning or rotating entries.

Monk CI Cache vs GitHub Actions Cache

	Monk CI	GitHub Actions
Cache location	Co-located	Remote object store
Typical restore time	Under 3 seconds	30–60 seconds
Storage limit	No limit	10 GB per repo
Compatible with actions/cache	Yes, transparent	N/A
Workflow changes required	None	N/A

Metric	Value	Detail
Faster cache	4x	vs GitHub Actions cache
Avg restore time	Under 3s	For most dependency trees

Monk CI runners and cache work together natively to deliver maximum performance, with the most dramatic gains on jobs that previously spent 40% of their runtime on cache operations.

Pricing

No Additional Cost

Caching is included with Monk CI runners at no extra charge. For details on overall platform pricing, visit the Pricing page.

4x Faster Cache