GitHub rebuilds its Git storage to absorb 5,000 agents on a single repository
On November 5, 2026, GitHub detailed “Project Rubicon”, its new Git storage architecture capable of 7,200 pushes per second to one repository and 5,000 concurrent agents, built on a simple insight: only reference updates need coordination. Immutable Git objects go to Azure Blob Storage; the tiny mutable state goes to a replicated log.
November 5, 2026. Karthik Raman and Brian Celenza publish on the GitHub blog the details of the platform’s new Git storage architecture, announced a week earlier at GitHub Universe. 7,200 pushes per second. That is the throughput achieved in internal testing on a single repository. 5,000 agents. That is the number of concurrent agents working on that same repository, while reads stay at low latency. Why it matters: GitHub rebuilt the most critical layer of its platform — code storage — while it was running, to absorb a world where thousands of agents push continuously to the same repositories.
The problem: agents change the shape of a busy repository
The starting point is a quantified observation. Today, the busiest repositories on GitHub receive at most a few dozen writes per second, in short bursts. With the arrival of coding agents running in parallel, around the clock, those bursts will become a sustained rate within a year. Every push also triggers a read fan-out: the CI runs, deployment systems pull the commit, other agents fetch it for context. GitHub says it already sees this trend on repositories at the top of the curve — one of them saw its daily traffic quadruple between March and May, then continue on an exponential path.
Rather than plan for “the next increment”, the team set a target of two orders of magnitude more capacity. For a single repository, that means accepting thousands of writes per second, spreading writes across multiple nodes — pack indexing and object connectivity checking are the most CPU-expensive steps, and one node would saturate quickly — and minimizing commit latency, since an agent waits on every push before moving to its next step.
The master idea: only references need agreement
Everything follows from an observation about the nature of Git. Git objects are immutable and named by their contents: two writers can store them at the same time without agreeing on anything, because the object deadbeef… will be identical regardless of arrival order. The only part of a push that requires agreement is the reference update — the branch or tag pointing at the new state — and that update is tiny compared to everything else.
The architecture draws two principles from this, laid out in the first post of the series: minimize coordination and decouple storage from compute. The heavy part (packs) becomes an object-throughput problem, a natural fit for a service like Azure Blob Storage; the ordered part (references) becomes a replicated log. The components that used to be welded together — storing, serving, maintaining a repository — can finally scale independently.
For the developer, Git stays Git: same commands, same protections. The rework is invisible client-side, and that is the point.
“Project Rubicon”: an entirely new data plane
The project carries a deliberate name: “Rubicon”, a nod to the point of no return the industry crossed with agentic development. It started in May 2026, hot on the heels of the initial Azure migration — which already moved 99.99999% of repositories and scoped the write quorum to individual references.
Above that, a lot stays the same. Requests from Git clients, the API and the web UI land on Spokes, which keeps its role of routing, load balancing, placement and tenant fairness — it carries horizontal scale. Below it, however, the data plane is new.
Spokes routes each request to one of the virtual replicas assigned to the repository. These replicas form a single fleet of disposable compute: their local disk is only a cache, rebuildable at any time. When a replica goes away, the others keep serving and a replacement fills its cache as traffic arrives. When a repository gets busy, you add replicas. In parallel, a fleet of compaction nodes works in the background, directly against Blob Storage and Ref-CAS, to merge packs and remove unreachable objects — never on the replicas, whose CPU and memory stay dedicated to serving.
Durable state lives in two places: Git objects (packs and read-acceleration data) in Azure Blob Storage; references and the pack manifest in a replicated log called Ref-CAS, for Reference Compare-and-Swap.
Two paths, one ordered transaction
The path of a write fits in one sentence: a virtual replica indexes the incoming pack and uploads it to Blob Storage, then commits a single transaction to Ref-CAS that lists the pack in the manifest and updates the references; a compaction node merges it later. The path of a read: the replica checks its reference version against Ref-CAS, pulls the packs it needs from Blob Storage into its cache, and serves from there.
The subtlety is in what goes where. Blob Storage hosts almost everything durable: the packs and indexes written by pushes, compaction and garbage collection; the read accelerators (multi-pack indexes, reachability bitmaps); the records that let compaction resume or audit its work; the leases that claim work; the cached responses for repeated fetches; and the checkpoints of reference state — non-authoritative. Anything written once to a key and never changing again is an ideal object-storage citizen.
References are the exact opposite: hot and mutable. A very active repository changes its branch reference thousands of times per second — exactly what an immutable object store handles poorly, and the reason Ref-CAS exists.
What this changes for an SRE
The lesson extends beyond GitHub. The pattern “immutable content-addressed objects + a replicated log for the tiny mutable state” is a generic answer to saturation in high read/write-ratio systems: push immutable state to the cheapest, most scalable store, and concentrate coordination on the smallest possible unit of ordering. It is the same move immutability already made familiar in build pipelines, transplanted to the heart of the forge.
For the operator, the signal is concrete: agentic development does not only change what you deploy — it changes the load profile of the tooling that serves it. A repository that absorbed bursts will have to absorb continuous throughput, and architectures designed for humans — a few dozen writes per second, in spikes — will not hold. GitHub’s rework is a preview of what most internal platforms will have to redo.
Verdict
If you run a forge or a delivery platform, read “Rubicon” as a roadmap, not an anecdote. The target is explicit: at least two orders of magnitude more capacity, because agents will make continuous what used to be episodic. If your forge is a monolithic internal GitLab or Gitea, measure your read/write ratio and your burstiness now: that is the metric that will tell you when the same rework becomes necessary. If you consume GitHub, you have nothing to do — the migration is invisible client-side — but expect the notion of a “busy repository” to change scale, and size your webhooks and CI accordingly. The lesson fits in one line: when the immutable dominates, only the reference still deserves coordination.