Glonce

GitHub details Rubicon, its new Git storage design for agent-scale pushes

infrastructureThe Glonce editorsHacker News🔥74Glonce rating74Impact72Novelty68Relevance95Surprise45Players85Credibility85
GitHub details Rubicon, its new Git storage design for agent-scale pushes

GitHub's engineering blog has laid out the architecture it announced a week earlier at GitHub Universe: a new way of storing Git data, built so that thousands of agents can push to a single repository at once. GitHub says internal testing showed the design supporting 5,000 concurrent agents working on a repository and sending 7,200 pushes per second to it, while serving read traffic with consistently low latency. The company calls it the foundation for supporting agentic development for hundreds of millions of developers, and says it has been building it underneath GitHub while the service keeps running.

The post is part of a series. The first post set out two principles for the next-generation design: minimize coordination, and decouple storage from compute. The last one covered the bridge to it: moving 99.99999% of repositories into Azure, scoping the write quorum to individual references, and standing up virtual replicas backed by Azure Blob Storage. The key observation carried over is that very little of a write needs ordering. Git objects are immutable and named by their contents, so two writers can store them at the same time without agreeing on anything. Only reference updates need agreement, and a reference update is tiny by comparison. For developers, GitHub says, Git stays Git: they push, fetch and branch the same way, with the same protections in place.

GitHub frames scale along two axes. Horizontal scale is how many developers and agents work across many repositories; existing approaches such as tenant partitioning, isolation and fairness enforcement, and load-aware routing are carried forward. Vertical scale is how many work on one repository, and most of the new requirements came from there. Today the busiest repositories on GitHub.com receive at most dozens of writes in a single second, typically in short bursts. GitHub expects those bursts to become a sustained rate within the next year as agents run in parallel and around the clock. Each push also triggers more reads, from CI runs, deployment systems and other agents fetching the new commit for context, so read traffic is amplified along with writes. As one data point, daily requests to one repository grew about 4x from March to May, and the post says growth has stayed on an exponential trajectory since. Rather than plan for the next increment, GitHub set a target of at least two orders of magnitude more scale.

For a single repository, that meant the system had to accept thousands of writes per second and support multiple writer nodes. The reasons given: indexing incoming packs and checking object connectivity are the most CPU-expensive parts of a write and grow with write size, so one node would quickly become compute-bound; and spreading the work improves fault tolerance and shortens recovery. It also had to minimize commit latency, since an agent waits on each push before its next step; record changes in order per reference while being able to linearize across references quickly; keep reads cheap when nothing has changed; and let each component scale independently. A virtual replica that falls behind must catch up by downloading only the data it needs for the incoming request.

Work on the design, named Rubicon after the point of no return the industry crossed with agentic development, began in May 2026, right after the initial Azure migration. GitHub tried several approaches, all with pack data in Blob Storage, and in some also kept reference state there.

The request path works like this. Requests from Git clients, the API and the web UI still arrive at Spokes, which handles routing and load balancing, serves the internal API the rest of GitHub uses to read and write repository data, and remains the placement and balancing service. The data plane underneath is new. Spokes routes each request to one of a small group of virtual replicas assigned to the repository. Virtual replicas are a single fleet of disposable compute that serves reads, writes or both, and a replica's local disk is a cache that can be rebuilt at any time. Spokes sends a repository's traffic to the same replicas when it can, which keeps caches warm, but correctness never depends on which replica gets a request. If one disappears, the others keep serving and a replacement fills its cache as traffic arrives. Busy repositories get more replicas. Separately, a fleet of compaction nodes works in the background directly against Blob Storage and Ref-CAS, merging each repository's packs and removing unreachable objects, so replica CPU and memory can go almost entirely to serving requests.

Durable state lives in two places. Git objects, as packs plus auxiliary read acceleration data, are in Azure Blob Storage. References and the list of packs making up the repository (the pack manifest) are in a separate replicated log service called Ref-CAS, for Reference Compare-and-Swap. A write has a virtual replica index the incoming pack, upload it to Blob Storage, then commit one transaction to Ref-CAS that lists the pack in the manifest and updates the references; a compaction node later merges that pack with others to keep reads fast. A read has a replica check its reference version with Ref-CAS, pull the packs it needs from Blob Storage into its cache and serve from there.

The post then digs into why references got their own service. Blob Storage holds nearly everything else: packs and indexes from pushes, compaction and garbage collection; read accelerators such as multi-pack indexes and reachability bitmaps; records and leases for compaction and garbage collection; cached responses for repeated fetches; and checkpoints of reference state, though not the authoritative state. Most of that is written once to a distinct key and never changes, which suits object storage. References are the opposite: a small piece of state that many writes race to update. Two prototypes showed the problem. The first was a write-ahead log for all of a repository's references, indexed by a single blob, with every update a conditional write against it. Reads were cheap, but only one conditional write can be in flight at a time, so the write ceiling was one write per round trip, and in practice throughput landed in the mid-hundreds per second even with batching. The second split references across several segment blobs by hash. Writes to different segments no longer waited on each other, but a read had to check every segment and was only as fast as the slowest, trading write latency for read latency when reads outnumber writes by orders of magnitude.

Neither met every requirement, so GitHub built Ref-CAS, a replicated log dedicated to references and described as a small consensus group. Each reference update is a compare-and-swap committed by a quorum. A transaction locks only the references it touches, checks each still holds the value the writer expects, and becomes visible once a majority of the log's replicas have recorded it. Because agents mostly push to their own branches, most updates do not contend and replicate in parallel; when two pushes update the same reference, only one appends to the log. Each commit gets a log sequence number (LSN), and a repository's version is the LSN of its latest commit. Reads begin with a version check against that version.

Key facts

  • GitHub says internal testing showed 5,000 concurrent agents sending 7,200 pushes per second to one repository, with consistently low read latency.
  • Rubicon puts Git objects (packs) in Azure Blob Storage and references plus the pack manifest in Ref-CAS, a replicated log service; disposable virtual replicas serve reads and writes behind Spokes.
  • The busiest repositories on GitHub.com today see at most dozens of writes per second, in short bursts; GitHub expects sustained rates like that within the next year and set a target of at least two orders of magnitude more scale.
  • Prototypes that kept references in Blob Storage hit limits: a single-blob write-ahead log gave mid-hundreds of writes per second, and splitting references across segment blobs made reads as slow as the slowest segment.
  • Work started in May 2026; for developers, GitHub says Git stays Git, with the same push, fetch and branch workflow and protections.

Why it matters

AI coding agents change what a busy repository looks like: many writers, around the clock, each waiting on its push before taking the next step, and every push fanning out into CI, deployment and other agents' reads. GitHub says the busiest repositories today see at most dozens of writes per second in bursts, expects those to become sustained within the next year, and set a target of at least two orders of magnitude more. The design's central idea is that only reference updates need agreement, because Git objects are immutable and named by content. That lets storage, request serving and maintenance scale separately.

Who it affects

Developers and teams on GitHub.com, and especially anyone running many agents against one repository. GitHub says nothing changes in how they work: they push, fetch and branch the same way, with the same protections. The architecture is also a reference for engineers designing storage for write-heavy, contended state, since the post walks through the trade-offs it hit with object storage.

How to use it

This is internal infrastructure, not a feature to switch on, and the post mentions no pricing or product changes. The practical takeaways are design lessons from the post. Keep write-once data (packs, indexes, read accelerators, checkpoints) in object storage, where it scales well across many keys. Keep small, heavily contended state such as references in a dedicated replicated log, rather than behind conditional writes on one blob or a few segment blobs. Make compute disposable by treating local disks as rebuildable caches, and run compaction on separate nodes so request-serving machines are not taxed.

How solid is it

This is a first-party engineering post from GitHub. The headline figures, 5,000 concurrent agents and 7,200 pushes per second to one repository, come from internal testing; the post gives no details of the test repository, hardware, read load or actual latency numbers. The mid-hundreds-per-second result for the first prototype is likewise GitHub's own account. The roughly 4x traffic growth is for a single unnamed repository over March to May. The 99.99999% figure refers to the earlier migration of repositories into Azure, covered in the previous post, not to adoption of Rubicon.

Risks and caveats

The expectation that write bursts become a sustained rate within a year is a forecast, not a measurement. The 7,200 pushes per second was demonstrated in testing, not seen as production traffic. The post gives no rollout schedule for moving all repositories to Rubicon and no statement that it is already serving production repositories at that load. It also does not name the consensus protocol behind Ref-CAS or the number of replicas. Ref-CAS becomes a single dedicated service on the write path for references, which is why GitHub describes it as a small consensus group, and the post says repository onboarding happens through virtual replicas.

“Only reference updates need agreement.”

— GitHub engineering blog, "Inside GitHub's new Git storage architecture"