Uber cuts a 15-minute Git cold start to a 500-millisecond checkout
Most teams treat Git as plumbing. It works, it stays quiet, and nobody budgets compute for it. At Uber that assumption falls apart. Their automation systems call Git millions of times a day across monorepos covering Go, Java, Python, web, Android, and iOS. Reading a file, checking for a merge conflict, rebasing a branch, pushing a derived reference. Every one of those operations ran, in the old model, on a host that held a full local checkout of a multi-gigabyte repository.
The bill shows up in three places: compute, I/O, and the load that thousands of independent clones and fetches slam onto the upstream Git servers, which then get slow and hard to scale. So Uber built GitFarm, a Git-as-a-Service platform that exposes Git operations over a gRPC API. In production since early 2025, it cuts client-side resource use by more than 80 percent and hands you a ready checkout in under a second.
What GitFarm is (and deliberately isn't)
It is not a source control system. There is no new data model and no new way to store code. GitFarm is a centralized Git client. It runs standard Git commands on your behalf, remotely. Your service stops owning the repository and instead asks GitFarm to do the work for it.
A gateway authenticates and authorizes every request, then routes it to backend clusters. Commands run inside isolated, ephemeral sandboxes. Behind those sandboxes, the backend keeps bare repository clones in sync with upstream using push-based updates and periodic fetches. It also keeps pools of pre-warmed checkouts and sandbox containers. When a request lands, GitFarm mounts a checkout that already exists into a free sandbox instead of cloning anything from scratch. That pooling is the whole trick, and it is what gets the ready-checkout time under 500 milliseconds.
How a request flows through it
The interesting design choice is that a single session can run multiple commands against the same checkout. Fetch a branch, compute a merge base, push a derived reference, all without re-initializing repository state between steps. Uber gets this with bidirectional gRPC streaming, so a workflow stays attached to one live checkout for as long as it needs. If a client genuinely needs the freshest upstream state, it issues an explicit fetch. If the workload tolerates bounded staleness, it just uses the state the backend already has.
a GitFarm session is a stream of commands on one checkout:
fetch release/2026-09-25
merge-base main release/2026-09-25
push refs/audit/2026-09-25
That last bit is worth pausing on, because it is where a lot of Git tools get clumsy. Most run-Git-for-me options are stateless and make you pay the clone tax on every single call. GitFarm bets that most real workflows are multi-step and stateful, and it prices the API around that assumption.
The numbers that made it worth building
Two internal case studies do the talking. A code ownership service dropped its local checkouts across six hosts. CPU went from more than 70 cores to 16, memory from 400 GB to 32 GB, and startup time from 15 to 20 minutes down to under one minute. A compliance auditing service, chewing through 10,000 to 20,000 events an hour across 9,000 repositories, cut median latency from 110 to 160 seconds under Buildkite down to 20 to 30 seconds with GitFarm, simply by deleting the scheduling, workspace initialization, and repository sync overhead that used to wrap every run.
I would frame the real win as removing a cold start entirely. A 15-minute host-level cold start was the old floor. GitFarm replaces it with a sub-second mount. The CPU and memory savings are the bonus you get when you stop paying for six redundant copies of the same multi-gigabyte repository.
Why 2026 coding agents make this more relevant, not less
There is a forward-looking reason this pattern is landing right now. Coding agents do not behave like a human running a handful of git commands. They search, branch, diff, experiment, retry, and validate changes, often all at once and concurrently. Each of those is more Git infrastructure load on top of a repo that is already big. An Uber engineer flagged exactly this: agents multiply the Git workloads a monorepo already generates. A service that answers those operations from pre-warmed, pooled checkouts fits agent traffic far better than a fleet of hosts each cloning the world.
When it is the wrong tool
GitFarm is very specific to a particular shape of problem: many services, large monorepos, high call volume, and Git work that is mostly read-heavy and multi-step. If you have one or two services and a small repository, a local checkout costs you almost nothing and you do not need a gateway, sandboxes, and a pool. The roadmap (streaming output, sparse checkouts, bare workspaces, longer-lived sessions, repository mirroring, SubmitQueue integration) is all about stretching the reach further, but today it earns its complexity at Uber's scale, not necessarily at yours.
The broader lesson is the one that keeps repeating across distributed systems. When a piece of plumbing is being done redundantly by hundreds of clients, the fix is usually to make it a shared service backed by a warm pool, not to make every client faster at the thing it probably should not be doing in the first place.
Comments