GitHub Rebuilds Git Infrastructure for Agent-Scale Development
The redesign separates durable repository storage from compute as GitHub reports sharp growth in commits, pushes and CI activity linked to concurrent developer and agent work.
Edited by Tyronne Panaino
GitHub said on October 6, in an engineering article updated October 7, that it is rebuilding the infrastructure behind Git repositories for heavier concurrent work by developers and coding agents. The program separates durable repository storage from the compute workers that serve reads and writes, with the aim of scaling each layer independently.
The change matters most to organizations running busy continuous-integration pipelines, merge queues and multiple agents against one codebase. GitHub presents the redesign as infrastructure work already underway, but the announcement does not give a completion date, a rollout percentage or a customer availability milestone.
Why writes became the constraint
GitHub reports that total Git activity rose from 218.2 billion events per month in September 2025 to 473.3 billion in August 2026. It also says developers and agents made 7.38 billion commits in September 2026, more than five times the volume a year earlier. These are GitHub's own platform measurements and were not independently audited in the evidence reviewed for this article.
The company describes a sharper increase on write-heavy paths. Monthly pushes rose from 0.69 billion to 3.35 billion year over year, while pull-request merges approached four times their previous volume. GitHub Actions ran 3.26 billion times in September, more than four times the year-earlier figure. Each push can trigger further reads from continuous integration and code scanning, so higher write activity also expands the load placed on repository-serving systems.
GitHub says its current Spokes system stores a full repository copy on several fileservers, with five copies by default. A three-phase commit protocol uses a quorum when a reference changes so the web interface, APIs and CI observe a consistent repository state. That design couples durability and read capacity: adding a replica to serve more reads also adds another participant to every write, making the slowest replica part of the push path.
What GitHub says it is changing
The new design narrows the coordinated portion of a push to the reference update. GitHub says object storage, connectivity validation and secret scanning can then proceed in parallel with other writes. It also plans to move compaction and garbage collection off the request-serving path to separate workers operating against durable storage.
The larger architectural shift is to decouple storage from compute. GitHub says the authoritative repository data will live in Azure Blob Storage, while lighter compute workers cache data and answer requests. Read capacity can therefore expand without creating another durable copy that participates in writes. If a compute worker fails, the intended recovery path is closer to replacing a cache: a new worker can begin serving and refill from the durable layer as traffic arrives.
That separation also lets GitHub add or remove compute capacity as demand changes. A repository experiencing a release burst or a large agent workload could receive more serving capacity without permanently provisioning for the peak. The source presents this as a design goal rather than evidence that every repository is already using the new architecture.
The performance claim needs production evidence
GitHub reports that internal benchmarks delivered up to 35 times higher write throughput and independently scalable read capacity. The upper-bound wording is important. The announcement does not publish the benchmark workload, latency distribution, repository mix, hardware configuration or comparison baseline, and it provides no independent reproduction.
The source also does not quantify how much production traffic has moved, whether all repository features behave identically on the new path or how failure recovery performs under customer workloads. The supported conclusion is therefore narrower than the benchmark headline: GitHub has described an active infrastructure rebuild and the principles behind it, while broad production performance remains to be demonstrated.
What affected teams should watch
For engineering leaders, the next verifiable checkpoints are a documented rollout stage, production latency and reliability data, and evidence that branch protection, required reviews, audit logs and repository visibility retain their behavior under the new architecture. GitHub says those existing controls remain design requirements, but this first article does not provide a migration schedule or independent operational results.
For maintainers and individual developers, no workflow change is announced. GitHub says the platform will continue supporting familiar branching, review, merge and history workflows while it changes the infrastructure underneath them. That makes the immediate story an architecture commitment rather than a new setting or feature that users can enable.
Status
Confirmed. GitHub has disclosed the redesign, its current architecture and its intended storage-and-compute separation. Internal confidence is medium because one actor-controlled source supplies all workload figures, benchmark results and implementation claims.
Sources
Update note: Last reviewed 2026-10-08. We will revise this post when GitHub publishes a rollout milestone, production evidence or a deeper architecture follow-up.
Sources
Drafted with AI assistance from source briefs; reviewed for citation completeness and label accuracy.