GitHub rebuilds Git storage to survive thousands of agent pushes a second
Project Rubicon splits mutable Git references from immutable object storage, hitting 7,200 pushes a second to one repository in internal tests. It is in limited private preview now.
GitHub has built a new Git storage architecture, named Project Rubicon, to cope with repositories that get pushed to by thousands of coding agents at once rather than a handful of humans. In a post published on 5 November, GitHub says one customer repository saw traffic grow 4x between March and May 2026, and that the old infrastructure couldn’t keep write latency flat as concurrent writers climbed into the thousands.
Rubicon separates the two things Git actually has to coordinate: mutable references (branches, tags) and immutable objects (commits, trees, blobs). References now go through Ref-CAS, a replicated log service built on compare-and-swap transactions, while objects sit in Azure Blob Storage, read and written by disposable “virtual replica” compute nodes with local disk caches. Separate compaction nodes merge packs and garbage-collect in the background. In internal tests, GitHub measured 7,200 pushes a second to a single repository with 5,000 concurrent agents, and a flat latency curve as write volume rose.
Why it matters: if you’re pointing a fleet of coding agents at one repository, today’s answer to “will this scale” has mostly been “nobody’s tried it at this volume.” Rubicon is GitHub’s admission that normal human-paced Git traffic and agent-paced Git traffic are different engineering problems, and a sign of where repo hosting is heading as agents write more of the commits.
The caveat: Rubicon is in limited private preview now, with a broader rollout planned for early next year, so none of this is available to try yet.