GitHub outlines Git infrastructure rebuild for agent-heavy workloads

GitHub is rebuilding its Git infrastructure to support increasingly concurrent activity from developers and software agents. In an engineering post published October 6, 2026, the company described a design that separates durable repository storage from the compute capacity serving Git requests.

The goal is to break a scaling tradeoff: adding capacity for reads should not also make writes more expensive.

Why more replicas can slow pushes

GitHub says its current Spokes system stores complete repositories on the local disks of several fileservers—five by default. Those copies provide both durability and read capacity. But every replica participates in every write, so adding replicas to handle fetch traffic also increases the burden on pushes. According to GitHub, a push is only as fast as the slowest replica in its set.

In the architecture under development, authoritative repository data would live in Azure Blob Storage. Lightweight compute workers would cache data and serve requests, allowing read capacity to grow without adding another durable repository replica to the write path.

Separate maintenance workers would handle compaction and garbage collection against durable storage, moving that work off the hosts answering live Git requests. These are elements of the planned architecture, not claims that every repository already uses it.

The critical path still matters

GitHub also plans to narrow coordination during a push to the reference update itself. Much of the work involved in storing objects, validating object connectivity and scanning for secrets could proceed in parallel with other writes.

The engineering distinction is between increasing read capacity and eliminating write contention. Independent cache workers are intended to absorb traffic such as CI fan-out without increasing the replication burden on every push. Reference updates would still require agreement, however. Separating storage from compute should not be read as a promise of contention-free updates to a shared branch.

Work underway, with benchmark limits

GitHub describes the rebuild as work underway and says it is already putting the foundation in place. The company reports up to 35× higher write throughput in internal benchmarks. That is a vendor-reported test result, not a production-wide performance guarantee or a result teams should assume applies to their repositories.

GitHub says the redesign must preserve existing workflows, including branching, review, merge and history, along with controls such as branch protections and required reviews. For engineering teams, the announcement signals a backend scaling effort designed around existing workflows—not a required workflow migration or a guaranteed performance improvement already available to them.