The volume of concurrent commits and pushes flowing through GitHub's repositories is accelerating rapidly, creating new architectural demands on systems that every repository depends on. The platform is undertaking a fundamental redesign of its Git infrastructure to handle the scale and concurrency patterns introduced by agent-driven development.

Millions of developers use GitHub daily to build products, contribute to open source, and work on personal projects. The platform's architecture has evolved continuously to meet growing demands, but agentic software development is now driving the next major shift. With developers and agents working concurrently in repositories that process millions of commits daily, the existing Git architecture requires rethinking.

The Scale of Current Workloads

The distribution of repository activity on GitHub reveals an extreme concentration at the high end. In August 2026, the busiest repository on GitHub received roughly a billion requests in a single month. The gap between typical repositories and the highest-volume ones is far wider than most observers realize.

Total Git activity across the platform is growing at an extraordinary pace. Between September 2025 and August 2026, monthly Git events more than doubled, rising from 218.2 billion to 473.3 billion. In September alone, developers and agents created 7.38 billion commits, more than five times the volume from a year prior.

The highest-volume repositories demonstrate what agentic development looks like in practice: large engineering teams running intensive CI pipelines alongside growing agent fleets. Supporting these teams requires Git infrastructure capable of sustaining concurrent reads and writes at a scale that few repositories currently experience. GitHub is investing heavily in this infrastructure to provide teams with a foundation designed for their most demanding workloads.

Architectural Challenges at Scale

Supporting agent-driven development at scale introduces several critical challenges:

  • Commit turnaround becomes a limiting factor for agent speed. Agents in tight loops commit or checkpoint after nearly every action, and their performance is bounded by how quickly a single push completes. Latencies imperceptible to humans become the bottleneck.
  • Write throughput demand is growing by orders of magnitude. Pushes increased 4.9 times year over year, from 0.69 billion to 3.35 billion per month. Thousands of agents working on separate branches in one repository create sustained write rates that converge on a single architectural point.
  • Merges contend on a single reference. Trunk-based development, release trains, and merge queues funnel all work onto one ref that must absorb every merge. Pull request merges on GitHub grew to nearly four times their previous volume.
  • Each push multiplies into thousands of reads. CI and code scanning clone or fetch the same branch tip thousands of times per minute, and this fan-out must remain inexpensive. GitHub Actions alone ran 3.26 billion times in September, more than four times the prior year's volume.
  • Repository operations must remain fast despite growing write volume. Continuous compaction and cleanup of unused objects are necessary, and the cost compounds as volume increases.

Fast clones address only part of the problem. Reads are relatively straightforward to scale through caching and replication, but writes present a fundamentally harder challenge. Every push must be stored durably and made visible consistently before the next agent or CI job can proceed.

Current Architecture and Its Limits

GitHub's existing architecture has served developers well for years. Each repository is managed by Spokes, which maintains a full copy on the local disks of multiple fileservers—five by default. These fast local disks enable Git operations to read native repository data with low latency, and the redundant copies provide both resilience and read distribution across fileservers. When a push updates a reference, a three-phase commit protocol using quorum consensus ensures that CI, the web UI, and API clients observe a consistent repository state. This design currently serves a billion repositories.

However, the mechanism providing durability is also the mechanism providing scale. Since the disk copies serve as the source of truth, adding read capacity requires adding another durable replica. Every replica participates in every write, making a push only as fast as the slowest replica in the set. The consequence is clear: adding replicas to absorb read load slows writes.

For most repositories, this tradeoff is acceptable. At the highest activity levels, it becomes a ceiling: adding read replicas increases write overhead, losing a replica reduces read capacity, and losing quorum halts writes entirely. Meeting the demands of agent-first development requires separating durability from scale while preserving the reliability teams depend on.

Design Principles for the New Architecture

GitHub is rebuilding its infrastructure while the platform continues operating. There is no maintenance window where code stops moving, and no expectation that users will change their development practices during the transition.

The work is being engineered for the most demanding workloads on GitHub: enterprises shipping under strict regulatory requirements, teams landing changes across repositories that build operating systems, and organizations running thousands of agents against a single codebase. Engineering for that scale raises the floor for everyone. Maintainers reviewing volunteer contributions across time zones and students opening their first pull request benefit from the same faster, more resilient foundation.

The new architecture must preserve the controls teams already operate on. Maintainers need branch protections and required reviews to prevent unreviewed changes from reaching the default branch. Security teams need audit logs and repository visibility to investigate suspicious access. On-call engineers need dependable automation and sufficient observability to understand deployment failures.

Three guiding principles shape the work:

  • Build on the workflows developers already trust. Teams rely on branching, review, merge, and history to build, ship, and govern software at scale. The new infrastructure is designed to support these same workflows at much higher activity volumes.
  • Put reliability first. Every decision is measured against the reliability that developers and organizations require. Confidence in the platform enables engineering organizations to build automation, ship on schedule, meet compliance obligations, and understand the software they produce. This work will meaningfully improve throughput and scale while extending the existing foundation of trust.
  • Keep people in control of their code. If the system does not help the people and organizations using it and is not under their control, it is not worth building. As agents take on more work, the people who own the code can still review, understand, and approve it.

Core Design Approach

GitHub is building a new architecture that scales much more effectively, centered on distributed systems design principles applied to the concurrency and scale of agentic software development. The goal is to maintain forward momentum for open-source communities and enterprises while preserving and adapting features and controls to meet the needs of the agentic era.

Minimize Coordination

A repository receiving many pushes must accept and publish updates quickly. Coordination protects correctness but excessive coordination limits write throughput and can turn a busy repository into a bottleneck. The current architecture is tightly coupled in places where it does not need to be, limiting the ability to scale reads and writes without difficult tradeoffs. The redesign preserves the coordination that Git semantics require while allowing everything else to proceed independently.

  • Coordinate only what needs agreement. The part of a push requiring agreement is the reference update itself. Storing underlying objects, validating object connectivity, and secret scanning involve much more work but can happen in parallel to other writes. This shrinks the critical path of a push to the small step needing coordination, so remaining work no longer delays acknowledgment.
  • Move maintenance off the serving path. Compaction and garbage collection are among the heaviest operations a repository performs, and today they run on the same hosts answering live Git requests. In the new architecture, separate workers handle maintenance directly against durable storage. A busy repository can be optimized continuously in the background without slowing pushes and fetches.

Decouple Storage from Compute

Currently, complete repository copies on local disks serve both as durable storage and as the layer answering Git requests. Separating these functions allows independent scaling of each.

  • Scale reads without adding durable copies. In the new architecture, read capacity comes from lightweight workers that cache data to serve requests. The authoritative repository copy lives in a durable storage layer underneath. The platform can absorb large read spikes from CI fan-out, agent fleets, and large clones without adding work to every push.
  • Let each layer do one job. Authoritative repository data lives in Azure Blob Storage, which already provides durability and replication at Azure scale. The compute layer is optimized for throughput at the lowest latency.
  • Recover faster from failures. When storage and compute are coupled, losing a host reduces both capacity and durability, and recovery requires rebuilding a full repository copy. When they are separate, losing a compute worker is closer to a cache miss: a replacement worker can start serving requests immediately and fill its cache from durable storage as traffic arrives.
  • Match capacity to demand. Compute workers can be added or removed as traffic changes instead of provisioning for peak load in advance. A repository experiencing a burst of activity, such as a release or a new agent fleet coming online, can receive extra capacity for the burst. Once the burst passes, that capacity is removed.

Together, these design tenets enable support for higher throughput and more concurrent work without abandoning the reliability and controls users need.

What Comes Next

GitHub is building an architecture designed to provide the highest throughput and reliability available. Reads and writes scale independently, and the system recovers gracefully from failures. In internal benchmarks, it has delivered up to 35 times higher write throughput, with read capacity that scales on its own to meet demand.

As automated development increases the frequency and concurrency of software change, GitHub will evolve its foundations without trading away the governance and control that teams rely on. The foundation is already being put in place. A subsequent post in this series will dive deeper into the future architecture and the journey that led to it.