Tools & Infrastructure

Monorepo vs Multi-Repo

When your codebase grows past a certain point, one big question appears: should you keep everything in one place, or split it across multiple repositories?

Scroll to start

01 — The Concept

Two Ways to Organize Code

Imagine your code is like a library. A monorepo is like keeping every book on one giant shelf in the same room. A multi-repo (also called polyrepo) is like having a separate shelf — and a separate room — for each topic.

In tech terms: a monorepo is one single repository (folder tracked by Git) that holds all your projects, packages, and code in one place. A multi-repo has a different repository for each project or team.

Google, Meta, and Airbnb all use monorepos for their main code. Many smaller teams start with one project and slowly split into many repos as things grow.

02 — Why It Matters

The Trade-Off That Affects Your Whole Team

The choice matters because it changes how your team works day to day. A monorepo makes it easy to share code between projects and make sure everything stays up to date. A multi-repo gives each team more freedom to move fast and choose their own tools.

But the downside is real too. A monorepo can get slow and hard to manage as it grows. A multi-repo can create duplicated work and headaches when a shared piece of code needs updating across dozens of repos.

💡 Key Insight

There's no perfect answer. The best choice depends on how many teams you have, how independent those teams need to be, and how much shared code connects your projects. Most startups start multi-repo and wish they had gone monorepo. Most large orgs go monorepo and wish they'd stayed multi-repo.

03 — How It Works

The Two Approaches Side by Side

Here's how the two approaches compare in practice:

Monorepo

✅ One place for all code — easy to find everything
✅ Share code between projects instantly
✅ One CI/CD pipeline to maintain
✅ Easy to make large changes across all projects at once
⚠️ Repository can get very large and slow to clone
⚠️ All teams share the same review and deploy process
⚠️ Requires more tooling to keep organized (Nx, Turborepo, Bazel)

Multi-Repo

✅ Each team is fully independent — move at their own pace
✅ Repos stay small and fast to clone
✅ Teams pick their own tools and release cycles
⚠️ Copy-pasting code between repos becomes common
⚠️ No easy way to see how a change affects other projects
⚠️ Each repo needs its own CI/CD setup and maintenance
⚠️ Keeping shared libraries in sync is a full-time job

04 — Practical Example

Visualizing the Difference

Imagine you're building a web app, a mobile app, and a backend API. Here's how the two approaches look:

Monorepo Structure

my-company/
├── apps/
│   ├── web-app/
│   ├── mobile-app/
│   └── api-server/
├── packages/
│   ├── shared-ui/
│   ├── shared-utils/
│   └── shared-types/
├── .github/workflows/
│   └── ci.yml
└── package.json

Multi-Repo Structure

github.com/my-company/
├── web-app-repo/
├── mobile-app-repo/
├── api-server-repo/
├── shared-ui-repo/
├── shared-utils-repo/
└── shared-types-repo/

In the monorepo, if you update shared-types, every app immediately sees the change when they pull. In the multi-repo, you'd need to publish a new version of shared-types and then manually update each app's dependency — which can become a real headache with 6+ repos.

05 — Test Yourself

Knowledge Check

Test what you learned with this quick quiz.

Quick Quiz — 3 Questions

Question 1

What is a monorepo?

Question 2

What is one main advantage of a multi-repo approach?

Question 3

What is a common downside of a monorepo as it grows very large?