Uber: GitFarm — Git as a Service for Large-Scale Monorepos
Problem + constraints
Uber runs multi-gigabyte monorepos, and the standard Git workflow — every client (developer laptop, CI job, build agent) clones the repo locally, keeps a local checkout, and continuously syncs it — turns into a genuine infrastructure bottleneck at that scale. Cold-start latency for a fresh clone or checkout ran up to 15 minutes, every one of those clients was independently hammering upstream Git servers with redundant clone/fetch traffic, and each client was paying its own local compute and I/O cost to maintain a checkout it might use for a single CI run and then throw away. The constraint isn't Git's correctness — it's that Git's default model assumes every client wants a full, durable, local copy, which is the wrong assumption when most callers (CI jobs especially) just need a fast, disposable, read-mostly checkout.
Solution
Uber built GitFarm: Git exposed as a stateful, identity-scoped, repository-centric execution service via a gRPC API, rather than something every client clones locally. A request comes into the GitFarm Gateway, which authenticates and authorizes it and routes it to the GitFarm Backend; the Backend picks an available node and executes the Git operation inside a secure, ephemeral sandbox on that node — critically, backed by a pre-warmed repository checkout rather than a cold clone. Because the checkout is pre-warmed and shared server-side infrastructure rather than freshly cloned per-client, GitFarm delivers a ready-to-use checkout in under 500ms (down from up to 15 minutes) and cuts resource overhead by more than 80%, while also taking the redundant clone/fetch load off upstream Git servers since clients no longer each maintain their own full local copy.
What to steal
- When a widely-used tool's default model (every client keeps a full local copy) stops matching how most callers actually use it (many callers just want a fast, disposable, read-mostly checkout), the fix is a service layer that changes the interaction model — not a faster version of the old model. GitFarm didn't optimize
git clone; it made most clients stop cloning at all. - Pre-warming server-side state (the checkout) to amortize a cost across many callers is a pattern that generalizes well beyond Git — anywhere a "cold start" cost is paid repeatedly by many short-lived, disposable clients (CI runners, serverless containers, ephemeral build agents), check whether that cost can move server-side and be shared instead of being paid per-client.
- Decoupling repository management from the client application via a gateway + backend + ephemeral sandbox execution model is a reusable shape for "as a service"-ifying any tool that traditionally assumed local, stateful client installs.
- The 80%+ resource-overhead reduction is the real payoff metric here, not just the latency number — redundant local state across thousands of CI jobs is a hidden multiplier on infrastructure cost that's easy to underestimate until someone centralizes it and measures the delta.
Engineering Lens
This is a clean example of a build-vs-buy-vs-rearchitect call that pays off specifically at scale: for a ten-person team, "everyone clones the repo" is fine, and a Git-as-a-Service platform would be pure overengineering. At Uber's monorepo scale, the redundant-clone cost compounds across every CI job and every developer machine, and centralizing it into a service is the kind of platform investment that's hard to justify with a single team's budget but easy to justify amortized across an entire engineering org — exactly the kind of tradeoff a Principal Engineer has to be able to size and defend in front of a platform-investment review. It also generalizes as an architecture-review pattern: whenever a system component is used read-mostly and repeatedly by many short-lived, disposable clients, ask whether that access pattern justifies moving the state server-side, rather than accepting "that's just how the tool works" as a fixed constraint.