GitHub Actions cache

Caching is critical for fast CI pipelines. Whether you're restoring dependencies or build artifacts, a slow or unreliable cache can cancel out your runner’s performance gains.

Shipfox solves this with a built-in, high-speed caching layer that’s colocated with your runners and fully compatible with GitHub’s native caching workflows.

How it works

Shipfox intercepts actions/cache and other GitHub-native caching calls at the network level and redirects them to our local caching infrastructure, no configuration changes required.

• 4× faster cache throughput compared to GitHub-hosted runners
• Unlimited cache size, store as much as your workflows need
• Colocated storage, cache is served from the same data center as your runner
• Automatic integration, no need to change how you use actions/cache
• Just works, you keep using GitHub Actions the same way, only faster

Why it's better than GitHub-hosted cache

GitHub imposes a hard 10 GB limit per repository for cached data. On large projects, or when building big artifacts, this can cause caches to be evicted prematurely or skipped entirely, hurting CI performance.

Shipfox has no such limits. You get unlimited cache storage, colocated with your runners, and full control over cache keys, scope, and usage. Your CI jobs stay fast and consistent, even as your project scales.

GitHub-hosted cache is stored on remote Azure Blob Storage, which introduces latency and regional inconsistency. When the runner and the cache are not in the same availability zone, downloads can be slow or fail entirely.

With Shipfox, cache is always nearby, ensuring high-speed access and reliable performance across jobs.

Benefits

• Faster builds: Restore and save large caches in seconds
• Zero cold start: Cache is available instantly across all jobs
• No limits: Store language package caches, build outputs, or custom directories
• Fully managed: No maintenance or storage cleanup needed