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.
Principal Engineer 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.
Reel Script
Setup: Uber's monorepos are multi-gigabyte, and thousands of CI jobs and developer machines each cloning and syncing their own local copy was costing up to 15-minute cold starts and hammering upstream Git servers with redundant traffic.
Concept walkthrough: Explain GitFarm's shape: a gRPC Gateway authenticates and routes requests, the Backend picks a node, and the Git operation runs inside an ephemeral sandbox backed by a pre-warmed checkout — so the client never clones anything locally, it just asks the service for a ready-to-use checkout.
Real example tie-in: Walk through a CI job hitting GitFarm: instead of a cold git clone eating minutes of the job's runtime, the job gets a checkout mounted from a pre-warmed sandbox in under 500ms, and that pre-warmed state is shared infrastructure rather than something the CI job paid to build itself.
Tradeoffs & alternatives: Contrast with just optimizing the clone path (shallow clones, partial clones, Git's own sparse-checkout features) — those help, but they're still paying a per-client cost every time. GitFarm's tradeoff is real platform complexity (a gateway, a fleet of backend nodes, sandbox orchestration) in exchange for eliminating the per-client cost entirely rather than shrinking it — worth it only once the aggregate per-client cost across your whole org clears that platform-build bar.
Principal Engineer takeaway: When a tool's default model has every client pay a redundant cost, ask whether that cost can be centralized and shared instead — and be ready to size exactly where the break-even point is, because the same rearchitecture that's overkill for a small team is a clear win at platform scale.
Related
Sources: