---
title: "GitFarm: Git® as a Service for Large-Scale Monorepos"
description: "At Uber’s monorepo scale, traditional Git workflows create bottlenecks through multi-gigabyte clones, local checkouts, repeated synchronization, and independent fetch or push operations across automation systems. The post describes GitFarm, a Git as a Service platform exposed through a high-performance gRPC API that executes standard Git commands in secure, ephemeral sandboxes backed by pre-warmed repository and container pools. Each backend maintains a bare clone, receives push-based updates and periodic git fetch operations every five minutes, while clients can explicitly fetch when they need current state. The design provides a full checkout in under 500 milliseconds and reduced client-side resource utilization by over 80%, while avoiding local clones and long initial clone delays."
---

# GitFarm: Git® as a Service for Large-Scale Monorepos

[Uber](https://yomu.fyi/company/uber) · Jul 9, 2026

**Type:** Problem & solution

## Summary

At Uber’s monorepo scale, traditional Git workflows create bottlenecks through multi-gigabyte clones, local checkouts, repeated synchronization, and independent fetch or push operations across automation systems. The post describes GitFarm, a Git as a Service platform exposed through a high-performance gRPC API that executes standard Git commands in secure, ephemeral sandboxes backed by pre-warmed repository and container pools. Each backend maintains a bare clone, receives push-based updates and periodic git fetch operations every five minutes, while clients can explicitly fetch when they need current state. The design provides a full checkout in under 500 milliseconds and reduced client-side resource utilization by over 80%, while avoiding local clones and long initial clone delays.

## Context

At Uber, automation systems and developer services invoke Git millions of times per day across multiple monorepos. Maintaining separate full checkouts caused high compute, memory, storage, I/O, and upstream Git-server costs; cloning the Go monorepo alone takes roughly 15 minutes and uses about 6 CPU cores, 32 GB of memory, and over 40 GB of disk.

## Approach / What changed

GitFarm centralizes Git client operations behind a high-performance gRPC API. A Gateway authenticates, authorizes, and routes requests using Redis-tracked sandbox availability; backend nodes maintain bare repository clones, synchronize through push-based updates and five-minute fetches, and execute commands in identity-scoped, ephemeral sandboxes with pre-warmed repository and container pools.

## Takeaways

- GitFarm is not a Git SCM: it executes standard Git commands on behalf of services but does not store, replicate, or serve repositories.
- Repository freshness is configurable per request: clients can run an explicit git fetch for current state, or rely on eventually consistent backend synchronization to reduce latency and redundant fetches.
- Production use reduced client-side resource utilization by over 80%, and clients can obtain a full Git checkout in under 500 milliseconds.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [gRPC](https://yomu.fyi/topic/grpc), [Scalability](https://yomu.fyi/topic/scalability)

- Source: [Uber](https://www.uber.com/us/en/blog/gitfarm-as-a-service)
- Source URL: https://www.uber.com/us/en/blog/gitfarm-as-a-service
- Ingested by Yomu: 2026-09-11T00:02:01.043Z

[Read original post](https://www.uber.com/us/en/blog/gitfarm-as-a-service)