Fastest GitHub Actions cache.
A 4 GB file saved with actions/cache and restored right away on 9 providers, 2 to 12 vCPU,
x64 and arm64. The runner is half of it: where actions/cache goes is the other half.
How this shows up in real builds
4 GB restore per provider
Each provider's fastest ranked result (3+ runs) at any sizeEach provider's fastest ranked 2 vCPU resultEach provider's fastest ranked 4 vCPU resultEach provider's fastest ranked 8 vCPU result, any action; RunsOn once per storage (EBS, local NVMe, tmpfs: the Storage pill); faded rows are provisional. Right: how long the save step took.
Faded: provisional, under 3 runs, not ranked.
Fastest x64 restore: RunsOn r8a.xlarge · tmpfs (5s), ahead of RunsOn m8a.2xlarge · EBS (6s).
Fastest arm64 restore: RunsOn r9g.xlarge · tmpfs (5s), ahead of RunsOn m9gd.2xlarge · NVMe (8s).
Faded: provisional, under 3 runs, not ranked.
Fastest x64 2 vCPU restore: RunsOn r8a.large · tmpfs (7s), ahead of Blacksmith (9s).
Fastest arm64 2 vCPU restore: RunsOn r9g.large · tmpfs (9s), ahead of Avrea (12s).
Fastest x64 4 vCPU restore: RunsOn r8a.xlarge · tmpfs (5s), ahead of RunsOn m8azn.xlarge · EBS (7s).
Fastest arm64 4 vCPU restore: RunsOn r9g.xlarge · tmpfs (5s), ahead of Avrea (11s).
Faded: provisional, under 3 runs, not ranked.
Fastest x64 8 vCPU restore: RunsOn m8a.2xlarge · tmpfs (5s), ahead of RunsOn m8a.2xlarge · EBS (6s).
Fastest arm64 8 vCPU restore: RunsOn m9g.2xlarge · tmpfs (5s), ahead of RunsOn m9gd.2xlarge · NVMe (8s).
Restore, job to job
Each provider's fastest machineEach provider's fastest 2 vCPU machineEach provider's fastest 4 vCPU machineEach provider's fastest 8 vCPU machine with two or more jobs (it may differ from the machine on the chart above). Every dot is one job.
- AWS CodeBuild 8 vCPU · 16 GB spread 8.8% (p10–p90) around a p50 of 34s, min 32s, max 35s, 7 samples
- Ubicloud 8 vCPU · 32 GB spread 22.2% (p10–p90) around a p50 of 55s, min 50s, max 1m 07s, 7 samples
- Avrea 4 vCPU · 16 GB spread 26% (p10–p90) around a p50 of 10s, min 9s, max 14s, 7 samples
- Namespace 8 vCPU · 16 GB spread 32.9% (p10–p90) around a p50 of 17s, min 15s, max 26s, 7 samples
- boat 8 vCPU · 16 GB p50 1m 11s, min 56s, max 1m 26s, 2 samples, not ranked
- Blacksmith 2 vCPU · 8 GB spread 35.6% (p10–p90) around a p50 of 9s, min 9s, max 14s, 7 samples
- RunsOn 12 vCPU · 48 GB spread 41.7% (p10–p90) around a p50 of 6s, min 6s, max 10s, 6 samples
- Warpbuild 4 vCPU · 16 GB spread 41.9% (p10–p90) around a p50 of 21s, min 19s, max 29s, 7 samples
- GitHub 8 vCPU · 32 GB spread 100.6% (p10–p90) around a p50 of 31s, min 21s, max 1m 06s, 7 samples
- Avrea 8 vCPU · 32 GB spread 14.3% (p10–p90) around a p50 of 11s, min 10s, max 12s, 6 samples
- RunsOn 8 vCPU · 32 GB spread 22.7% (p10–p90) around a p50 of 11s, min 10s, max 14s, 6 samples
- Ubicloud 8 vCPU · 32 GB spread 22.9% (p10–p90) around a p50 of 49s, min 45s, max 1m 01s, 7 samples
- Namespace 4 vCPU · 16 GB spread 32.7% (p10–p90) around a p50 of 22s, min 17s, max 26s, 7 samples
- GitHub 4 vCPU · 16 GB spread 42.8% (p10–p90) around a p50 of 36s, min 27s, max 49s, 7 samples
- Warpbuild 8 vCPU · 32 GB spread 45.7% (p10–p90) around a p50 of 21s, min 18s, max 39s, 7 samples
- Blacksmith 8 vCPU · 32 GB spread 107.8% (p10–p90) around a p50 of 18s, min 16s, max 36s, 7 samples
- AWS CodeBuild 2 vCPU · 3 GB spread 4.6% (p10–p90) around a p50 of 52s, min 50s, max 53s, 7 samples
- RunsOn 2 vCPU · 16 GB spread 8.8% (p10–p90) around a p50 of 17s, min 16s, max 19s, 6 samples
- GitHub 2 vCPU · 8 GB spread 27.2% (p10–p90) around a p50 of 1m 01s, min 58s, max 1m 20s, 7 samples
- Avrea 2 vCPU · 8 GB spread 27.7% (p10–p90) around a p50 of 13s, min 10s, max 16s, 7 samples
- Ubicloud 2 vCPU · 8 GB spread 29.2% (p10–p90) around a p50 of 59s, min 53s, max 1m 18s, 7 samples
- Blacksmith 2 vCPU · 8 GB spread 35.6% (p10–p90) around a p50 of 9s, min 9s, max 14s, 7 samples
- Namespace 2 vCPU · 8 GB spread 41.9% (p10–p90) around a p50 of 21s, min 17s, max 30s, 7 samples
- Warpbuild 2 vCPU · 8 GB spread 59.3% (p10–p90) around a p50 of 27s, min 24s, max 49s, 7 samples
- Avrea 2 vCPU · 8 GB spread 6.7% (p10–p90) around a p50 of 12s, min 12s, max 14s, 7 samples
- GitHub 2 vCPU · 8 GB spread 10.2% (p10–p90) around a p50 of 53s, min 49s, max 58s, 7 samples
- Ubicloud 2 vCPU · 8 GB spread 19.1% (p10–p90) around a p50 of 1m 04s, min 56s, max 1m 10s, 7 samples
- Warpbuild 2 vCPU · 8 GB spread 28.3% (p10–p90) around a p50 of 29s, min 26s, max 39s, 7 samples
- RunsOn 2 vCPU · 8 GB spread 28.9% (p10–p90) around a p50 of 19s, min 18s, max 29s, 6 samples
- Namespace 2 vCPU · 8 GB spread 46.2% (p10–p90) around a p50 of 26s, min 19s, max 34s, 7 samples
- Blacksmith 2 vCPU · 6 GB spread 171.3% (p10–p90) around a p50 of 23s, min 21s, max 1m 01s, 7 samples
- AWS CodeBuild 4 vCPU · 8 GB spread 8.6% (p10–p90) around a p50 of 35s, min 34s, max 37s, 7 samples
- RunsOn 4 vCPU · 16 GB spread 9.4% (p10–p90) around a p50 of 16s, min 15s, max 18s, 6 samples
- Namespace 4 vCPU · 8 GB spread 23.5% (p10–p90) around a p50 of 17s, min 15s, max 22s, 7 samples
- Avrea 4 vCPU · 16 GB spread 26% (p10–p90) around a p50 of 10s, min 9s, max 14s, 7 samples
- Blacksmith 4 vCPU · 16 GB spread 40% (p10–p90) around a p50 of 12s, min 8s, max 14s, 7 samples
- Warpbuild 4 vCPU · 16 GB spread 41.9% (p10–p90) around a p50 of 21s, min 19s, max 29s, 7 samples
- GitHub 4 vCPU · 16 GB spread 45.5% (p10–p90) around a p50 of 44s, min 26s, max 58s, 7 samples
- Ubicloud 4 vCPU · 16 GB spread 76.8% (p10–p90) around a p50 of 56s, min 46s, max 1m 53s, 7 samples
- Warpbuild 4 vCPU · 16 GB spread 9.6% (p10–p90) around a p50 of 27s, min 26s, max 31s, 7 samples
- RunsOn 4 vCPU · 16 GB spread 12.5% (p10–p90) around a p50 of 16s, min 15s, max 18s, 6 samples
- Avrea 4 vCPU · 16 GB spread 29.1% (p10–p90) around a p50 of 11s, min 9s, max 14s, 7 samples
- Ubicloud 4 vCPU · 16 GB spread 30% (p10–p90) around a p50 of 58s, min 51s, max 1m 15s, 7 samples
- Namespace 4 vCPU · 16 GB spread 32.7% (p10–p90) around a p50 of 22s, min 17s, max 26s, 7 samples
- GitHub 4 vCPU · 16 GB spread 42.8% (p10–p90) around a p50 of 36s, min 27s, max 49s, 7 samples
- Blacksmith 4 vCPU · 16 GB spread 73.3% (p10–p90) around a p50 of 21s, min 19s, max 35s, 7 samples
- AWS CodeBuild 8 vCPU · 16 GB spread 8.8% (p10–p90) around a p50 of 34s, min 32s, max 35s, 7 samples
- RunsOn 8 vCPU · 32 GB spread 13.6% (p10–p90) around a p50 of 11s, min 10s, max 13s, 6 samples
- Ubicloud 8 vCPU · 32 GB spread 22.2% (p10–p90) around a p50 of 55s, min 50s, max 1m 07s, 7 samples
- Warpbuild 8 vCPU · 32 GB spread 31.5% (p10–p90) around a p50 of 26s, min 22s, max 32s, 7 samples
- Avrea 8 vCPU · 32 GB spread 32.7% (p10–p90) around a p50 of 11s, min 9s, max 15s, 7 samples
- Namespace 8 vCPU · 16 GB spread 32.9% (p10–p90) around a p50 of 17s, min 15s, max 26s, 7 samples
- boat 8 vCPU · 16 GB p50 1m 11s, min 56s, max 1m 26s, 2 samples, not ranked
- Blacksmith 8 vCPU · 32 GB spread 70% (p10–p90) around a p50 of 12s, min 7s, max 16s, 7 samples
- GitHub 8 vCPU · 32 GB spread 100.6% (p10–p90) around a p50 of 31s, min 21s, max 1m 06s, 7 samples
- Avrea 8 vCPU · 32 GB spread 14.3% (p10–p90) around a p50 of 11s, min 10s, max 12s, 6 samples
- RunsOn 8 vCPU · 32 GB spread 22.7% (p10–p90) around a p50 of 11s, min 10s, max 14s, 6 samples
- Ubicloud 8 vCPU · 32 GB spread 22.9% (p10–p90) around a p50 of 49s, min 45s, max 1m 01s, 7 samples
- Namespace 8 vCPU · 16 GB spread 32.1% (p10–p90) around a p50 of 33s, min 31s, max 50s, 7 samples
- Warpbuild 8 vCPU · 32 GB spread 45.7% (p10–p90) around a p50 of 21s, min 18s, max 39s, 7 samples
- Blacksmith 8 vCPU · 32 GB spread 107.8% (p10–p90) around a p50 of 18s, min 16s, max 36s, 7 samples
Every result
Every machine and action, failures included.
Show every result102 results · x64, arm64
| x64 · runner | Action | Restore | Save |
|---|---|---|---|
| RunsOnr8a.xlarge · tmpfs | actions/cache | 5s | 7s |
| RunsOnm8a.2xlarge · tmpfs | actions/cache | 5s | 7s |
| RunsOnr8a.2xlarge · tmpfs | actions/cache | 5s | 7s |
| RunsOnm8a.2xlarge · gp3 1000 MiB/s | actions/cache | 6s | 8s |
| RunsOnm8azn.3xlarge · EBS gp3 | actions/cache | 6s | 9s |
| RunsOnr8a.large · tmpfs | actions/cache | 7s | 8s |
| RunsOnm8azn.xlarge · gp3 1000 MiB/s | actions/cache | 7s | 9s |
| RunsOni7i.2xlarge · local NVMe | actions/cache | 8s | 8s |
| RunsOni7i.xlarge · local NVMe | actions/cache | 9s | 8s |
| RunsOnm8a.2xlarge · EBS gp3 | actions/cache | 11s | 13s |
| RunsOnm8id.2xlarge · local NVMe | actions/cache | 11s | 10s |
| RunsOnm8i.2xlarge · EBS gp3 | actions/cache | 12s | 12s |
| RunsOnm8i-flex.2xlarge · EBS gp3 | actions/cache | 13s | 12s |
| RunsOnm8azn.xlarge · EBS gp3 | actions/cache | 16s | 16s |
| RunsOnm8a.xlarge · EBS gp3 | actions/cache | 17s | 16s |
| RunsOnc8a.2xlarge · EBS gp3 | actions/cache | 17s | 16s |
| RunsOnr8a.large · EBS gp3 | actions/cache | 17s | 16s |
| RunsOnm8i-flex.xlarge · EBS gp3 | actions/cache | 17s | 14s |
| RunsOnm8i.xlarge · EBS gp3 | actions/cache | 17s | 14s |
| RunsOnc8a.xlarge · EBS gp3 | actions/cache | 18s | 16s |
| RunsOnm8azn.large · EBS gp3 | actions/cache | 19s | 16s |
| RunsOnm8a.large · EBS gp3 | actions/cache | 19s | 16s |
| RunsOni7i.large · local NVMe | actions/cache | 19s | 14s |
| RunsOnm8i-flex.large · EBS gp3 | actions/cache | 20s | 15s |
| RunsOnm8i.large · EBS gp3 | actions/cache | 21s | 16s |
| RunsOnc8a.large · EBS gp3 | actions/cache | 30s | 35s |
| RunsOnm8id.xlarge · local NVMe | actions/cache | 30s | 24s |
| RunsOnt8i.medium · EBS gp3 | actions/cache | 32s | 34s |
| RunsOnm8id.large · local NVMe | actions/cache | 1m 08s | 45s |
| actions/cache: 1 of 6 jobs failed, latest failed in set up runneractions/cache: 1 of 6 jobs failed, latest saved in 1m 24s, restore failed after 26s | |||
| Blacksmith | actions/cache | 9s | 8s |
| Blacksmith | actions/cache | 12s | 6s |
| Blacksmith | actions/cache | 12s | 6s |
| Avrea | actions/cache | 10s | 19s |
| Avrea | actions/cache | 11s | 19s |
| Avrea | actions/cache | 13s | 19s |
| Namespace4x8 | actions/cache | 17s | 13s |
| Namespace8x16 | actions/cache | 17s | 13s |
| Namespace2x8 | actions/cache | 21s | 13s |
| Namespace8x32 | actions/cache | 21s | 13s |
| Namespace4x16 | actions/cache | 23s | 13s |
| Warpbuild | actions/cache | 21s | 15s |
| Warpbuild | actions/cache | 26s | 13s |
| Warpbuild | actions/cache | 27s | 17s |
| Warpbuild | WarpBuilds/cache | 1m 07s | 1m 24s |
| Warpbuild | WarpBuilds/cache | 1m 07s | 54s |
| Warpbuild | WarpBuilds/cache | 1m 12s | 1m 28s |
| GitHub | actions/cache | 31s | 18s |
| GitHub | actions/cache | 44s | 35s |
| GitHub | actions/cache | 1m 01s | 38s |
| AWS CodeBuildlarge | actions/cache | 34s | 1m 58s |
| AWS CodeBuildmedium | actions/cache | 35s | 2m 04s |
| AWS CodeBuildsmall | actions/cache | 52s | 2m 17s |
| Ubicloudstandard | actions/cache | 55s | 53s |
| Ubicloudpremium | actions/cache | 56s | 1m 09s |
| Ubicloudpremium | actions/cache | 56s | 50s |
| Ubicloudstandard | actions/cache | 59s | 56s |
| Ubicloudstandard | actions/cache | 1m 01s | 50s |
| Ubicloudpremium | actions/cache | 1m 04s | 58s |
| boat | actions/cache | 1m 11s | 48s |
| boat | actions/cache | 1m 30s | 59s |
| boat | actions/cache | failedsaved in 53s, restore failed after 10m 03s | |
| actions/cache: 1 of 2 jobs failed, latest saved in 2m 09s, restore failed after 1m 05s | |||
- tinted: fastest providers on the arch
- bold: fastest result
- actions/cache: GitHub's standard action
- owner/cache: the provider's own action
Which machines ran it2 notes
-
RunsOn ran on r8a.2xlarge, m8a.2xlarge, r8a.xlarge, r8a.large, m8azn.3xlarge, i7i.2xlarge, m8azn.xlarge, i7i.xlarge, m8id.2xlarge, m8i.2xlarge, m8i-flex.2xlarge, m8i-flex.xlarge, m8i.xlarge, c8a.2xlarge, m8a.xlarge, i7i.large, c8a.xlarge, m8azn.large, m8a.large, m8i-flex.large, m8i.large, m8id.xlarge, c8a.large, t8i.medium and m8id.large (x64) and m9g.2xlarge, r9g.xlarge, m9g.xlarge, m9gd.2xlarge, r9g.large, c8g.2xlarge, c8g.xlarge, m9g.large, m9gd.xlarge, c8g.large and m9gd.large (arm64) with Magic Cache:
the
extras=s3-cachelabel and theruns-on/actionstep. Its other machines have no cache run.
Where actions/cache goes
4 providers send it to their own storage, 3 with no workflow change. Namespace and Warpbuild leave it on GitHub's cache service, as GitHub's own runners do. AWS CodeBuild and boat document no rerouting.
| Provider | actions/cache goes to | Own cache | Docs |
|---|---|---|---|
| GitHub | GitHub's cache service (Azure Blob) | – | GitHub |
| RunsOn | rerouted S3 in your AWS account, via a label and runs-on/action | – | Magic Cache |
| Avrea | rerouted a local cache proxy | – | Avrea |
| AWS CodeBuild | not rerouted | – | – |
| Blacksmith | rerouted Blacksmith's colocated cache | useblacksmith/cache (archived) | Blacksmith |
| boat | not rerouted | – | boat |
| Namespace | not rerouted GitHub's cache service (Azure Blob) | Cache Volumes (not a save and restore; not measured) | Namespace |
| Ubicloud | rerouted Ubicloud's cache, stored on Cloudflare R2 | – | Ubicloud |
| Warpbuild | not rerouted GitHub's cache service (Azure Blob) | WarpBuilds/cache, to WarpBuild's storage | WarpBuild |
-
GitHub GitHub's cache service (Azure Blob)
own cache: none · docs
-
RunsOn rerouted S3 in your AWS account, via a label and runs-on/action
own cache: none · docs
-
Avrea rerouted a local cache proxy
own cache: none · docs
-
AWS CodeBuild not rerouted
own cache: none
-
Blacksmith rerouted Blacksmith's colocated cache
own cache: useblacksmith/cache (archived) · docs
-
boat not rerouted
own cache: none · docs
-
Namespace not rerouted GitHub's cache service (Azure Blob)
own cache: Cache Volumes (not a save and restore; not measured) · docs
-
Ubicloud rerouted Ubicloud's cache, stored on Cloudflare R2
own cache: none · docs
-
Warpbuild not rerouted GitHub's cache service (Azure Blob)
own cache: WarpBuilds/cache, to WarpBuild's storage · docs
- Warpbuild: WarpBuild's docs call GitHub's own cache "the recommended approach and is the most seamless experience for users", and keep WarpBuilds/cache for advanced use and bring-your-own-cloud. This test measures both on every WarpBuild runner.
Caches not measured here
Each works differently from a save and restore, so this test leaves it out.
- RunsOn: the ECR Docker layer cache (extras=ecr-cache) and EFS shared across jobs (extras=efs).
- Blacksmith: sticky disks (a disk attached to the runner, not a save and restore) and its Docker layer cache.
- Namespace: Cache Volumes (nscloud-cache-action), a disk attached to the runner rather than a save and restore.
- Warpbuild: snapshot runners (a job starts from a saved disk image).
Transparent cache or a provider action
Keep actions/cache and pick a runner that makes it fast.
- Warpbuild x64: WarpBuilds/cache 1m 07s–1m 12s restore, 54s–1m 28s save; actions/cache 21s–27s restore, 13s–17s save on the same 3 runners.
- Warpbuild arm64: WarpBuilds/cache 1m 05s–1m 17s restore, 53s–1m 30s save; actions/cache 21s–55s restore, 14s–25s save on the same 5 runners.
-
A rerouted
actions/cachespeeds up every action built on the cache API at once:setup-node,setup-python,setup-go,Swatinem/rust-cache, Docker'stype=ghacache. A provider action only speeds the steps you rewrite, on that provider's runners, and its fork lags upstream.
GitHub's cache limits
- 10 GB per repository at no charge, entries evicted after 7 days unused; since November 2025, admins can pay for more. 4 GB took 44s to restore on GitHub's x64 runner.
-
RunsOn's Magic Cache keeps
actions/cacheand sends it to S3 in your AWS account: no quota, your retention, your IAM policies. It takes a label,extras=s3-cache, plus theruns-on/actionstep.
How it's measured
One job per runner and action per run, 2 to 12 vCPU: save a 4 GB file, delete it, restore it, check its size. Times are the steps inside the job, medians across jobs; a failed job stays, at the step it failed.
Detailsworkload, consistency, earlier numbers
- A 4 GB random file saved with a cache action, deleted, restored right away on the same runner, and checked to be complete: actions/cache (GitHub's cache service, or whatever the provider routes it to) and the provider's own cache action where the provider still recommends one (Blacksmith archived useblacksmith/cache: actions/cache is routed to its cache). No pause between save and restore, so a cache that isn't read-after-write consistent shows up as a failure. File generation is not timed. The size check is not counted.
- Restore runs right after save. A cache that is not read-after-write consistent fails here; in a real job, the build silently starts cold.
- The same machines as the all-runners table, where each runner's
actions/cacherestore sits next to its builds. - Earlier versions of this page came from a different harness on 2 vCPU runners; those numbers are not comparable and are gone.
- Raw numbers: cache.json. Caching on RunsOn: docs. What to cache and how to key it: caching dependencies.