Every day, GitHub serves as the primary engine for global innovation. Millions of developers rely on the platform to build mission-critical products, contribute to the vast ecosystem of open-source software, and pursue personal projects that push the boundaries of what is possible with code. Over the years, GitHub’s architecture has evolved steadily, transforming to meet the mounting demands of the organizations and individual contributors who depend on its reliability. Today, however, the platform is facing a fundamental shift: the emergence of agentic software development.
As AI agents and automated workflows become increasingly integrated into the development lifecycle, the way code is written and managed is undergoing a profound transformation. Developers and autonomous agents are now working concurrently within the same repositories, generating millions of commits every single day. This new paradigm creates workloads that demand a radically different Git architecture. To ensure that the platform remains a robust foundation for the future of coding, GitHub is in the process of rebuilding its core Git infrastructure. This initiative is designed to support the unique pressures of the agentic era while maintaining the high standards of consistency and durability that the developer community expects.
Understanding the New Scale of Development
The necessity for this architectural shift is best illustrated by looking at the highest-volume workloads currently hosted on the platform. The gap between a typical repository and the busiest ones is significantly wider than many observers anticipate. When analyzing monthly repository activity distributions, it becomes clear that activity levels climb sharply at the extreme end of the spectrum. For instance, in August 2026, the busiest repository on GitHub alone processed roughly one billion requests.
This surge is not limited to a few outliers; it reflects a broader, platform-wide trend. Between September 2025 and August 2026, total Git activity on GitHub more than doubled, jumping from 218.2 billion events per month to 473.3 billion. The volume of commits is particularly staggering: in September 2026 alone, developers and automated agents pushed 7.38 billion commits to the platform, representing a fivefold increase over the previous year.
These top-tier repositories serve as a leading indicator of what the future of software development looks like. They are characterized by large, distributed engineering teams running intense continuous integration (CI) pipelines alongside growing fleets of autonomous agents. Supporting these environments requires an infrastructure capable of sustained, concurrent reads and writes at a scale that very few repositories were reaching even a few years ago. By investing deeply in its Git infrastructure, GitHub aims to provide a foundation that can handle these ambitious, high-concurrency workloads without compromising performance.
The Challenge of Modern Scaling
Addressing this level of growth requires moving beyond traditional solutions. While fast clones were a necessary improvement for developer experience, they only solve a portion of the broader architectural challenge. Scaling read operations is relatively straightforward; by adding caches and replicas, platforms can serve the same bytes to a growing number of clients with relative ease. However, scaling write operations is significantly more complex. Every push must be stored durably and made visible consistently before any subsequent agent or CI job can build upon it. This requirement for immediate, consistent durability is where modern workloads push the limits of existing systems.
Where Today’s Architecture Meets New Demands
For years, GitHub has successfully relied on an architecture known as "Spokes." In this model, every repository is stored by keeping a full copy on the local disks of several fileservers—typically five by default. These high-speed local disks allow Git operations to read native repository data with low latency, while the redundant copies provide both safety and the ability to distribute read traffic across multiple servers. When a push updates a reference, a three-phase commit protocol uses a quorum to ensure that CI systems, the web interface, and API clients all see a consistent state of the repository. This pairing has served a billion repositories effectively to date.
However, the current architecture faces a limitation: the mechanism used for durability is the same one used for scale. Because the copies on disk serve 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, the speed of a push is effectively capped by the performance of the slowest replica in the set. Consequently, the act of adding replicas to accommodate read volume inadvertently makes write operations slower.

While this trade-off is manageable for the vast majority of repositories, it creates a performance ceiling for the highest-activity projects. In these scenarios, adding read replicas increases write overhead, while losing a replica decreases read capacity, and losing quorum can bring writes to a complete halt. To accommodate the demands of agent-first development, GitHub must decouple durability from scale, ensuring that the platform can expand without sacrificing the stability that teams rely on.
Built for the Busiest, Better for Everyone
A critical constraint of this infrastructure overhaul is that it must occur while GitHub remains operational. There is no convenient maintenance window where the world’s code stops moving, and it is not an option to ask developers to change their workflows to accommodate the transition. The engineering team is rebuilding the platform from the inside out while it continues to support millions of users.
The goal is to design for the most demanding workloads imaginable: an enterprise navigating strict regulatory requirements, a large team landing a complex change across an operating system codebase, or an organization running thousands of agents against a single repository. Crucially, engineering for this level of scale raises the floor for all users. A maintainer reviewing contributions from volunteers across different time zones or a student opening their first pull request will benefit from a faster, more resilient foundation.
The new architecture must also preserve the essential controls teams already use. Maintainers require branch protections and mandatory reviews to ensure that unreviewed code never reaches the default branch. Security teams need robust audit logs and clear repository visibility to investigate potential access events. On-call engineers rely on dependable automation and deep observability to diagnose deployment failures. These controls are non-negotiable, and the new architecture is designed to integrate them seamlessly.
The New Approach to Distributed Systems
GitHub’s approach to this redesign is rooted in core distributed systems design tenets, tailored specifically for the concurrency and scale of agentic software development. The goal is to sustain the momentum of open-source communities and enterprises worldwide while adapting the platform to the needs of a new era.
The primary strategy is to minimize coordination. A repository that receives frequent pushes must be able to accept and publish updates rapidly. While coordination is necessary to protect data integrity, excessive reliance on it limits write throughput and creates bottlenecks. The current architecture is tightly coupled in areas that do not strictly require it, which limits the platform’s ability to scale reads and writes independently. By redesigning the system to preserve only the coordination required by Git semantics while allowing other processes to proceed independently, GitHub aims to significantly improve throughput.
Furthermore, the team is moving to decouple storage from compute. Currently, complete repository copies on local disks perform the dual role of durable storage and the interface for answering Git requests. By separating these two layers, GitHub can scale them independently. This separation allows the platform to handle higher throughput and more concurrent work without abandoning the reliability and governance controls that users require.
The results of these changes are already promising. In internal benchmarks, the new architecture has delivered up to 35 times higher write throughput, with read capacity that scales automatically to meet demand. As automated development increases the frequency and concurrency of software change, GitHub is evolving its foundation to ensure it remains the most reliable home for code, proving that even as the nature of work changes, the core principles of governance and control can remain intact. The journey continues as the engineering team prepares to implement these improvements across the platform, with further details on the architecture expected in future updates.

