Every single day, millions of developers log into GitHub to build the products that power modern society, contribute to the sprawling ecosystem of open-source software, and push the boundaries of their own personal projects. As the global hub for software development, GitHub has spent years steadily evolving its architecture to support this work, adapting to the shifting demands of the organizations and individual contributors who rely on it for their most critical assets. However, we are currently witnessing a seismic shift in how software is created: the rise of agentic software development.
With developers and autonomous agents now working concurrently within the same repositories—often generating millions of commits every single day—the traditional Git architecture is reaching its physical limits. To address this, GitHub has begun a major project to rebuild its core Git infrastructure. By designing a system specifically for this high-concurrency, agent-driven future, GitHub aims to provide a foundation that can handle the most ambitious workloads imaginable.
The Scale of Modern Development
To understand why this architectural overhaul is necessary, one must look at the data from the highest-volume repositories on the platform. The gap between a typical repository and the busiest ones is far wider than most observers might expect. By analyzing the monthly repository activity distribution from August 2026, it is clear that activity levels climb sharply at the far end of the spectrum. In that month alone, the single busiest repository on GitHub experienced roughly a billion individual requests, a figure that underscores the sheer volume of traffic the platform must manage.
This surge is not limited to just a handful of outlier repositories. Total Git activity on GitHub is growing at an exponential rate. Between September 2025 and August 2026, the volume of activity on the platform more than doubled, jumping from 218.2 billion events per month to 473.3 billion. Perhaps most tellingly, in September 2026 alone, developers and automated agents pushed a staggering 7.38 billion commits to the platform. To put that in perspective, that represents more than five times the volume of commits observed just one year prior.
These repositories at the very top of the growth curve provide a window into the future of agentic development. They are characterized by large, complex engineering teams running high-frequency continuous integration (CI) pipelines, all while coordinating with growing fleets of autonomous agents. Supporting these teams requires a shift in how GitHub thinks about its infrastructure, moving toward a design that prioritizes sustained, concurrent reads and writes at a scale that few repositories have ever encountered.
Beyond Fast Clones: The Challenge of Writes
For years, the industry has focused on optimizing for "fast clones"—the ability for a developer to pull down a repository quickly. While this is an essential part of the user experience, it only solves a fraction of the problem. Reads are, by their nature, relatively easy to scale; by adding caches and replicas, a provider can serve the same bytes to an increasing number of clients with minimal friction.
However, scaling writes is a significantly more complex challenge. Every push to a repository must be stored durably and rendered visible consistently before the next agent or CI job can build upon it. This requirement for durability and consistency is the primary obstacle to scaling for the agentic age.
Evolving the Spokes Architecture
The current architecture, which has successfully supported billions of repositories for years, relies on a system known as Spokes. Under this model, every repository is stored by keeping a full copy on the local disks of several fileservers—typically five by default. These fast, local disks allow Git operations to read native repository data with extremely low latency, while the redundant copies provide both safety and the ability to distribute read requests across multiple servers.
When a push updates a reference, the system employs a three-phase commit protocol using a quorum to ensure that the web UI, CI systems, and API clients all see a consistent state of the repository. While this pairing of storage and compute has served the industry well, the mechanism used for durability is also the one that limits scalability. Because the copies on the disk act as the ultimate source of truth, adding read capacity necessitates adding more durable replicas. Since every replica is required to participate in every write operation, a push is only as fast as the slowest replica in the set. Consequently, as the infrastructure grows to absorb higher read loads, the write operations become progressively slower—a trade-off that is becoming unsustainable at the highest activity levels.
A Foundation for Everyone
GitHub is currently rebuilding its infrastructure while the platform remains live. Because there is no "maintenance window" in global software development, the transition must occur seamlessly, without forcing users to change how they build their software.
The goal is to engineer for the most demanding workloads: an enterprise operating under strict regulatory requirements, a team modifying an entire operating system, or an organization running thousands of agents against a single codebase. By solving for these extreme edge cases, GitHub effectively raises the floor for every user on the platform. Whether it is a maintainer reviewing volunteer contributions across time zones or a student opening their first pull request, everyone will benefit from a faster, more resilient foundation.
Crucially, this new architecture must preserve the governance controls that teams rely on. Maintainers require robust branch protections and mandatory reviews to ensure that unreviewed code never reaches the default branch. Security teams need comprehensive audit logs and clear visibility to investigate suspicious access events, and on-call engineers need deep observability to diagnose deployment failures. The guiding principle is to ensure that as the platform scales to meet the needs of the busiest repositories, it does not sacrifice the safety and control that underpin the trust of the developer community.
Decoupling and Coordination
To achieve these goals, GitHub is moving toward an architecture that minimizes unnecessary coordination and decouples storage from compute.
In the current model, the repository copies on local disks perform double duty as both durable storage and the active layer that answers Git requests. By separating these two functions, GitHub can scale each one independently. This allows for higher throughput and more concurrent work without abandoning the reliability that users demand.
Furthermore, the team is working to minimize coordination across the board. While coordination is necessary to maintain Git’s strict semantic requirements, excessive coupling can turn a busy repository into a bottleneck. By redesigning the system to isolate the coordination required for Git semantics while allowing other processes to proceed independently, the platform can handle significantly more volume.
The Path Forward
The results of these internal benchmarks are promising, with the new architecture delivering up to 35 times higher write throughput than the existing system, while read capacity scales independently to meet shifting demand. As automated development increases the frequency and concurrency of software change, GitHub is evolving its foundations to keep pace.
This transformation represents a long-term commitment to the millions of developers who rely on GitHub’s infrastructure. By investing deeply in these core systems now, GitHub is ensuring that the platform remains a reliable, high-performance home for the next generation of software, whether that software is written by humans, agents, or a collaborative mix of both. As the company continues to refine this new architecture, the focus remains on maintaining the forward momentum of open-source communities and enterprises, ensuring that the transition to the agentic era is as seamless and powerful as possible.
