Fastest GitHub Actions Runners: Cache

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

Benchmark results

Last updated:June 6, 2025

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.

Providers can then be ordered by tiers:

• Tier1: Blacksmith, Namespace, RunsOn: very fast save and restore times, fully transparent caching using the usual actions without any modifications.
• Tier2: GitHub, Shipfox, Ubicloud: slightly slower, but still fast and no changes required.
• Tier3: Warpbuild, Cirrus, Codebuild, Buildjet: either abysmal performance (or even complete failure), or requires provider-specific actions to get decent performance.

Full results below (test run on 2026-01-20):

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