Real Monorepo Case Studies:
Google, Meta, Twitter, Cash App, Proton (2026)

~2 billion lines of code, ~86 TB, 40k commits/day, 25k+ engineers

Google stores almost all of its code in a single repository, called Piper, which runs on their internal distributed file system (Colossus). As of the 2016 paper, the repo had approximately 1 billion files, 86 TB of data, and 25,000+ engineers committing to it daily. The build system, Bazel (released externally in 2015), was developed specifically to handle this scale. Google also built CitC (Clients in the Cloud) for workspace management and Critique for code review. The tooling investment is massive and not transferable to most organisations.

Unified codebase across Android, iOS, web, server

Meta runs a large unified monorepo on a Mercurial-based VCS they forked and renamed Sapling (open-sourced in 2022). The key technical challenge at Meta's scale is that no developer machine can hold the full repo. Meta built EdenFS (Eden Filesystem) to provide virtual file system access: you see all files, only the touched files are materialised locally. Sapling was open-sourced to allow adoption outside Meta.

Backend services consolidated

Twitter's engineering team invented the Pants build system in 2011 to handle their polyglot monorepo (Python, Scala, Java). They open-sourced it in 2012 as the first publicly available hermetic build system for Python. Pants became the tool of choice for Python-heavy polyglot shops. Twitter's use of Pants predates Bazel's external release by 3 years.

Multiple large product-level monorepos

Microsoft uses a hybrid approach: monorepo per product line, separate repos across product domains. VS Code, TypeScript, Office Web, and other JS/TS products each run their own monorepo. Microsoft developed Rush Stack specifically for their JS/TS monorepo needs and open-sourced it. Not all of Microsoft is in one repo: it is a collection of large product-level monorepos.

Go backend services in a monorepo

Uber runs their Go backend services in a monorepo, while other parts of their stack (iOS, Android, web) have separate setups. The Go monorepo approach works well for them because Go's module system and fast compilation times make shared code practical. Uber has published engineering blog posts on their Go build tooling and module management approaches.

JS codebase consolidation (mid-2010s)

Airbnb migrated their JavaScript codebase to a monorepo in the mid-2010s during the early Lerna era. They published engineering blog posts on the migration and the productivity wins they saw. This was an early example of a company at meaningful scale (hundreds of engineers) choosing monorepo for their JS frontend/full-stack code.

~450 JVM services consolidated

Block (formerly Square) consolidated approximately 450 JVM services (Java and Kotlin) from polyrepo into a Bazel-based monorepo. The migration was multi-quarter. The full productivity win took approximately 2 years to realise. This is the most frequently cited real-world data point for large-scale JVM monorepo migration because Block published an honest post-mortem rather than just a success story.

Web engineering stack

Proton's web engineering team moved from a polyrepo to a monorepo in a single weekend cutover. The scope was bounded (web stack, TypeScript), which made the Saturday cutover pattern viable. Proton published a blog post documenting the decision process, migration approach, and results. This is the most accessible case study for mid-size JS/TS teams considering consolidation.