GitHub's new Git storage architecture, internally codenamed "Project Rubicon," is the company's answer to a problem that didn't exist two years ago: what happens when thousands of AI agents push code to the same repository simultaneously. The design separates immutable Git objects (stored in Azure Blob Storage) from mutable reference state (stored in a custom replicated log called Ref-CAS), and routes all traffic through disposable "virtual replicas" whose local disk is purely a cache. The result, in internal testing: 5,000 concurrent agents, 7,200 pushes per second, with reads still serving at consistently low latency. The core insight is surprisingly simple. Git objects are content-addressed and immutable — two writers can store them at the same time without coordination. The only part that requires agreement is the reference update, which is tiny. Rubicon builds an entire architecture around that asymmetry: writers upload packs to Blob Storage in parallel, then commit a single transaction to Ref-CAS that lists the pack and updates the reference. A separate fleet of compaction nodes merges packs in the background, never touching the virtual replicas that serve live traffic. The article traces two failed approaches to storing reference state in Azure Blob Storage before the team settled on Ref-CAS. A single-blob write-ahead log gave cheap reads but serialized all writes behind one conditional write. A per-reference blob approach removed that bottleneck but made cross-reference reads expensive. Ref-CAS is the custom middle ground: a replicated log service purpose-built for the compare-and-swap pattern that references demand, accepting high write concurrency without sacrificing read consistency. Vertical scale — how many agents can hammer one repository — is the axis that matters here. GitHub's busiest repos today see dozens of writes per second in bursts. The company expects that to become a sustained rate within a year. One repository's daily traffic grew 4x between March and May 2025 and has continued on an exponential curve. The design target was not the next increment but two orders of magnitude: from dozens to thousands of writes per second per repo. The architecture preserves Git's semantics entirely. Developers push, fetch, and branch the same way. Spokes still handles routing, load balancing, partitioning, and tenant fairness. What changes is the data plane underneath: virtual replicas are stateless and disposable, Blob Storage holds the durable objects, Ref-CAS holds the durable reference state, and compaction runs on dedicated nodes. Each layer scales independently. When a repository gets busy, GitHub adds more virtual replicas. When a virtual replica dies, its peers keep serving. The migration strategy is incremental. The previous phase moved 99.99999% of repositories into Azure and stood up virtual replicas as the onramp. Rubicon builds on that foundation. The seven-nines migration number is worth noting: GitHub is not asking repositories to opt in. They are rebuilding the storage layer underneath a running platform used by hundreds of millions of developers. The bet is that agentic development will make the current architecture inadequate within the next year. If that bet is right, Rubicon is infrastructure debt paid early. If agent-driven development plateaus, GitHub has overbuilt — but with a cleaner separation of concerns that benefits the platform regardless. The deeper strategic implication is that GitHub is positioning itself as the only Git host that can handle agent-scale traffic, making it harder for competitors to match the platform's capacity at the moment when capacity matters most.
