Introduction
Git was built for human collaboration: a handful of developers, occasional merges, mostly manual coordination. Since 2025, the rise of AI agents has fundamentally changed the load profile. GitHub recorded 473.3 billion Git events in a single month, August 2026, a figure that more than doubled year-over-year. Against that pressure, a decade-old infrastructure began to buckle. The answer is called Rubicon.
Spokes: The Architecture That Hit Its Ceiling
For years, GitHub ran on an architecture called Spokes: replicated copies of each repository distributed across multiple servers, held in sync through a consensus mechanism. It served millions of human engineering teams well, but it carried a hard structural ceiling: a few hundred writes per second, maximum, on any given repository. Write operations blocked one another, and compaction, the background maintenance work that reorganizes Git objects, competed directly with production traffic for server resources.
The breaking point came between March and May 2026: one particularly active repository saw its daily request count surge from 44 million to 181 million in just two months. Four times the load, on a system never dimensioned to absorb it.
Rubicon's Three-Layer Architecture
Announced at GitHub Universe in November 2026, Project Rubicon fundamentally reorganizes Git storage around three independent components that scale separately.
Git objects, commits, trees, blobs, are immutable by nature. Their content never changes once written, which makes them ideal candidates for storage in Azure Blob Storage with zero coordination overhead. A blob is a blob, identified by its hash, retrievable from any node without synchronization.
References (branches, tags) are mutable and demand strict consistency. That's where Ref-CAS comes in: a replicated log service built on a compare-and-swap mechanism with majority quorum. Every reference update goes through a vote across replicas before it's committed. Decoupled entirely from object storage, Ref-CAS can process tens of thousands of operations per second, independent of data volume.
The compute layer, virtual replicas, becomes stateless: lightweight nodes that maintain a local cache, serve read requests, and delegate writes to the central infrastructure. When a node goes down, nothing is lost.
The result of this separation: 7,200 pushes per second to a single repository with 5,000 concurrent agents, a 35x improvement in write throughput over the previous system.
Rebuilding the Plane Mid-Flight
What makes this migration a genuine engineering achievement is that it was executed with zero service interruption, across a platform hosting hundreds of millions of repositories. 99.99999% of GitHub repositories had already been moved to Azure in a prior initiative. Rubicon was built underneath, progressively replacing the lower layers while the system kept running.
This approach, changing the foundations without turning off the water, is among the hardest problems in production software engineering. It demands strict discipline around backward compatibility, observability, and progressive rollout.
What DevOps Teams Should Take Away
The principles behind Rubicon, simplify primitives, decouple storage from compute, minimize coordination, are not GitHub-specific. They reflect the defining patterns of modern distributed systems, applied to a problem that many teams had assumed was already solved.
For teams managing internal forges or high-throughput CI/CD pipelines, the lesson cuts two ways: decoupling mutable and immutable state is not an exclusive luxury of hyperscalers, and well-tuned storage monoliths can quickly become the next bottleneck as AI agents embed themselves into delivery pipelines.
Rubicon is currently in limited private preview. A broader rollout is planned for early 2027.