iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
GitHub is rebuilding its Git infrastructure to handle more simultaneous pushes, reads, and maintenance work without tying read capacity to extra durable repository copies. Its announced design puts authoritative repository data in Azure Blob Storage and uses lightweight compute workers to serve Git requests. The rebuild is underway; GitHub has not announced a completion date. The change is intended to improve scaling, reliability, and recovery—not a response to a reported reliability failure.
Why GitHub says it needs a different architecture
GitHub connects the redesign to rising Git activity and agentic software development. Coding agents may commit or checkpoint after many individual actions, adding writes alongside reads from CI, code scanning, the web interface, and API clients.
In its October 2026 announcement, GitHub said monthly pushes had increased from 0.69 billion to 3.35 billion. Pull request merges had reached nearly four times their year-earlier volume. It also reported 7.38 billion commits in September, more than five times the year-earlier level; 3.26 billion GitHub Actions runs in September, more than four times the year-earlier level; and total Git activity rising from 218.2 billion events per month in September 2025 to 473.3 billion in August 2026. The post does not specify the year for its September Actions and commits figures.
GitHub also said its busiest repository received roughly one billion requests in August 2026. These figures describe the scale and concurrency pressures the company cites; they do not by themselves establish that customers experienced a reliability incident. GitHub’s architecture announcement describes the motivation and the proposed changes.
#1 Best Overall
How Spokes works today—and where GitHub sees a limit
GitHub says its existing Spokes system keeps a full copy of each repository on local disks across several fileservers, with five as the default. The local disks support low-latency Git operations, while the multiple copies provide redundancy and let fileservers share read traffic.
For reference updates—the changes that move branch or tag references—GitHub describes a three-phase commit protocol using a quorum. That coordination helps CI, the web interface, and API clients see a consistent repository state. The trade-off is that the same replicas provide both durable storage and read capacity, and every replica participates in every write. GitHub says a push therefore takes as long as its slowest replica in the set; adding replicas to handle more reads can add write overhead, and writes stop if the system loses quorum.
What changes in the announced design
GitHub’s proposal separates durable storage from the compute that handles Git requests. Rather than making each serving worker another full durable replica, the design places authoritative repository data in Azure Blob Storage and uses lightweight workers that cache data as they serve requests.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Architecture question | Existing Spokes system | Announced design |
|---|---|---|
| Where repository data lives | Full repository copies on local disks across fileservers; five fileservers is GitHub’s stated default. | Azure Blob Storage is the authoritative repository-data layer; serving workers cache data. |
| How read capacity grows | Reads are spread across durable full-repository replicas. | GitHub says it can add cache-serving compute without adding another durable copy to every push. |
| How writes coordinate | A three-phase commit protocol uses a quorum for reference updates; GitHub says every replica participates in each write. | The reference update still needs agreement, while object storage, connectivity validation, and secret scanning can mostly proceed in parallel with other writes. |
| When a serving worker fails | The announcement does not describe worker replacement or cache recovery for the existing design. | A replacement worker can serve requests and repopulate its cache from durable storage rather than first rebuilding a full repository copy. |
| Where heavy maintenance runs | Maintenance can run on hosts that also serve live Git requests. | Separate workers handle compaction and garbage collection against durable storage. |
| How capacity responds to bursts | Adding read capacity means adding durable replicas, which also take part in writes. | GitHub says it can add workers during activity bursts and remove them afterward. |
What the redesign changes about pushes and maintenance
Less work on the coordinated part of a push
GitHub says a push still needs agreement for its reference update, but several other tasks need not hold up that coordination. Storing objects, checking object connectivity, and scanning for secrets can mostly happen in parallel with other writes. The goal is to preserve the coordination needed for correctness while shortening the push’s critical path—not to eliminate consistency checks or agreement altogether. As Brian Celenza, a principal software engineer working on GitHub storage and core services, put it: “The part of a push that truly needs agreement is the reference update itself.”
Maintenance away from request-serving hosts
Compaction and garbage collection can consume substantial resources. GitHub plans to move that work to separate workers operating against durable storage, instead of having the same hosts both perform maintenance and answer live Git requests.
Compute that can be replaced or scaled independently
With repository data held in the durable storage layer, GitHub says it can add serving workers for a burst and remove them later. If a worker fails, its replacement can begin serving requests while rebuilding its cache from durable storage, rather than waiting to reconstruct a full repository copy first.
What GitHub’s performance figure does—and does not—show
GitHub reports up to 35 times higher write throughput in internal benchmarks. The announcement does not describe the benchmark workload or methodology, and the figure is not an independent measurement or a guarantee that every repository or customer workload will see that improvement. It should be read as GitHub’s reported best-case benchmark result, not as a production-wide performance promise.
What developers should expect during the rebuild
GitHub describes the rebuild as underway while the service continues to operate. It says the work will not require a maintenance window that stops code movement or changes to customer development workflows. The announcement does not give a completion date, detailed customer rollout schedule, or region-by-region availability, so it should be understood as an active infrastructure transition rather than a completed migration.
GitHub says it intends to preserve familiar development workflows and controls as the infrastructure evolves, including branching, reviews, merges, history, branch protections, required reviews, audit logs, and repository visibility. These are stated intentions for the redesign, not a claim that the migration is already complete.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
