Ing. Calogero Bono
GitHub has described Rubicon, the new Git storage architecture announced at GitHub Universe. According to the company, in internal tests it handled 5,000 concurrent agents on a single repository, with 7,200 pushes per second and low-latency reads. It matters because coding agents are changing the load on repositories, and what GitHub runs today may not be enough a year from now.
A few terms before we get into the facts. Agent is an AI program that writes code and pushes on its own. Reference is the pointer to a commit, like a branch. Pack is the file that bundles Git objects. Compare-and-swap is an operation that updates a value only if nobody has changed it in the meantime. Blob Storage is Azure's object storage service.
What is Rubicon and why did GitHub build it?
Rubicon is the name of the project with which GitHub redesigned how it stores and serves Git data. According to the GitHub article, the work began in May 2026, right after the initial migration to Azure.
The reason is load. GitHub says that today its busiest repositories receive at most dozens of writes per second, in short bursts. With agents working in parallel and continuously, it expects this to become a steady rate within a year. That is why it set a target of at least two more orders of magnitude.
What scale requirements did GitHub set?
GitHub distinguishes two axes. Horizontal scale concerns the number of repositories, and here proven solutions such as partitioning and load-based routing still apply. Vertical scale concerns a single, very large and busy repository, and this is where almost all the requirements come from.
For a single repository the architecture must accept thousands of writes per second and support multiple write nodes. It must also reduce commit latency, because an agent waits for each push before the next step. Every push also generates more reads, from CI, deployments and other agents, and GitHub describes a strong amplification effect.
One example cited is a repository whose daily traffic grew about fourfold between March and May.
How does the new architecture work?
The starting idea is that agreement is only needed when updating references. Git objects are immutable and identified by their content, so multiple writers can store them together. This way storage, request serving and maintenance scale independently.
Requests arrive at Spokes, which continues to handle routing and load balancing. Underneath is a new data plane, with virtual replicas and disposable compute whose local disk is just a rebuildable cache. Durable state lives in two places.
- Packs and acceleration data in Azure Blob Storage.
- References and the list of packs (the manifest) in Ref-CAS, a replicated log service.
A write indexes the pack, uploads it to Blob Storage and performs a single transaction on Ref-CAS. A read checks the version of the references, downloads the missing packs and responds from cache. Pack compaction runs on separate nodes, never on the replicas.
Does anything change for those who use Git every day?
According to GitHub, no. Git remains Git, with push, fetch and branches working the same way and with the same protections. The change is under the hood and is being rolled out while the platform stays in operation.
The topic ties into what is happening with Git tools for agents, as in the case of OpenAI acquiring Pierre. Those who know the basic commands well, for example with Git bisect and blame, do not need to change their habits.
Limits to know
The figures on 5,000 agents and 7,200 pushes per second come from internal tests reported by GitHub, with no external verification. The text provided cuts off before the details on the two components covered in depth, so we do not know the technical trade-offs. Complete adoption dates for all repositories are not available.
What changes for those working in digital
For an agency or a small team, almost nothing changes in the short term. The real point is different. If your workflows use agents that push frequently, GitHub is preparing its platform so it holds up. It is still worth reviewing your own pipeline, because every push triggers chains of reads, as also discussed in the comparison between GitLab CI/CD and GitHub Actions. Those building platforms with many customers can take note of the principle of separating compute and data, a theme close to multi-tenant design.
Our take
Rubicon is a serious engineering project, and the idea of coordinating only the references is elegant. But the name also says something else. GitHub treats agent load as a point of no return, and takes it for granted. It remains to be seen whether growth will really be what is forecast, or whether synthetic tests will overstate real usage. Independent data would be needed, not just the vendor's own.
Frequently asked questions
What is GitHub's Project Rubicon?
It is GitHub's new Git storage architecture, announced at GitHub Universe. It separates storage and compute and coordinates only reference updates.
How many pushes per second can it handle?
In internal tests GitHub reports 7,200 pushes per second on a single repository, with 5,000 concurrent agents. These are the company's own figures, not verified by third parties.
Do I need to change how I use Git?
No. According to GitHub, push, fetch and branches work as before, with the same protections.
Where is the data stored?
Packs live in Azure Blob Storage. References and the list of packs live in Ref-CAS, a replicated log service.
Why are more replicas needed for a repository?
Because indexing packs and checking object connectivity consumes a lot of CPU. More nodes spread the work and improve fault tolerance.
What to watch as Rubicon reaches everyone's repositories
The real test will be the move from internal numbers to real repositories. Here is what to keep an eye on.
- Follow GitHub's upcoming articles in the series on the two components covered in depth, to understand the trade-offs.
- Check whether push and fetch times for your repositories change over the coming months.
- See whether GitHub publishes limits or usage rules for agents making many parallel pushes.
