Uber has built GitFarm, a Git as a Service platform for running Git operations across its large scale monorepos. By moving repository operations to a shared service, GitFarm eliminates local clones for client systems and has reduced client side resource utilization by more than 80%.
Uber’s automation systems invoke Git millions of times per day across monorepos supporting Go, Java, Python, Web, Android, and iOS. Previously, individual services maintained full repository checkouts, including for operations such as reading files, validating changes, and calculating merge bases. Cloning Uber’s Go monorepo takes roughly 15 minutes and requires about six CPU cores, 32 GB of memory, and more than 40 GB of disk.
Uber Engineering said in a LinkedIn post describing GitFarm that the service provides full Git checkouts in under 500 milliseconds and removes historical 10 to 15-minute host-level cold starts.
Local cloning and repetitive repository syncing turn traditional Git workflows into a significant infrastructure bottleneck
GitFarm architecture (Source: Uber Blog Post)
GitFarm exposes Git operations through a high-performance gRPC API. It is not a source control management system. Instead, it acts as a centralized Git client that executes standard Git commands on behalf of other services. A Gateway authenticates and authorizes requests before routing them to backend clusters, where commands run in isolated, ephemeral sandboxes.
The backend maintains bare repository clones and keeps them synchronized with upstream repositories using push-based updates and periodic fetches. It also maintains pools of repository checkouts and sandbox containers. When a request arrives, GitFarm can mount a pre-warmed checkout into an available sandbox instead of creating a repository clone and execution environment from scratch. Uber reports that this pooling reduces the overhead of providing a ready-to-use checkout to less than a second.
GitFarm supports multi-command workflows through bidirectional gRPC streaming sessions. Commands can execute sequentially against the same checkout, allowing workflows such as fetching a branch, calculating a merge base, and pushing a derived reference without repeatedly initializing repository state. Clients can also explicitly run git fetch when they require the latest upstream state, while workloads that tolerate bounded staleness can use the backend’s synchronized repository state.
GitFarm Backend architecture (Source: Uber Blog Post)
Uber reports that a code ownership service eliminated local checkouts across six hosts after adopting GitFarm, reducing CPU consumption from more than 70 cores to 16 and memory from 400 to 32 GB. Startup time fell from 15 to 20 minutes to less than one minute. A compliance auditing service processing 10,000 to 20,000 events per hour across 9,000 repositories reduced median latency from 110 to 160 seconds with Buildkite to 20 to 30 seconds with GitFarm by eliminating scheduling, workspace initialization, and repository synchronization overhead.
The architecture could also support coding agent workloads. Ashish Verma noted on LinkedIn that agents repeatedly search, branch, diff, experiment, retry, and validate changes, concurrently, potentially increasing Git infrastructure workloads.
In production since early 2025, GitFarm’s roadmap includes streaming Git output, sparse checkouts, bare workspaces, longer-lived sessions, repository mirroring, and SubmitQueue integration.