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:July 8, 2026

Latest results for saving and restoring a 4GB randomly generated file with cache actions:

The benchmark uses the standard actions/cache action unless the provider offers a specific cache action, which is shown in the Action column.

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, Avrea, Namespace, and RunsOn: very fast save and restore times, with latest totals between 24s and 37s. RunsOn, Avrea, and Namespace use the standard actions/cache@v4; Blacksmith is fastest but only when using a custom action with useblacksmith/cache@v5.
• Tier2: GitHub and Starsling: usable, but clearly slower than the top group, at 78s and 91s total.
• Tier3: Ubicloud, Warpbuild’s provider-specific cache, and AWS CodeBuild: slower again, from 113s to 176s total.
• Tier4: Warpbuild with the standard actions/cache@v4: currently the outlier at 550s total.

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:

• 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