Overview
How Shipfox accelerates your CI pipelines with colocated caching for GitHub Actions and popular build tools
Slow CI pipelines often come down to one thing: cache latency. Whether you're restoring node_modules, replaying Turborepo tasks, or reusing compiled Rust artifacts, a cache that is far from your runner adds seconds on every read and write.
Shipfox ships a built-in caching layer, colocated with your runners. Because the cache lives in the same data center as the job that uses it, reads and writes are near-instant. There is nothing to provision and no configuration required to get started.
Two layers of caching
Shipfox provides caching at two levels, both active by default.
GitHub Actions cache
Shipfox intercepts calls to the actions/cache API and redirects them to local storage instead of GitHub's remote Azure Blob Storage. Any workflow that already uses actions/cache or cache-enabled actions (e.g. actions/setup-node, actions/setup-python) immediately benefits, with no changes to workflow files.
Key differences from GitHub-hosted cache:
| GitHub | Shipfox | |
|---|---|---|
| Storage limit | 10 GB per repository | Unlimited |
| Location | Azure Blob Storage (remote) | Colocated with your runner |
| Throughput | Variable, often slow | Up to 4× faster |
| Configuration | None | None |
Learn more about GitHub Actions caching
Build tool caches
On top of the GitHub Actions cache, Shipfox exposes dedicated remote cache endpoints for build tools that have their own caching protocols. These caches store task outputs and compiled artifacts so that unchanged work is never repeated across runs.
Supported tools:
| Tool | What is cached | Protocol |
|---|---|---|
| Turborepo | Task outputs in JS/TS monorepos | Turborepo Remote Cache API |
| Nx | Task outputs in JS/TS monorepos | Nx Cloud-compatible API |
| Gradle | Build and test outputs | Gradle Build Cache |
| sccache | Rust and C/C++ compilation artifacts | WebDAV |
| Bazel | Build and test action outputs | WebDAV |
| Nix | Nix derivation outputs | Nix binary cache (HTTP) |
Each tool is configured automatically. The relevant environment variables or config files are set before your job starts, so your existing workflow steps work without modification.
Automatic caching is enabled by default for all supported tools. You can disable individual tools from Organization Settings in the Shipfox dashboard.
Why colocation matters
When a runner and its cache share the same physical network, there is no roundtrip to a remote region. Large caches that would take tens of seconds to restore from Azure or S3 are available in under a second. The benefit compounds across parallel jobs: every job in a matrix gets the same fast access simultaneously.
This is the same principle behind placing runners close to your cloud workloads. Shipfox applies it to the cache layer as well.
Managing your cache
The Shipfox dashboard provides a cache management interface where you can inspect what is stored, remove entries that are stale or corrupted, and download entries to reproduce a cache hit locally.