Boosting Git Performance: Self-Hosted Runners and In-Network Caching

Optimizing continuous integration and delivery (CI/CD) pipelines is a critical aspect of achieving ambitious software engineering goals. For organizations leveraging self-hosted GitHub Actions runners, the ability to fine-tune every aspect of their build environment is paramount. A recent discussion on the GitHub Community highlights a significant challenge: enabling self-hosted runners to utilize an in-network cache for GitHub Actions, a feature that could drastically improve git performance, reduce egress costs, and bolster security.

Self-hosted GitHub Actions runner connected to an in-network cache for improved performance.
Self-hosted GitHub Actions runner connected to an in-network cache for improved performance.

The Challenge: Cache Egress and Runner Overrides

The core issue stems from how GitHub Actions runners handle the ACTIONS_RESULTS_URL environment variable. This variable, crucial for services like actions/cache, is automatically copied from the job message by the runner into every node and container action. Crucially, it overwrites any value an operator might have set on the runner process itself. This means that actions/cache (and BuildKit's type=gha cache) invariably points to GitHub's external cache data plane (*.blob.core.windows.net), forcing cache data to leave the local network.

For environments with strict security postures, such as those running untrusted fork pull requests with locked-down egress, this behavior renders actions/cache unusable. The inability to direct cache traffic to an in-network solution leads to increased egress costs, slower build times, and a security gap where sensitive data might traverse external networks unnecessarily.

Developer achieving high productivity with optimized CI/CD and fast git operations.
Developer achieving high productivity with optimized CI/CD and fast git operations.

Current Workarounds: Fragile and Unsustainable

Operators currently resort to precarious workarounds, none of which are officially supported or robust:

  • Forking the Runner: Some maintain custom runner forks, like falcondev-oss, that introduce custom environment variables (e.g., CUSTOM_ACTIONS_RESULTS_URL). This requires constant maintenance to track and merge every new runner release.
  • Binary Patching: Another method involves binary-patching Runner.Worker.dll to rename the ACTIONS_RESULTS_URL literal, effectively making the runner write a dummy variable. This is extremely fragile and breaks silently with any runner update.

Previous attempts to address this upstream (actions/runner#3411 and actions/runner#3906 for ACTIONS_CACHE_URL) were closed by a stale bot, underscoring the need for a new approach.

The Proposed Solution: Operator-Controlled Overrides

The community discussion proposes a straightforward solution: allow self-hosted runner operators to override ACTIONS_RESULTS_URL, ensuring the override is sourced exclusively from the runner process environment or configuration, never from the job itself. This prevents malicious job code from redirecting cache saves.

Several shapes for this override are suggested:

  1. A runner process environment variable, such as ACTIONS_RUNNER_RESULTS_URL_OVERRIDE, applied where the runner handlers set ACTIONS_RESULTS_URL.
  2. A narrower override specifically for the cache service, requiring the toolkit to read a separate cache URL.
  3. A config.sh flag that writes the override into the .runner configuration file, ensuring persistence.

Why This Matters for Developer Productivity

Implementing such an override would align with existing GitHub Actions policies, where cache access is already treated as a policy decision (e.g., ACTIONS_CACHE_MODE). It empowers operators to optimize their infrastructure, directly contributing to enhanced developer productivity and more efficient git performance.

The security boundary remains intact, as a properly configured in-network cache server can still verify the runtime token's signature and enforce GitHub's ref scoping. This proposal simply changes the endpoint for an honest client, offering significant benefits in terms of cost reduction (eliminating egress fees), faster build times (local network access), and improved security posture for sensitive CI/CD pipelines. This is a crucial step towards giving self-hosted runner operators the control they need to meet their specific software engineering goals effectively.

|

Dashboards, alerts, and review-ready summaries built on your GitHub activity.

 Install GitHub App to Start
Dashboard with engineering activity trends