What is a monorepo?

A monorepo (short for “monolithic repository”) is a single Git repository that contains multiple projects. Instead of having separate repos for your frontend, backend, and shared libraries, everything lives in one place.

Google, Meta, Microsoft, and Uber all use monorepos. But that doesn’t mean you should — it depends on your situation.

Monorepo vs. multi-repo

Multi-repo (one repo per project):

github.com/company/web-app        ← React frontend
github.com/company/api-server     ← Node.js backend
github.com/company/shared-utils   ← Shared library
github.com/company/mobile-app     ← React Native app

Monorepo (one repo, multiple projects):

github.com/company/platform
  ├── apps/
  │   ├── web/          ← React frontend
  │   ├── api/          ← Node.js backend
  │   └── mobile/       ← React Native app
  ├── packages/
  │   ├── shared/       ← Shared utilities
  │   ├── ui/           ← Component library
  │   └── config/       ← Shared ESLint/TS config
  └── package.json

Why use a monorepo?

Shared code is easy. Change a shared component, and every app that uses it gets the update immediately. No publishing packages, no version mismatches.

Atomic changes. Need to update the API and the frontend at the same time? One PR, one review, one merge. In multi-repo, that’s two PRs that need to be coordinated.

Consistent tooling. One ESLint config, one TypeScript config, one CI pipeline. Every project follows the same standards.

Easier refactoring. Rename a function in the shared library and update all consumers in the same commit.

Monorepo ≠ monolith

This is the most common misconception. A monolith is a single deployable application where everything is tightly coupled. A monorepo is just a repository structure — the projects inside can be completely independent microservices.

	Monorepo	Monolith
What it is	One repo, many projects	One app, one deployment
Coupling	Projects can be independent	Everything is tightly coupled
Deployment	Each project deploys separately	One big deployment
Scaling	Scale individual services	Scale the whole thing

Google runs thousands of independent services from a single monorepo. The repo is shared, the services are not.

Related: Monolith vs Microservices

Why NOT use a monorepo?

Complexity. You need specialized tools (Turborepo, Nx, pnpm workspaces). Simple npm install doesn’t cut it.

CI gets slow. Changing one file triggers builds for everything unless you set up smart caching.

Access control. Everyone can see everything. If teams need isolated repos, monorepos make that harder.

Git gets slow. Very large monorepos (millions of files) can make Git sluggish.

Tools

Tool	What it does
pnpm workspaces	Package management for monorepos
npm workspaces	Same, built into npm
Turborepo	Build system with caching (by Vercel)
Nx	Full monorepo framework with plugins
Lerna	Older tool, now maintained by Nx

Turborepo and Nx are the most popular monorepo frameworks in the JavaScript ecosystem. Turborepo focuses on speed through caching, while Nx offers a more opinionated, full-featured approach with generators and plugins.

Real-world monorepo examples

• Google — One of the largest monorepos ever, containing billions of lines of code across nearly all of their products
• Meta — React, Jest, Relay, and other open-source projects all live in Meta’s monorepo
• Microsoft — Uses a monorepo for Rush, TypeScript tooling, and many internal projects
• Vercel — Next.js, Turborepo, and the Vercel CLI are developed in a monorepo
• Babel — The JavaScript compiler uses a Lerna-based monorepo with 100+ packages

Most open-source monorepos you’ll encounter use Turborepo, Nx, or Lerna for orchestration.

Quick setup with pnpm

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'

// Root package.json
{
  "private": true,
  "scripts": {
    "dev": "turbo dev",
    "build": "turbo build",
    "test": "turbo test"
  }
}

See: pnpm cheat sheet for workspace commands.

When to use a monorepo

Yes if:

• You have 2+ apps sharing code (frontend + backend, web + mobile)
• You want consistent tooling across projects
• Your team is small-to-medium and works across projects
• You’re building a component library used by multiple apps

No if:

• You have one app
• Teams are completely independent and don’t share code
• You don’t want to learn monorepo tooling
• Your projects use completely different tech stacks

Related: What is a Microservice? A Simple Explanation for Developers Related: GitHub vs. GitLab — Which Platform Should You Use? Related: What is Docker? A Simple Explanation Related: Git complete guide