GitFarm is an example of how Git operations as a service removes bottlenecks in large monorepos. For architects, the focus is not on Git itself, but on how a centralized service changes platform behavior under high load.
When automation starts invoking Git millions of times a day, local checkouts cease to be a convenience and become an infrastructure problem. At Uber, this affected monorepos for Go, Java, Python, Web, Android, and iOS. Previously, individual services maintained full copies of repositories even for simple operations: reading files, validating changes, and calculating merge bases. The cost of this approach was predictable: long cold starts, high CPU, memory, and disk usage.
The pain is especially noticeable in large monorepos. Cloning Uber’s Go repository took about 15 minutes and required approximately 6 CPU cores, 32 GB of memory, and over 40 GB of disk space. This is not just a delay for a single process. It is a recurring tax on the entire system that grows with the number of services, checks, and background tasks. In such conditions, the classic Git workflow begins to compete with core computations for node resources.
Instead of leaving each consumer alone with the repository, Uber moved Git operations to a shared service called GitFarm. Essentially, this is a centralized Git client that executes standard Git commands on behalf of other systems through a high-performance gRPC API. It is not a source code management system, but a layer of execution. This choice is important: it preserves the familiar Git semantics but changes the way access is granted. The trade-off is also clear. A central point emerges that needs to be authenticated, authorized, and scaled, but local clones and repetitive synchronization are eliminated.
Architecturally, GitFarm is structured as a chain of Gateways and backend clusters. The Gateway accepts requests, checks access, and routes them further. On the backend, commands are executed in isolated ephemeral sandboxes. Bare repository clones are stored there, synchronized with upstream repositories through push-based updates and periodic fetches. Additionally, the service maintains pools of repository checkouts and sandbox containers. This allows for a pre-warmed checkout to be placed in a ready sandbox instead of building the environment from scratch each time. According to Uber, this reduces the overhead of preparing a checkout to less than a second.
For system commands, support for multi-command workflows is particularly important. GitFarm operates through bidirectional gRPC streaming sessions, where multiple commands can be executed sequentially in the same checkout. This allows the state not to be recreated at each step. A typical scenario looks like fetching a branch, calculating the merge base, and pushing a derived reference. Meanwhile, the client can explicitly trigger a git fetch if it needs the latest upstream state. If the task allows for bounded staleness, it works faster due to the already synchronized state of the backend.
The effect of this approach is described by Uber through specific consumers. The code ownership service eliminated local checkouts on six hosts. CPU consumption dropped from over 70 cores to 16, and memory decreased from 400 GB to 32 GB. Startup time reduced from 15–20 minutes to less than one minute. This is not a cosmetic improvement. It is a shift in the load profile, where the infrastructure stops servicing the repository at the cost of an entire cluster of resources.
There is also a second important scenario. The compliance auditing service processed 10,000–20,000 events per hour across 9,000 repositories. Median latency fell from 110–160 seconds with Buildkite to 20–30 seconds with GitFarm. The reason is not magic, but the removal of overhead related to scheduling, workspace initialization, and repository synchronization. When these stages are removed from the critical path, the system begins to respond like a service rather than another set of slow jobs.
From an architectural perspective, GitFarm presents a pragmatic path for large engineering organizations. If Git becomes a common infrastructure dependency, it makes sense to serve it as a service. But the cost is also clear: one must manage staleness, isolation, the lifecycle of sandboxes, and the state of repositories. This is why GitFarm’s roadmap includes streaming Git output, sparse checkouts, bare workspaces, longer-lived sessions, repository mirroring, and SubmitQueue integration. The service is set to be in production by early 2025, but it is already addressing a classic platform engineering challenge: eliminating repetitive work closer to the center and freeing compute for truly valuable tasks.