Over the past year, GitHub has navigated a period of unprecedented growth, marked by a surge in Git traffic driven largely by the rise of agentic development. In a massive operational undertaking, 99.99999% of the repositories hosted on the platform now live in two locations simultaneously: GitHub’s own internal data centers and Microsoft Azure. This migration represents a fundamental shift in how the platform manages its most critical assets. However, the remaining fraction of repositories—the busiest and most active on the service—have presented a unique challenge. These high-traffic repositories have been constrained by the physical reality of network latency, specifically the 25ms round trip required for inter-region communication. To overcome this, GitHub is introducing a new approach to per-reference quorums and object storage, effectively decoupling read and write operations to scale independently.
The Motivation Behind the Migration
The timing and scale of this move were dictated by a combination of factors. As traffic grew exponentially, GitHub faced a hard ceiling on the power capacity of its physical data centers and the surrounding geographical regions. Furthermore, global physical supply chain constraints meant that while there was enough capacity to migrate safely, there was not enough runway to do so slowly.
For a Tier 0 service like GitHub, where repository data is the bedrock of nearly every other function, the migration had to be handled with extreme precision. The team decided to prioritize data movement above all else. By moving the data first, they could ensure that the underlying infrastructure was in place before attempting to evolve the architectural design. The first repository replica arrived in Azure’s Central US region in August 2025. Today, approximately half of all Git traffic is served by Azure, with most repositories maintaining five replicas to ensure durability and availability.
The migration follows a structured path: Spokes, GitHub’s internal routing and load-balancing layer, uses preferential routing to direct traffic to a replica in the same region and availability zone as the request. As replicas are migrated to Azure, the share of traffic served by the cloud increases proportionally, until the last replica arrives and the legacy region is decommissioned.
Tackling the Final 0.00001%
The most challenging repositories are those that operate at the edge of performance limits. In the current architecture, a repository spread across multiple regions experiences a lower write throughput ceiling. The Spokes quorum, which governs how writes are committed, requires a majority to succeed but typically waits for every healthy replica to respond. This means the slowest replica dictates the latency of every write. Because each write holds a repository-wide lock until it is committed, the slowest link in the chain effectively becomes the throughput bottleneck for the entire repository.
Once a replica is moved to an Azure region, it may be situated 1,000 miles away from the primary data center, introducing a 25ms round-trip delay. For a repository already operating at peak throughput, this added latency per write would be catastrophic, causing it to fall behind with every push.
To solve this, GitHub is pivoting toward a strategy of minimizing coordination. The engineering team recognized that Git’s consistency requirements do not necessarily need to be enforced at the repository level. Instead, they apply to each reference—such as a branch or tag—individually. By shifting the scope of the quorum from the entire repository to individual references, the platform can eliminate the need for global locks.
Under the new model, only writes that contend on the same reference are required to wait for one another. Since the vast majority of writes to a repository—such as individual developers or automated agents pushing to their own unique branches—target different references, they can now proceed concurrently. This change effectively removes the primary bottleneck, allowing writes to proceed without waiting for unrelated traffic to clear. Internal testing has demonstrated that this per-reference serialization can yield a 3x to 4x increase in write throughput while simultaneously reducing latency.
Scaling Reads Independently Through Object Storage
The challenge of scaling is compounded by the fact that most repositories are heavily read-skewed, often experiencing 100 to 1,000 reads for every single write. Currently, both reads and writes compete for the same resources on the same replicas, preventing independent scaling. By decoupling storage from compute, GitHub aims to change this dynamic entirely.
Once data is durably stored in Azure Blob Storage, it becomes possible to separate read traffic from the write quorum. The first phase of this evolution involves introducing a "virtual replica" into the quorum. This compute node is fully ephemeral and acts as a bridge to object storage, streaming incoming writes without serving read traffic itself. A write is not acknowledged until it is confirmed to be durable within the object storage layer.
While this adds a small amount of latency to each write, the per-reference serialization mentioned earlier ensures that this does not become a new bottleneck. Furthermore, the virtual write replica is designed to coalesce transactions on disjoint references into a single set of network I/O operations, meaning that a busy repository pays the cost of a single round trip for multiple concurrent writes rather than one per individual operation.
Once the virtual write replica is established, GitHub can scale out an unlimited number of virtual read replicas on demand. These replicas warm their caches directly from Azure Blob Storage and begin serving read traffic without needing to participate in the quorum. They treat object storage as the ultimate source of truth, reconciling their local state in the background. This approach unlocks massive read scalability, as the system can now scale read compute resources independently of the write-heavy quorum processes.
Looking Toward the Future of Infrastructure
The current infrastructure is built upon the foundation of the Spokes system, which has evolved far beyond a simple quorum coordinator. Today, Spokes serves as an intelligent routing layer, a unified API for over 100 billion daily operations, and a robust management system that handles repository placement, repair, and rebalancing. While the majority of this logic remains relevant to the new cloud-native architecture, the team acknowledges that the commit protocol that supported the first billion repositories will need further refinement for the next billion.
The next major hurdle is further increasing write throughput. While the platform has made significant strides, every write still contends with replicas holding full copies of the repository. However, because Git objects are immutable and identified by their contents, the team sees a path toward storing them without requiring global consensus on every detail. The objective is to order only the necessary components as quickly as possible without creating new bottlenecks elsewhere in the stack.
The complexity of designing these systems is magnified by the scale of the environment; they are being rebuilt while supporting millions of developers and agents performing operations around the clock. The engineering team is already looking ahead to the second-order effects, such as how durable reference state is managed and how background processes like compaction and garbage collection will perform at this new scale.
As agent traffic continues to grow, these incremental improvements provide the necessary headroom for repositories to thrive. GitHub plans to provide a deeper look at the end state of this architecture, the specific problems solved by this transition, and the future role of consensus groups during the upcoming GitHub Universe event and in a forthcoming technical report. The transition represents not just a move to the cloud, but a fundamental reimagining of how large-scale, distributed Git infrastructure must function in an era of unprecedented development activity.
