S3-Compatible Cache Backends

Runaway does not provide a cache backend. On a single host, the per-scale-set /cache volume is almost always the better choice — it’s a local filesystem mount with no network round-trip, no credentials, and no extra service to run.

You’d reach for an S3-compatible backend (MinIO, AWS S3, or similar) only when you need cache sharing across hosts — and the /cache volume is per-host, so it can’t do that on its own.

Caution

This is not a Runaway feature. There’s no Runaway setting that points runners at S3. What follows composes third-party actions/cache-compatible actions with your own object store — you own the backend and its credentials.

How the composition works

Several community actions implement an actions/cache-compatible interface backed by S3 instead of GitHub’s Actions Cache. They read their endpoint, bucket, and credentials from their own documented env vars or with: inputs — point those at your MinIO/S3. Variable names depend on the action you choose, but the shape is always an endpoint URL, a bucket name, and access credentials.

Caution

Credentials are your responsibility and are secret. Do not put S3 access keys in a scale set’s custom env — it’s stored as plaintext (see Custom environment variables). Pass them as GitHub Actions repository or organization secrets referenced from the workflow instead.

A minimal sketch (names vary by action):

- uses: <some-org>/s3-cache-action@v1
  with:
    endpoint: http://minio.lan:9000
    bucket: ci-cache
    key: deps-${{ hashFiles('lock-file') }}
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.CACHE_S3_KEY }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.CACHE_S3_SECRET }}

Related

• Caching — the per-scale-set /cache volume.
• Custom environment variables — why secrets don’t go here.
• Writing workflows — referencing secrets from a job.