Monorepo

Updated September 30, 20262 min read

In short

A monorepo is a single version control repository that holds the code for many projects, such as several apps, services, and shared libraries, managed together.

What is a monorepo?

A monorepo stores multiple related projects in one repository instead of giving each project its own. A company might keep its web app, mobile app, backend services, and shared UI and utility libraries side by side in folders like apps/ and packages/. The opposite approach, with one repository per project, is called a polyrepo or multi-repo setup.

The main advantage is that everything can change together. A developer can update a shared library and every project that uses it in a single commit and pull request, which makes large refactors atomic and avoids juggling version numbers between repositories. Monorepos also make it easy to share code, tooling, and configuration, and to see how projects depend on each other.

A monorepo is like a family keeping all its important documents in one well-organized filing cabinet instead of in boxes scattered across different houses. Everyone knows where things are, but the cabinet needs a good system as it grows. At scale, monorepos rely on specialized tools to avoid rebuilding and retesting everything on every change: workspaces in npm, pnpm, and Yarn link local packages together, and build systems such as Nx, Turborepo, and Bazel cache results and run only the tasks affected by a change.

A monorepo is not the same as a monolith. A monolith is a single application deployed as one unit, while a monorepo can contain many independently deployed microservices; the term describes where code is stored, not how it runs. Monorepos do bring trade-offs, such as slower Git operations on very large histories, the need for clear code ownership rules, and CI pipelines that must be smart about what to build.

Key takeaways

A monorepo keeps many projects and shared libraries in one repository.
Cross-project changes can land in a single atomic commit.
Workspaces and build tools like Nx, Turborepo, and Bazel keep builds fast by running only affected tasks.
A monorepo describes code storage, not architecture; it can hold microservices as well as monoliths.
The alternative, one repository per project, is called a polyrepo.

Example

A monorepo with npm workspacesbash

# A typical monorepo layout:
#   apps/web/        customer-facing website
#   apps/api/        backend service
#   packages/ui/     shared UI components
#   package.json     "workspaces": ["apps/*", "packages/*"]

# Install dependencies for every project at once
npm install

# Build just one project
npm run build --workspace=apps/web

# Run tests in every project that has a test script
npm test --workspaces --if-present

Readers ask

What is the difference between a monorepo and a polyrepo?

A monorepo stores many projects in one repository, while a polyrepo setup gives each project its own repository. Monorepos simplify sharing code and making cross-project changes, whereas polyrepos give teams more independence and keep each repository small.

Is a monorepo the same as a monolith?

No. A monolith is an application built and deployed as one unit, while a monorepo is just a way of storing code; a single monorepo can contain dozens of independently deployed microservices.

What tools are used to manage a monorepo?

Package manager workspaces in npm, pnpm, and Yarn link local packages together. Build tools such as Nx, Turborepo, and Bazel add caching and run only the tasks affected by a change, which keeps CI fast as the repository grows.