Monorepo
MON-oh-REE-poh
A single repository that contains multiple projects, packages, or services managed together.
A monorepo is a single Git repository that holds multiple projects. Instead of having separate repos for your frontend, backend, shared libraries, and infrastructure, everything lives in one place. Google, Meta, and Microsoft famously use monorepos. The entire codebase, millions of lines of code, lives in a single repository.
The appeal is simplicity in coordination. When you change a shared library, you can update all the code that uses it in the same PR. You can run tests across all affected projects in one CI pipeline. You can search the entire codebase in one place. Refactoring a shared type or API does not require coordinating across five repos with five different PR processes.
The trade-off is complexity in tooling. Standard Git slows down with large monorepos. Standard CI/CD pipelines waste time running tests for unchanged projects. You need specialized tools: Turborepo, Nx, or Bazel for build orchestration. pnpm or Yarn workspaces for dependency management. CODEOWNERS files for granular permissions. The tooling investment pays off for large teams but can be overkill for small ones.
Examples
A startup consolidates three repos into a monorepo.
The team has separate repos for the web app, the API, and a shared component library. Every time the component library changes, developers must publish a new version, then update the web app and API separately. Changes that should take 30 minutes take half a day. They consolidate into a monorepo using Turborepo. Now a component library change, its consumers, and all their tests are in one PR. Deploy time drops from 4 hours to 20 minutes.
A large team uses a monorepo with code ownership.
The company has 200 engineers and a monorepo with 30 projects. CODEOWNERS files define which team owns which directory. The payments team can only approve changes to /packages/payments. The auth team owns /packages/auth. When someone changes a shared utility, the PR requires approval from every team that uses it. This prevents accidental breakage while keeping all code in one searchable, consistent repository.
A team optimizes CI for their growing monorepo.
The monorepo CI pipeline runs all tests on every PR, which takes 45 minutes. Most PRs only touch one or two packages. The team configures Turborepo to detect which packages changed and only run affected tests. A PR that changes only the dashboard package runs 3 minutes of tests instead of 45. The full test suite still runs on merges to main.
In practice
Read more on the blog
Frequently asked questions
When is a monorepo the wrong choice?
When your teams work on completely independent products with no shared code. If the mobile app and the marketing site share nothing, keeping them in the same repo adds complexity without benefit. Also, if your team is small (under 5 engineers) and your projects are simple, the monorepo tooling overhead is not worth it. Start with separate repos. Consolidate when coordination costs become a bottleneck.
What tools do you need for a monorepo?
At minimum: a workspace-aware package manager (pnpm workspaces, Yarn workspaces, or npm workspaces) and a build orchestrator (Turborepo, Nx, or Bazel) that understands the dependency graph and only rebuilds what changed. For larger monorepos, add CODEOWNERS for permissions, a task runner that caches build outputs (Turborepo Remote Cache or Nx Cloud), and branch protection rules that require specific team approvals based on changed files.
Related terms
A repository: the central location where a project's source code and version history are stored.
The process of compiling source code into a runnable application or deployable artifact.
Continuous integration and continuous deployment: automating code testing and delivery to production.
A tool that automates installing, updating, and removing software dependencies for a project.
An architecture where an application is built as a collection of small, independent services.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.