Image: GitHub — the Project Rubicon architecture: Spokes routes requests to virtual replicas, with packs in Azure Blob Storage and references in Ref-CAS (official diagram from the GitHub Blog).
TL;DR — GitHub Project Rubicon is a rebuilt Git storage architecture designed for the age of AI coding agents. In GitHub's internal tests it handled 7,200 pushes a second to a single repository with 5,000 agents working at once. It is in limited private preview now, with a wider rollout early next year — and for most developers, Git itself does not change.
📌 KEY HIGHLIGHTS
- Announced at GitHub Universe: GitHub detailed the new architecture on 5 November 2026 in a GitHub Blog post by Distinguished Engineer Karthik Raman and Principal Software Engineer Brian Celenza.
- The headline numbers: internal testing showed 5,000 concurrent agents on one repository sending 7,200 pushes per second, while read traffic kept consistently low latency.
- Why now: the busiest repositories today see at most dozens of writes a second in short bursts. As agents work in parallel around the clock, GitHub expects those bursts to become a sustained rate within a year.
- The core idea: Git objects are immutable and named by their contents, so two writers can store them at the same time without agreeing on anything — only the tiny reference update needs agreement.
- Status: limited private preview now, broader rollout early next year. Developers push, fetch and branch exactly as before.
What happened?
GitHub announced its new Git storage architecture at GitHub Universe, its annual event held on 28–29 October 2026, and published the full technical deep dive on 5 November 2026. It is the third post in a series: the first, on 6 October, laid out the two principles — minimise coordination, decouple storage from compute — and the second, on 21 October, covered the bridge step of moving 99.99999% of repositories into Azure. The new design is called "Project Rubicon", which GitHub says is "a nod to the point of no return the industry crossed with agentic development". Design work began in May 2026, and it caps a busy month for GitHub's platform team: the same week also brought GitHub's November SSH brownout and CodeQL 2.27.3.
Why agents broke the old Git storage
GitHub's existing system, Spokes, stores a full copy of every repository on the local disks of several fileservers — five by default — and updates references through a three-phase commit with a quorum, so every replica takes part in every write. That worked well when the writers were humans. AI coding agents changed the pattern: an agent commits or checkpoints after nearly every action, many agents work on the same repository in parallel, and they run around the clock. Each push also creates more reads — CI runs, deployment systems pull the new commit, and other agents fetch it for context.
GitHub says it is already seeing the trend on its busiest repositories: daily requests to one repository grew about four times between March and May 2026, from an average of 44 million a day to 181 million a day. Rather than plan for the next increment, GitHub targeted at least 100x more scale for a single repository.
Daily requests to a single repository grew about 4x from March to May 2026. Image: GitHub (official chart from the GitHub Blog).
How Project Rubicon works
From a developer's point of view, almost nothing changes at the front door: requests from Git clients, the API and the web UI still arrive at Spokes, which still handles routing, load balancing and the internal API. What is new is the data plane underneath. Spokes routes each request to a small group of virtual replicas assigned to that repository — disposable compute nodes that serve reads, writes, or both, with local disk as a rebuildable cache. When one disappears, the others keep serving; when a repository gets busy, GitHub adds more replicas.
Durable state lives in two places. Git objects, in the form of packs, live in Azure Blob Storage. References — the branch and tag pointers — and the list of packs that make up the repository live in a separate replicated log service called Ref-CAS, short for "Reference Compare-and-Swap". A write works like this: a virtual replica indexes the incoming pack, uploads it to Blob Storage, then commits one transaction to Ref-CAS that lists the pack and updates the references.
Ref-CAS is the clever part. Each reference update is a compare-and-swap committed by a quorum, locking only the references it touches. Agents mostly push to their own branches, so most updates run in parallel; when two pushes update the same reference, only one makes it into the log. Ref-CAS stores pointers, not objects, and a reference only ever points at objects already durable in Blob Storage. Reads are cheap, too: if a virtual replica's version is current, an unchanged repository costs a single comparison. Compaction is separated from serving as well — background nodes merge packs into fewer, larger ones, so the pack count and latency stay flat as writes climb.
| What | Old Spokes system | Project Rubicon |
|---|---|---|
| Repository data | Full copies on local disks of several fileservers (five by default) | Packs in Azure Blob Storage; references in the Ref-CAS log |
| Serving requests | The same replicas that store the data | Disposable virtual replicas; local disk is only a cache |
| Reference updates | Three-phase commit with a quorum across every replica | Compare-and-swap in Ref-CAS, locking only the references touched |
| Compaction | Runs on serving replicas, on every replica | Separate background nodes, directly against Blob Storage |
| Tested scale | Dozens of writes a second in short bursts | 7,200 pushes a second, 5,000 concurrent agents (internal tests) |
What it means for developers in India
For Indian developers, who build on GitHub every day across startups, enterprises and open source, the short answer is that nothing in your daily workflow changes — GitHub says "Git stays Git", with the same push, fetch and branch commands and the same protections. What changes is what happens underneath when a repository gets busy: fewer slow or failed pushes when an agent fleet and CI hammer the same repo, and no migration when a side project suddenly picks up agents overnight.
It also unlocks planned features: working without a full clone, an atomic commit API for multi-file changes, and event streams so agents can react to changes as they happen. Git storage is having a moment beyond GitHub, too — OpenAI's acquisition of Pierre Computer centres on the same problem of making Git work for agents. GitHub has announced no India-specific rollout or dates, so there is nothing to opt into yet — the wider rollout is expected early next year.
Should you care?
✅ Yes, if you run busy repositories or agent fleets. Rubicon is the infrastructure that decides whether thousands of agents can share one repo without stepping on each other — and it is the foundation for the agent features GitHub plans next. ⏳ No action needed yet. It is a limited private preview, your Git commands do not change, and the 7,200-pushes-a-second figure is GitHub's own internal test result, not an independent benchmark.
FAQs
What is GitHub Project Rubicon?
GitHub's rebuilt Git storage architecture for agent-scale development: Git objects live in Azure Blob Storage, references in a replicated log service called Ref-CAS, and requests are served by disposable virtual replicas — replacing Spokes, which kept full repository copies on fileserver disks.
How does Project Rubicon handle 7,200 pushes a second?
Git objects are immutable and content-addressed, so many writers can store them at once. Only the small reference update needs agreement, and Ref-CAS commits those in parallel by compare-and-swap quorum, while background nodes handle compaction.
Will Project Rubicon change how I use Git?
No. GitHub says developers push, fetch and branch the same way, with the same protections. Spokes still handles routing and the API, and the changes sit in the storage layer underneath. The visible difference should be reliability and speed on busy repositories.
When will Project Rubicon roll out to everyone?
Limited private preview now, with a broader rollout early next year. GitHub has announced no date, region schedule or opt-in for individual developers yet.
Takeaway: GitHub rebuilt the storage under Git because AI agents push code the way humans never did — constantly, in parallel, around the clock. Rubicon's answer is to coordinate as little as possible and let storage, serving and maintenance scale separately.
If you maintain a busy repository, the practical next step is simple: nothing changes in your workflow yet — but read GitHub's own deep dive in the Sources below to see whether your team's agent setup will benefit when the wider rollout lands early next year.
Sources
- GitHub Blog — Inside GitHub's new Git storage architecture (primary source; published 5 November 2026)
- Zot News — Inside GitHub's new Git storage architecture: 'Project Rubicon' targets agent-scale performance
- Mezha — How GitHub redesigned Git storage for agent-driven development
- StartupHub — GitHub rebuilt Git for 7,200 pushes a second
Comments
Post a Comment