Over the past year, GitHub has been engaged in a massive, high-stakes infrastructure migration, shifting the vast majority of its repository data from its private data centers into the cloud via Microsoft Azure. As Git traffic continues to grow at an exponential rate, fueled by the rise of AI-driven agentic development, the platform has successfully moved 99.99999% of its repositories. This transition represents a critical milestone in GitHub’s long-term strategy to ensure that its architecture can support not only today’s developer demand but also the increasingly autonomous and high-velocity nature of future coding workflows.
The scale of this migration is difficult to overstate. GitHub’s repositories are a Tier 0 service—the foundational bedrock upon which the entire platform, and the daily work of millions of developers, rests. Because nearly every feature on GitHub depends on repository data, the migration had to be executed with surgical precision. The first repository replica arrived in Azure’s Central US region in August 2025. Today, most repositories on the platform maintain two of their five replicas in Azure, with the cloud infrastructure currently handling roughly half of all Git traffic.
For the most part, Azure has successfully absorbed the platform’s recent growth, allowing GitHub’s own data centers to remain stable. However, the migration is far from finished. The remaining 0.00001% of repositories—which happen to be among the busiest and most resource-intensive on the entire platform—have presented a unique set of challenges that require a fundamental rethink of how GitHub handles data synchronization and consistency.
The Bottleneck of Global Latency
The primary obstacle facing these high-traffic repositories is the physical reality of network latency. In GitHub’s current architecture, a repository spread across multiple geographic regions encounters a "hard ceiling" regarding write throughput. When a repository is hosted in both a local data center and an Azure region 1,000 miles away, every write operation must traverse that distance.
The current system, known as "Spokes," relies on a quorum-based model to ensure data integrity. To commit a write, the system requires a majority of replicas to agree, but it also waits for every healthy replica to respond before completing the transaction. If a replica is slow, the entire operation is delayed. Because each write holds a repository-wide lock until it commits, this latency creates a ripple effect: the slowest healthy replica effectively dictates the write latency for the entire repository, and consequently, sets a hard limit on its throughput.
When a replica is moved to an Azure data center 1,000 miles away, a 25ms round trip becomes the standard for every write. For a repository already operating near its capacity, this added latency is insurmountable. The queue of pending writes would simply grow indefinitely, causing the repository to fall further behind with every push. To solve this, GitHub is implementing a shift from repository-wide coordination to per-reference serialization.
Shifting to Per-Reference Quorums
The core philosophy behind GitHub’s new architectural approach is the minimization of coordination. The team identified that Git’s consistency requirements, while strict, apply to each "reference"—such as an individual branch or tag—rather than the repository as a whole. While a push to a specific branch must ensure that no client sees an older value after the update is accepted, updates to different references generally do not depend on one another.
By changing the scope of the quorum from the entire repository to individual references, GitHub is effectively dismantling a significant bottleneck. Under the old system, holding a repository-wide lock for the duration of a write turned the quorum into a single, unordered queue. Only one write could be in flight at a time, and every write had to wait for the slowest replica.
With per-reference serialization, only writes that compete for the same specific reference are required to wait for each other. Because the vast majority of activity on GitHub involves agents and developers working on separate branches, this change allows multiple writes to be in flight simultaneously. Each individual write still experiences the cross-region latency, but because they are no longer queued behind every other unrelated operation in the repository, the throughput ceiling is significantly raised. Internal testing has shown that this approach consistently delivers three to four times higher throughput at lower latency, providing the necessary headroom to bring the final, busiest repositories into the Azure environment.
Scaling Reads Independently
While write throughput is the immediate concern for migration, GitHub is also addressing the inherent limitations of coupling storage and compute. Most repositories on the platform are heavily read-skewed, often seeing hundreds or thousands of reads for every single write. Currently, both read and write traffic compete for the same resources on the same replicas, making it impossible to scale them independently.
To break this coupling, GitHub is introducing the concept of a "virtual replica." This involves making object storage—specifically Azure Blob Storage—a member of the quorum. The virtual replica acts as an ephemeral node that streams incoming writes to object storage without serving any read traffic. A write is not considered acknowledged until it is durably stored in the cloud. While this adds a marginal amount of latency, the efficiency gained through per-reference serialization ensures it does not become a new throughput bottleneck.
Furthermore, this setup allows GitHub to scale virtual read replicas on demand. Because these read replicas do not need to join the quorum—instead using the object storage as the single source of truth and reconciling their local state in the background—they can be spun up to handle spikes in traffic without impacting the write performance of the repository. This architecture also allows for the decoupling of memory configurations; read replicas can be optimized with larger in-memory caches, while write-heavy nodes can focus their resources on compaction and transaction management.
Looking Toward the Future
The Spokes service has served as the backbone of GitHub for years, evolving from a simple quorum coordinator into a complex ecosystem that manages load balancing, routing, API transactions, and automated repository maintenance. While this infrastructure has powered the growth of a billion repositories, the GitHub engineering team acknowledges that the current commit protocol will eventually face new limits.
The next frontier for the platform is the further optimization of write throughput. GitHub is investigating ways to move beyond the current model, where every write still waits on replicas that hold full copies of the repository. Because Git objects are immutable and identified by their contents, the team is exploring ways to store data without requiring full consensus on every single piece of information, reserving the heavy lifting of coordination for only the most essential operations.
Designing these systems is an abstract challenge on a whiteboard, but implementing them beneath the weight of a billion repositories that are constantly being written to by developers and AI agents alike is an immense engineering feat. The ongoing migration and the transition to this new architectural model are designed to provide that necessary headroom, ensuring the platform remains resilient as agentic traffic continues to climb.
As GitHub prepares for the final stages of this infrastructure overhaul, the focus remains on solving the second-order effects of this shift—such as how to manage durable reference states and how to optimize garbage collection and compaction at a global scale. With the end-state architecture in sight, the platform is not just moving data to the cloud; it is rebuilding the very foundation of how the world’s code is stored, accessed, and managed. Further details on the final architecture, including how it addresses remaining consensus challenges and scales write throughput, are expected to be shared in the coming week at GitHub Universe.
