Caching

Every scale set gets a persistent /cache volume mounted into every runner. It survives across runner generations — a fresh ephemeral container picks up the warm cache the previous one left behind. This is the biggest difference between a Runaway runner and a GitHub-hosted one, and it changes how you write workflows.

Pre-wired ecosystem caches

Runaway points these package managers at the /cache volume out of the box:

yarn
npm
pnpm
pip
Go modules
cargo

No configuration — installs land on the persistent volume and the next run reuses them.

Skip GitHub’s Actions Cache for tool binaries

On a GitHub-hosted runner, actions/cache@v4 and actions/setup-node’s cache: input make sense: the runner is thrown away with nothing persistent attached, so caching means tar + compress + round-trip through GitHub’s Cache service.

On a Runaway runner that round-trip is slower than reading the already-warm local /cache volume. Point your tools at /cache instead.

Drop the cache: input — the pnpm store already lives on the volume:

# No `cache: pnpm` — the store already persists on /cache.
- uses: actions/setup-node@v4
  with:
    node-version: 22

Put browser binaries and other heavy tool downloads on the volume directly:

env:
  PLAYWRIGHT_BROWSERS_PATH: /cache/ms-playwright

With the path on /cache, playwright install no-ops on warm runs instead of re-downloading browsers every job.

The cache panel

The cache panel is host-scoped — /cache is a physically distinct Docker volume on each host, so the panel shows you one host’s volume at a time behind a host selector, never a cross-host sum. The purge action is gated on no live runners using the volume, so you can’t wipe a cache out from under a running job.

Isolated runners and the cache volume

A scale set on the isolated-sysbox runtime gets a fresh inner Docker daemon per runner, so Docker layer cache does not carry across generations — that matches github-hosted semantics. The /cache filesystem volume still bind-mounts in, so your ecosystem and tool caches survive exactly as they do on the shared-daemon runtime.

Writing workflows for Runaway