Uber has built GitFarm, a Git as a Service platform that slashed client-side resource consumption by more than 80% across its sprawling monorepos. The company announced the platform in a LinkedIn post, describing how it eliminated local repository clones for client systems by shifting Git operations to a centralized service. Uber's automation infrastructure executes Git commands millions of times daily across monorepos that support Go, Java, Python, Web, Android, and iOS development.

Before GitFarm, each service kept complete repository checkouts for tasks like file reading, change validation, and merge base calculations. Creating a clone of Uber's Go monorepo alone consumed approximately 15 minutes and demanded around six CPU cores, 32 GB of memory, and more than 40 GB of disk space. A code ownership service that adopted GitFarm dropped its local checkouts across six hosts, cutting CPU use from over 70 cores to 16 and memory from 400 GB to 32 GB. Startup time plummeted from 15 to 20 minutes down to under one minute. A compliance auditing service handling 10,000 to 20,000 events hourly across 9,000 repositories saw median latency fall from 110 to 160 seconds with Buildkite to 20 to 30 seconds with GitFarm by removing scheduling, workspace setup, and repository sync overhead.

According to Uber Engineering, the service delivers full Git checkouts in under 500 milliseconds and eliminates historical 10 to 15-minute host-level cold starts. The platform isn't a source control management system but rather a centralized Git client that runs standard Git commands on behalf of other services. GitFarm exposes operations through a high-performance gRPC API, with a gateway that authenticates and authorizes requests before routing them to backend clusters where commands execute in isolated, ephemeral sandboxes. The backend keeps bare repository clones synchronized with upstream repositories via push-based updates and periodic fetches, while maintaining pools of repository checkouts and sandbox containers that allow mounting a pre-warmed checkout into an available sandbox in less than a second instead of building from scratch.

The architecture supports multi-command workflows through bidirectional gRPC streaming sessions, letting commands run sequentially against the same checkout for tasks like fetching a branch, calculating a merge base, and pushing a derived reference without repeatedly resetting repository state. Clients can explicitly run git fetch when they need the latest upstream state, while workloads tolerant of bounded staleness can rely on the backend's synchronized repository state. In production since early 2025, GitFarm's roadmap includes streaming Git output, sparse checkouts, bare workspaces, longer-lived sessions, repository mirroring, and SubmitQueue integration. Ashish Verma noted on LinkedIn that the architecture could support coding agent workloads, which repeatedly search, branch, diff, experiment, retry, and validate changes concurrently, potentially multiplying Git infrastructure demands. The shift from local clones to a shared service turns what was once a significant infrastructure bottleneck into a streamlined operation that scales with Uber's massive automation footprint. As organizations embrace AI-driven development workflows, the tension between developer velocity and infrastructure efficiency will only sharpen, forcing teams to rethink assumptions about where computation should live. Platforms that centralize expensive operations may become table stakes for companies running code at scale, reshaping how engineering teams provision and manage their toolchains.