Cache

Jobs on AWS keep GitHub’s cache in your own AWS account. Nothing in your workflows changes: actions/cache, the setup actions’ caches and Docker’s type=gha reach it as they reach GitHub’s.

On a 16-CPU machine a 4 GB cache saved in 10 s and came back in 11 s. GitHub’s own cache took 12 s and 21 s.

Where it is kept

Each region your machines run in gets a bucket of the control plane’s, superci-plane-<id>-<region>, and a free S3 endpoint in its network. A cache never leaves your account and never goes over the internet. The dashboard makes both with your sign-in, beside each region’s network.

Who may read and write what

Each machine runs superci-cache, which holds no keys. For every lookup and save it asks the control plane with the job’s own token. The control plane checks that token against GitHub’s keys and signs links to the bucket that each do one thing.

A job reads and writes what GitHub would let it. A pull request reads its own branch’s caches, then its base’s and the default branch’s, and writes only its own.

What it keeps

On unless you turn it off. Settings → Cache, or:

superci caches retrieve                         # whether it is on, and what each repository keeps
superci caches update --size-gb=50 --days=14
superci caches update --enabled=false           # jobs use GitHub's own cache
superci caches list --repo=acmeci/api           # its entries: key, branch, size, last use
superci caches delete --repo=acmeci/api --confirm

• Each repository keeps 25 GB unless set; the least recently used entries go first.
• An entry unused for 7 days goes.
• An entry saved 30 days ago is saved anew, however often it is used. The bucket removes anything older than 32 days by itself.

Turbo, Nx and Bazel

Their remote caches go to the same bucket, with nothing to set. Each machine tells them where: Turbo and Nx in the runner’s environment, Bazel in its system-wide settings. A workflow’s own settings still come first, so a Vercel token goes on to Vercel.

They carry no GitHub token, so what they may read and write is what GitHub said of the job: its own branch’s to write, and the default branch’s to read. A branch never writes where the default branch reads.

GitLab and Windows

GitLab jobs on AWS keep GitLab’s own cache there: GitLab’s runner is pointed at it as S3, by project and by the branch the job runs for. Windows machines on AWS use it too.

When it is not used

• Machines on Cloudflare and Modal keep using GitHub’s cache.
• When the control plane cannot be reached, jobs use GitHub’s cache as before.
• Caches saved at GitHub earlier are used until they age: a lookup your bucket does not have is asked of GitHub.
• Artifacts of GitHub’s jobs stay at GitHub.