Skip to content
RunsOn - 10x cheaper self-hosted GitHub Actions runners RunsOn
Blog

GitHub Actions Cache performance

This guide compares cache performance across GitHub Actions runners - including official GitHub runners, self-hosted solutions, and third-party providers.

Providers included in the benchmark

Official:

Self-hosted alternatives:

Third-party alternatives:

Note: I’d love to benchmark Depot (hosted on AWS), but they forbid benchmarking their platform 🤷.

Benchmark results

Last updated:

The table below presents the results for saving and restoring a 4GB file (randomly generated) using the actions/cache action.

At most Hetzner-based providers, the bandwidth to the default GitHub Azure backend is abysmal, so most of them provide a specific action that you can use instead. It’s not clear where the files end up as a result. As far as I know it could be in a local Ceph cluster, on Cloudflare R2, etc.

Other providers like Ubicloud and RunsOn offer a transparent cache, which allows to reuse the same official actions (including language-specific actions) in your workflows.

Cache Performance: Save Time vs. Restore Time

0s 20s 40s 60s 80s 100s 120s 140s 160s Save Time (seconds) 0s 20s 40s 60s 80s 100s 120s 140s 160s 180s 200s 220s Restore Time (seconds) BuildjetUbicloudNamespaceWarpbuildGithubCodebuildBlacksmithWarpbuildCirrusRunsOnBlacksmith Providers Best providers areaRunsOnGitHubOther Providers

Lower save and restore times (closer to bottom-left) are better.

Provider Action Save Time Restore Time Total Time
Blacksmith useblacksmith/cache@v5 17s 26s 43s
RunsOn actions/cache@v4 23s 21s 44s
Namespace actions/cache@v4 19s 37s 56s
Github actions/cache@v4 33s 45s 78s
Warpbuild WarpBuilds/cache@v1 59s 27s 86s
Ubicloud actions/cache@v4 47s 69s 116s
Warpbuild actions/cache@v4 32s 145s 177s
Codebuild actions/cache@v4 143s 37s 180s
Blacksmith actions/cache@v4 28s 183s 211s
Cirrus actions/cache@v4 56s 169s 225s
Buildjet actions/cache@v4 46s 194s 240s

Transparent cache vs. provider-specific actions

The GitHub Actions cache ecosystem has evolved into two distinct approaches for improving cache performance: transparent cache implementations and provider-specific actions.

Transparent cache implementations

Transparent cache solutions intercept GitHub’s native cache API calls and redirect them to faster, local storage backends without requiring any workflow modifications. This approach maintains full compatibility with all existing GitHub Actions, including:

  • Standard caching actions: actions/cache, actions/setup-* (Node.js, Python, Go, etc.)
  • Third-party caching actions: Swatinem/rust-cache, language-specific tools
  • Docker layer caching: docker/build-push-action with type=gha

Providers offering transparent cache:

  • RunsOn: Magic Cache feature redirects cache requests to S3 within your VPC
  • Ubicloud: Transparent caching redirects to Cloudflare R2 storage
  • Depot: Intercepts cache API and uses S3 backend

Advantages:

  • Zero workflow changes required - works as drop-in replacement
  • Supports all existing cache actions and language-specific setups
  • Easy to evaluate and switch between providers
  • Maintains ecosystem compatibility

Provider-specific cache actions

Many Hetzner-based providers require you to replace GitHub’s cache actions with their own forked versions to access their faster cache backends.

Examples:

  • BuildJet: Replace actions/cache with buildjet/cache, actions/setup-* with buildjet/setup-*
  • Blacksmith: Use useblacksmith/cache and useblacksmith/setup-* actions
  • Warpbuild: Provider-specific action replacements

Advantages:

  • Often optimized for specific provider infrastructure
  • May offer additional features or configuration options
  • Can have better upload performance due to custom optimizations

Disadvantages:

  • Requires workflow modifications for each action
  • Creates vendor lock-in - harder to switch providers
  • Need to maintain multiple versions of workflows
  • Doesn’t support all third-party actions
  • Limited Docker layer caching support

Why transparent cache is superior

The transparent approach is technically superior because it provides the same performance benefits while maintaining ecosystem compatibility. You can seamlessly switch between providers or test multiple providers in a matrix configuration without changing your workflows.

GitHub’s cache v2 backend and storage limitations

GitHub recently announced significant changes to their cache infrastructure, but these improvements don’t address the fundamental limitations that make RunsOn a better choice.

GitHub’s cache v2 rollout (February 2025)

GitHub is migrating to a new cache backend service (v2) starting February 1, 2025, with the legacy service being sunset on the same date. Key changes include:

  • Performance improvements: Up to 80% faster upload times for hosted runners
  • Backend rewrite: Complete rebuild of the cache service for improved reliability
  • API compatibility: Fully backward compatible with existing actions
  • Mandatory upgrade: All deprecated cache action versions will fail after February 1, 2025

However, these improvements only apply to GitHub’s hosted runners and don’t address the core architectural limitations.

Persistent GitHub cache limitations

Despite the v2 improvements, GitHub’s cache still suffers from fundamental constraints:

Storage limitations:

  • 10GB limit per repository: Quickly exhausted by Docker layers, large dependencies, or multiple cache entries
  • 7-day eviction policy: Caches automatically deleted after one week of inactivity

Performance constraints:

  • Network bandwidth limits: ~125 MB/s (1 Gbps) maximum throughput to Azure
  • Geographic latency: Cache stored in Azure regions, adding network hops