Boosting Git Performance: Why Self-Hosted GitHub Actions Need 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.

The Hidden Cost of External Caching

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. Imagine the impact on git performance when every cache operation involves an external network hop, even for data that could reside just a few milliseconds away.

The Unstable Status Quo: Fragile Workarounds

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). While functional, this approach demands constant vigilance, requiring operators to track and merge every upstream runner release. Any change in the runner's internal logic can silently break these custom implementations, leading to unexpected build failures or performance regressions.
• Binary Patching: An even more extreme measure involves binary-patching Runner.Worker.dll to rename the ACTIONS_RESULTS_URL literal. This effectively tricks the runner into writing a dummy variable, allowing operator-set values to persist. This method is highly fragile, breaks silently with any runner update, and is a significant security risk, as it involves modifying core binaries.

These workarounds are not only resource-intensive to maintain but also introduce significant operational risk. They represent a technical debt that detracts from core development efforts and makes it harder to achieve strategic software engineering goals.

A Secure Path Forward: Operator-Owned Cache Configuration

The solution proposed in the GitHub discussion is elegant and aligns with best practices for self-hosted infrastructure: honour an operator-set override for ACTIONS_RESULTS_URL, read exclusively from the runner process environment or .runner configuration, never from anything the job controls. This critical distinction ensures the security boundary remains intact.

Suggested implementation shapes include:

1. Runner Process Environment Variable: A dedicated environment variable, such as ACTIONS_RUNNER_RESULTS_URL_OVERRIDE, would allow operators to explicitly define the cache service endpoint. This is applied at the runner process level, before any job message can interfere.
2. Narrower Cache-Specific Override: If GitHub prefers to keep artifacts and cache services distinct, a separate override specifically for cache services could be introduced. This would require the toolkit to read a separate cache URL.
3. config.sh Flag: Integrating the override into the config.sh script would write the setting into the .runner configuration file, ensuring persistence across runner restarts and maintaining consistency with other registration settings.

This approach maintains the security boundary because a hostile job cannot manipulate the cache endpoint. The cache server itself, if properly configured, would still verify the runtime token's signature and scope, applying GitHub's own ref scoping. The override simply changes where an honest client sends its requests, keeping the control firmly in the hands of the operator.

Beyond Performance: Strategic Advantages for Technical Leadership

Enabling in-network caching is more than just a performance tweak; it's a strategic enhancement for organizations focused on their software engineering goals:

• Significant Cost Reduction: Eliminating unnecessary egress traffic to external cache services can lead to substantial savings, especially for organizations with high build volumes and large cache footprints.
• Enhanced Security Posture: Keeping sensitive build artifacts and cache data within the local network reduces exposure to external threats and simplifies compliance with stringent data residency requirements. This is particularly vital for regulated industries or those handling proprietary code.
• Improved Developer Experience and Productivity: Faster build times directly translate to quicker feedback loops for developers, boosting morale and overall productivity. Reduced build times mean more iterations, faster deployments, and ultimately, accelerated delivery. This directly impacts git performance metrics and team efficiency.
• Operational Resilience: Relying on an in-network cache reduces dependency on external services, making CI/CD pipelines more resilient to internet connectivity issues or external service outages.
• Data-Driven Optimization: With an in-network cache, organizations can gain deeper insights into cache utilization and performance, enabling more precise optimization efforts. This can feed into valuable developer reports on build efficiency and resource allocation.

Empowering Your CI/CD Future

The proposed solution is a clear win for self-hosted GitHub Actions users. It addresses a critical pain point with a secure, operator-owned mechanism, moving beyond fragile workarounds to a stable, supported future. For dev teams, product managers, and CTOs, this means a direct path to improving git performance, reducing operational costs, and strengthening security without compromising the agility that GitHub Actions provides.

We encourage GitHub to prioritize this feature request. Providing official support for in-network caching will empower organizations to fully leverage self-hosted runners, driving greater efficiency and security across their software development lifecycle. The path to achieving ambitious software engineering goals is paved with such thoughtful tooling enhancements.