GitHub’s Agent-Scale Git Infrastructure Explained

A gradual migration follows the traffic

The first copy of a repository landed in Azure Central US in August 2025. GitHub says most repositories now have two of their five replicas in Azure, and Azure handles about half of Git traffic. The migration is gradual: for a while, Azure takes on growth while GitHub's own data centers stay comparatively steady.

One reason this is workable is that requests can follow replicas. Most repositories have five replicas for durability, availability, and scale. Spokes - GitHub's storage system - uses preferential routing to send requests to a replica in the same region and availability zone when possible. As more replicas move to Azure, more requests can land there. Once the last replica moves, the old region no longer needs to receive requests for that repository.

This matters operationally because it's not a one-time cutover. Data placement changes in steps, and traffic shifts as the destination becomes capable of handling it. In other words, the system doesn't rely on a single risky "all at once" move.

Why the busiest repositories are different

GitHub says it has moved a copy of 99.99999% of its repositories to Azure. The small remainder includes some of its busiest repositories. The issue there isn't just copying data. It's what distance does to serialized writes.

A replica in the target Azure region can be around 1,000 miles from GitHub's data centers. A network round trip might take about 25 milliseconds, and writes may require multiple round trips. That delay is manageable for many repositories. It becomes painful for repositories that are already close to their write-throughput limit.

In the current setup, the slowest healthy replica can effectively set the pace for when writes complete. Because writes hold a repository-wide lock while they commit, cross-region latency can reduce how fast that repository can accept updates. If pushes arrive faster than the system can finish them, they queue. That's why GitHub needs an architectural change, not just more time or faster data transfer.

From one queue to independent work

In GitHub's current model, the quorum needs a majority to commit a write, but it waits for every healthy replica to respond - up to a timeout - before it moves on. When the system holds a repository-wide lock during the update, one slow write can block other writes even if they target different branches.

That's the queueing problem. Each write takes as long as the slowest healthy replica. As the arrival rate rises, the queue grows and later writes wait longer. Cross-region latency increases the time each write ties up the serialized path, which effectively lowers the repository's throughput ceiling.

Per-reference serialization changes what needs to wait. Writes to the same reference still must be ordered, but writes to separate references can be in flight at the same time. This doesn't remove latency from a single write, but it reduces how often unrelated writes get blocked behind it.

A useful mental model is the coordination boundary:

• Repository-wide serialization: all writes compete for one lock and one ordered queue.
• Per-reference serialization: writes to the same reference are ordered; independent references can progress at the same time.

This isn't a promise of infinite write capacity. If the workload hammers one "hot" reference repeatedly, contention still shows up there. The benefit depends on how much of the write traffic can actually be done independently.

What the tests indicate

GitHub says that in internal testing with realistic traffic, writes to different references reached roughly three to four times higher throughput at lower latency. The company also says the new approach raises a repository's write-throughput ceiling roughly in proportion to the number of references being written at once.

That tracks the bottleneck they're targeting: serialized coordination, not raw ability to move Git objects. It also makes branch-heavy workloads - like many agents or developers working on separate branches - fit cross-region replication better.

There's a trade-off, though: more protocol and state-management complexity. The system has to preserve ordering when references conflict, while letting independent updates go forward. It's a better match for how Git works, but it still needs careful handling of failures, retries, and replica health. Cutting coordination only helps if what remains is correct.

The virtual write replica

GitHub calls the object-storage quorum member a virtual replica. It's an ephemeral compute node that sits in the write path to object storage. This node streams incoming writes and doesn't serve reads. Because it participates in the quorum, a write isn't acknowledged until the data is durable in object storage.

That durability requirement adds latency to writes. The design tries to avoid turning that into a new throughput bottleneck by batching work. The virtual write replica can coalesce transactions that touch disjoint references into fewer network I/O operations to object storage. Instead of paying one object-storage round trip per concurrent write, a busy repository can share a round trip across multiple writes.

For now, the virtual write replica also handles compaction, and read replicas pick up the compacted state. Separating read and write capacity doesn't eliminate background work like compaction - it changes where it happens and how it intersects with serving traffic.

On-demand virtual read replicas

Once object storage is the source of truth, GitHub can add virtual read replicas without making them members of the write quorum. Each can warm its cache from Azure Blob Storage, then serve read traffic while reconciling local state in the background.

This gives the system a clearer division of roles:

• The write quorum controls when updates become durable.
• Object storage holds the durable repository data.
• Virtual read replicas provide compute and cache capacity for reads.

The practical payoff is independent scaling. If a repository needs more read capacity, the system can add read replicas without requiring every component to join write coordination. Those replicas can also be tuned for read workloads - rather than sharing resources needed for compaction and writes.

GitHub says its distributed load-testing setup hit limits in the current architecture. When it tested virtual read replicas, the test harness reached its own limits first. That's encouraging, but it's not the same as proving every production workload is fully solved. GitHub also notes that virtual replicas bring challenges it addresses in later steps of the design.

The remaining write bottleneck

Per-reference serialization and virtual replicas create more room to grow, but GitHub still calls write throughput the next limit. Writes still wait on replicas that hold full copies of a repository. The difference is that, because Git objects are immutable and content-addressed, only a small portion of a write needs system-wide ordering.

The real engineering challenge is how to order that smaller portion quickly without simply moving the bottleneck somewhere else. That includes second-order effects - like where durable reference state lives, and how compaction and garbage collection scale as the system evolves.

This is why a "clean" diagram isn't enough. The protocol has to work under a service that handles repositories at enormous scale, with developers and agents changing things around the clock. It also has to be operational: failures need diagnosis, data needs repair, and capacity needs rebalancing without interrupting core Git operations.

The practical lesson for infrastructure teams

The broader takeaway isn't just "move storage to the cloud" or "use object storage." The decision sequence is more specific:

1. Separate migration risk from architecture risk. GitHub moved data before changing the storage design, avoiding a simultaneous platform switch and protocol overhaul.
2. Find the real coordination boundary. If unrelated updates are serialized together, the bottleneck might be the boundary, not the hardware.
3. Scale by workload. Reads and writes need different resources. Decoupling them can be more efficient as long as durability and consistency stay explicit.
4. Measure the next constraint. Each improvement tends to reveal what's limiting next. Adding more read replicas doesn't automatically fix write coordination, compaction, or garbage collection.

These ideas aren't unique to Git. They show up when a large shared data structure, a global lock, or a synchronous quorum forces independent operations to wait on each other. The "right" answer depends on the consistency guarantees your product actually needs. Removing coordination that protects correctness is a bug. Removing coordination that doesn't protect correctness can be a real scaling win.