OpenAI deploys Pando to scale Git for its growing monorepo
OpenAI has deployed Pando, a new backend for Git repositories that now powers all development in the company’s monorepo. The system was designed to support the increased concurrency associated with Codex while preserving the Git protocol, Git client and established engineering workflows.
In production, Pando reduced median push latency by nearly fivefold and improved merge reliability. OpenAI says the platform delivers nearly a petabyte of Git data per day, has served more than 57 TB of Git packs in a single hour, and draws more than 99% of those bytes from local disk cache.
Separate scaling for writes and reads
OpenAI identified two distinct scaling requirements: many clients pushing to different branches at once, and many clients fetching the same repository history. Its earlier monorepo service began showing slow fetches and pushes, failed merges, and reliability below 90% at times as concurrent work expanded.
Pando handles updates to each Git reference independently. This allows pushes to unrelated branches to proceed in parallel, while updates to an individual ref remain serializable. The trade-off is causal consistency rather than a repository-wide point-in-time view: a client reading several branches may observe them at different moments.
For a push, Pando validates an incoming packfile while streaming it to blob storage. It then records a ref version and updates the ref pointer in a metadata store through a multi-key transaction. OpenAI says the synchronous path uses a constant number of metadata reads and writes, while asynchronous work such as compaction is scheduled separately.
Reusing packfiles instead of rebuilding them
Conventional Git services commonly compute a client-specific pack by comparing the objects a client has with those it wants. Pando instead selects previously stored packs associated with ref versions. This avoids unpacking packs into a local repository and avoids costly repacking on serving nodes.
By default, Pando advertises a designated trunk branch when a client pushes a feature branch. That choice makes the advertised reference set stable as branch counts increase and helps create reusable packs, although repeated pushes or stacked branches can resend objects outside trunk. OpenAI reports that the median packfile in its monorepo was under 20 KiB and the 99th percentile was under 3 MiB.
On fetches, Pando maps Git protocol haves and wants to ref versions, then returns packfile URIs. Express serves these packs through regional caches, while background compaction combines small packs into larger covers. OpenAI says this approach supports logarithmic-time fetch planning and has demonstrated clone and fetch performance that saturates 10 Gbps network links on standard cloud virtual machines.
Built and migrated without workflow disruption
OpenAI built Pando in Rust in 10 weeks, using Codex-assisted development, Git conformance tests and deterministic simulation testing. It first operated as a read- and write-through proxy to the existing source-control system, enabling a phased migration without downtime. The company also migrated hundreds of integrations relying on legacy APIs, webhooks and repository downloads.
The company contributed several related client improvements upstream to Git, including work on concurrent pack downloads, interrupted-transfer cleanup, download tracing and packfile-uri support. For businesses operating large shared repositories, Pando illustrates that separating per-branch write coordination from reusable read delivery can raise throughput without requiring developers to abandon Git workflows.