Easing CI Load on GitHub Enterprise Server

CI runners are often the heaviest users of a Git server. Whether they're building every merge, every pull request, or every commit, the result is a steady stream of clones and fetches. On a large enough runner farm, that traffic can noticeably slow down Git operations for regular developers. Geography makes the problem worse: a CI fleet in Europe pulling from a primary server in North America forces every runner to drag every change across a slow, expensive connection. A better pattern is to have one machine pull the data once and serve it locally to the fleet.

Git traffic is not well-suited to classic CDNs, and geo-replicas can add latency to developer pushes. For large organizations that need local read performance without touching the write path, GitHub has introduced the GitHub Enterprise Server repository cache, now in public beta.

How the Cache Works

The repository cache is an eventually-consistent replica of your Git data, kept fresh by a background job. Because it doesn't participate in the initial receipt of Git data, pushes to the primary are unaffected. This gives you the data locality benefits of geo-replication without its push-path overhead.

The cache is also selective. Replication policies let you decide exactly which repositories are copied to which caches. This addresses a requirement some enterprise customers have for strict data residency: certain repositories can be designated to replicate only to specific locations, while others remain confined to their home instance.

Tradeoffs to Know

Repository caches are strictly read-only, so all writes must go to the primary. GitHub recommends that only CI farms point at the cache and that developers continue to use the primary. The existing strategies for speeding up large-monorepo developer workflows remain compatible when CI traffic is offloaded this way.

One operational caveat: it can take up to several minutes for new Git data to reach the cache. Clients that expect a commit that hasn't arrived yet need a backoff-and-retry strategy.

Beta Status and Known Issues

The feature started in beta with GHES 3.3 and saw improvements in GHES 3.4. The current release has a few known limitations worth reviewing before adoption:

  • LFS files are not replicated. Instead, LFS acts as a proxy and will stream the content from the primary instance. If you make heavy use of LFS, then you may not reap much benefit from the cache server in its current state. LFS caching will be implemented in a future release of the cache server.
  • Repositories which aren’t allowed by replication policy may still be streamed through the cache server. It’s important to note that the cache server is not an authorization boundary. If a user with access to a repository attempts to access it through a cache server, the cache server will proxy the data, but will not store the data. This behavior will be changed in a future release of the cache server.

For teams that can live with those constraints, the repository cache is worth a trial. Setup instructions are in the official documentation.