In a significant milestone for the world’s largest software development platform, GitHub has announced that 99.99999% of its Git repositories have successfully been migrated to Azure. This massive undertaking, which has spanned the past year, represents a fundamental shift in how the platform manages its global infrastructure. As Git traffic continues to grow exponentially—fueled largely by the rise of automated agents and AI-driven development—GitHub is moving to address the physical and logistical constraints of its own data centers by embracing cloud-native architecture.
While the vast majority of the platform’s data now resides in the cloud, the remaining 0.00001% of repositories represent some of the busiest and most complex projects on the platform. These repositories have presented a unique engineering challenge, held back by the constraints of legacy architectural patterns and the realities of network latency. To address this, GitHub is introducing a series of architectural refinements, including per-reference quorums and the decoupling of read and write traffic through virtualized storage, to ensure that no repository is left behind as the platform scales toward its next phase of growth.
How We Got Here: The Shift to Cloud Infrastructure
The decision to migrate to Azure was not merely a matter of convenience; it was a response to a rapidly changing digital landscape. GitHub’s leadership noted that the shift toward "agentic" development—where automated systems and AI agents interact with code repositories at an unprecedented scale—has triggered a surge in traffic. This growth collided with a hard ceiling on the power capacity of GitHub’s own physical data centers, alongside broader challenges in the global hardware supply chain.
Early in the migration process, the GitHub engineering team recognized that attempting to change the platform’s storage architecture and hosting environment simultaneously would introduce unacceptable levels of risk. Because Git operations are considered a Tier 0 service—the backbone upon which nearly every GitHub function depends—the migration had to be methodical. The strategy was to "move the data first, then evolve the architecture."
The first repository replica was successfully transitioned to Azure’s Central US region in August 2025. Today, the majority of repositories feature a five-replica distribution model, balancing the critical needs of durability, availability, and scale. Approximately half of all Git traffic is now served directly from Azure. To maintain performance, GitHub utilizes "Spokes," its proprietary infrastructure, to perform preferential routing. This system directs traffic to the nearest replica in the same geographic region and availability zone as the user, minimizing latency. As replicas move to the cloud, the share of traffic handled by Azure grows in tandem, until the last replica arrives and the legacy data center can be decommissioned for that specific repository.
Solving the Throughput Ceiling for the Busiest Repositories
The final fraction of repositories—those that have not yet moved to Azure—face a distinct challenge. In the current architecture, a repository hosted across multiple regions suffers from a lower write throughput ceiling. The Spokes quorum mechanism requires a majority to commit a write, but crucially, it waits for every healthy replica to respond. In a cross-region environment, a replica in an Azure data center can be up to 1,000 miles away from a GitHub data center, creating a 25ms round-trip latency.
When a write operation requires multiple round trips, the cumulative delay becomes a significant bottleneck. Furthermore, because each write currently holds a repository-wide lock until it commits, the slowest healthy replica effectively dictates the speed and throughput of the entire system. For the busiest repositories, this latency is unsustainable, causing them to fall behind with every push.
To overcome this, GitHub is pivoting to a principle of "minimizing coordination." The core of this strategy is the move from repository-wide serialization to per-reference serialization. Under the existing model, holding a repository-wide lock turns the quorum into a single, unordered request queue, where only one write can be in flight at any given moment. By changing the scope of the quorum to individual references, GitHub allows writes that do not contend on the same reference to proceed independently.
In practice, this means that while a developer or an automated agent pushes code to a specific branch, that operation no longer needs to wait for unrelated writes to other branches to complete. Each write still experiences the necessary cross-region latency, but because these operations can now occur in parallel, the single bottleneck is removed. Internal testing has demonstrated that this approach increases write throughput by three to four times while simultaneously reducing latency, providing the necessary "headroom" to bring even the most active repositories into the cloud environment.
Scaling Reads Independently Through Virtualization
Beyond solving write throughput issues, GitHub is also reimagining how it handles read traffic. Most repositories on the platform are heavily read-skewed, with as many as 1,000 reads occurring for every single write. In the current architecture, reads and writes compete for the same resources on the same replicas, preventing either from scaling independently.
To decouple these functions, GitHub is introducing the concept of a "virtual replica." By storing repository data durably in Azure Blob Storage, the platform can treat object storage as a member of the quorum. This virtual write replica serves as a bridge, streaming incoming writes to object storage and ensuring they are durable before acknowledging them. Importantly, this node serves no read traffic.
Once this virtual write replica is in place, GitHub can spin up as many virtual read replicas as a repository requires, on demand. These read replicas do not join the quorum; instead, they treat Azure Blob Storage as the "source of truth," warming their caches from the storage layer and reconciling local state in the background. This decoupling allows GitHub to optimize read and write compute independently. For instance, read replicas can be configured with larger in-memory caches, which were previously limited by the resource requirements of write-intensive compaction tasks.
Early testing of this distributed approach has shown that the platform’s load-testing harness, which previously identified ceilings in the old architecture, now hits its own performance limits before reaching the capacity of the virtual read replicas. This transition represents a major evolution in how the platform manages its underlying data, allowing for a much more elastic and resilient service.
The Road Ahead: Rethinking the Commit Protocol
While these advancements represent a massive step forward, the GitHub engineering team emphasizes that the work is far from finished. The Spokes system, which has been the cornerstone of GitHub’s infrastructure for years, has evolved into much more than a simple coordinator—it is now a sophisticated engine for intelligent routing, global load balancing, and automated repository maintenance.
However, the team acknowledges that the commit protocol that successfully scaled GitHub to a billion repositories will eventually need to be replaced to handle the next billion and beyond. The next frontier is further increasing write throughput. Currently, every write is still waiting on replicas that hold full copies of the repository, yet the reality is that very little of a write operation requires global consensus. Because Git objects are immutable and identified by their contents, there is significant potential to store them without requiring every replica to agree on the state of the entire repository simultaneously.
The challenge lies in designing a system that can order these operations at high velocity without moving the bottleneck elsewhere. As GitHub continues to grow, the team is focused on the "second-order effects" of these changes, such as how to effectively manage reference state, compaction, and garbage collection at an even larger scale.
With agent-based traffic showing no signs of slowing down, the migration and architectural updates serve as a vital preparation for the future. By moving repositories into the cloud and refining the quorum and storage models, GitHub is building a platform capable of handling the increasing intensity of modern software development. The next chapter in this infrastructure story, which will detail the final end-state of the architecture and the remaining consensus requirements, is set to be unveiled at GitHub Universe.
