What is a monorepo? What engineering leaders should know

Do a little digging (you probably already have) and you'll find strong arguments both for and against monorepos.

With your entire codebase in one repo, some say, you'll do nothing you couldn't do with multiple repos, except slow down builds, create "merge hell," and make dependencies a nightmare to deal with. But despite the added complexity, many large engineering teams use them anyway.

So... should you or shouldn't you? As with anything, monorepos solve some problems, for some teams, while creating others. There isn't a "right" answer for everyone, just the answer to which problems you can deal with most easily, and which approach to organization, development, and collaboration you want to take.

What is a monorepo? Monorepo definition

A monorepo is a software development and version control strategy where teams store code for individual projects, libraries, services, or components together in a single repository.

A monorepo structure gives every developer access to the entire codebase, since it's stored in a single repository. This makes it easier to have a "single source of truth" for your codebase, and to share and reuse code across projects within your company.

The alternative is a multi-repo (sometimes called a polyrepo or many-repo) approach, where individual projects are stored in separate repositories.

Monorepo vs. multi-repo

A monorepo is a single repository that houses code for multiple projects; a multi-repo is an approach where each project has its own repository.

Monorepos are well known at large tech companies like Google, Facebook, and Twitter. But they're not just for Big Tech. For example, the global financial platform Brex runs a nearly decade-old monorepo. Monorepos can become complex and messy, but they keep everything in one place.

Many lean teams prefer lots of repos to keep everything organized. For example, they may store the code, components, and libraries for their iPhone app in one repo, while keeping the Android code in another, and so on.

Here's a quick overview of how they stack up:

Monorepo vs. monolith

These terms sound similar, but they describe two different (and not mutually exclusive) things.

A monorepo is an approach to storing code, where all your code lives in a single repo.

A monolith is an approach to software architecture, or how your application runs and is deployed.

You can build a monolithic application with a monorepo or with a multi-repo approach. Or you can use a monorepo but deploy your application as microservices, where individual features or services run and deploy independently but communicate through APIs.

Monorepo pros and cons

A monorepo approach isn't better or worse than a polyrepo approach, but it does come with different considerations.

Here's the quick list, and we'll break down each pro and con below:

Pros of a monorepo

Easier code sharing. A monorepo keeps everything in one place: code for your projects, components, UI libraries, and so on. Your whole team has access to everything and can easily share and reuse code in multiple places. This avoids rewriting boilerplate or reinventing the wheel across your codebase.

High codebase visibility. When everyone has access to the entire codebase, it's easier to track changes, see all branches, evaluate the overall architecture, and keep things organized. Basically, it helps eliminate silos by giving all code a single home.

Simpler refactoring. This matters more as your codebase and team grow. As codebases get older, bigger, and more complex, being able to refactor easily is what keeps them maintainable. Changing code structure or architecture, or refactoring microservices, is much easier when all the code is in one repo than when you have to move or refactor code across many repos.

Streamlined and synchronized workflows. Atomic commits let devs make changes that cross multiple services or packages in a single pull request, updating the relevant code everywhere in the codebase at once. That's a big advantage over needing specialized tooling or multiple coordinated pull requests to change cross-repo dependencies in a polyrepo.

As Dan Luu (software engineer and systems researcher) explains:

"With lots of repos, making cross-repo changes is painful. It typically involves tedious manual coordination across each repo or hack-y scripts. And even if the scripts work, there's the overhead of correctly updating cross-repo version dependencies. Refactoring an API that's used across tens of active internal projects will probably [take] a good chunk of a day. Refactoring an API that's used across thousands of active internal projects is hopeless.

With a monorepo, you just refactor the API and all of its callers in one commit. That's not always trivial, but it's much easier than it would be with lots of small repos."

Cons of a monorepo

Scaling issues. One of the most common concerns about monorepos is scale. As monorepos grow in size and complexity, they can slow down builds and version control operations and become harder to manage. But companies like Google and Meta run monorepos at enormous scale, so scale is not out of the question. The real question is: do you have the resources to invest in developer tooling and experience to scale a monorepo well?

It's also worth considering what Paulus Esterhazy calls "the Fallacy of Scale":

"For the many developers working in small teams, practical problems of repository scalability are not likely to come up in the near term."

Can monorepos get hard to scale at some point? Of course. But many teams worry far too early about scale problems that may never show up. Meanwhile, they pass on a setup (a monorepo) that could work well for them right now.

Complexity. Monorepos simplify some things (refactoring, access, code sharing) but add complexity elsewhere. As a monorepo grows, there's more code, more cross-file dependencies, and more context, until no single engineer knows how everything connects. Build times and CI overhead also tend to grow unless you invest in build and caching tools built for monorepos (which you should).

Code review has to be stronger. Mistakes in a monorepo can reach more files, often unintentionally. Shared code, complex dependencies, and complex architecture mean bugs can be harder to find, affect more surface area, and create accidental dependencies. That's even more true with agentic coding. AI tools can make contextual, logical, or architectural errors, and in a monorepo, an AI-written change has more ways to break code somewhere else.

Monorepo best practices in 2026

So let's say you have a monorepo, or you're moving to one. How do you avoid the pitfalls while getting the most out of the advantages?

A monorepo is a repo that gets more complex as it grows, so most of what matters is standard engineering practice. A few things to keep in mind:

• Invest in developer experience and tooling early. With a monorepo, this pays off more and more as your codebase and team grow. There's more inherent complexity around builds, deployment, and testing, and good tooling keeps that complexity from slowing everyone down.
• Use modern build tools designed for the complexity and scale of monorepos. Modern build and CI/CD tools significantly cut build times and make it easier to merge branches, rebuild only what changed, and manage dependencies.
• Do the same for code review tools. In a monorepo, your code review tool really needs to understand your codebase, or most of what it says will be noise. Code review tools should automate (at least) the first pass of review while indexing and accounting for your entire codebase, as Greptile does. (For why that's harder than it sounds, see why codebases are uniquely hard to search semantically.)
• Keep things organized and well labeled. Monorepos, like all systems, drift toward entropy unless you push back. With everything in one place, you need an organization system that makes sense for your codebase. A good rule of thumb: "If it changes together, it stays together."
• Consider trunk-based development to avoid merge hell. In a monorepo, a strategy of small, frequent merges matters even more. Keep branches short-lived and merge small commits often rather than letting long-running branches drift. (PR size affects review in less obvious ways too; see what we found when we asked whether larger PRs get merged faster.)

Monorepo tools you should know

The right tooling can make or break your monorepo experience. If you're moving toward a monorepo, here are the tools to know:

Nx

Nx is a build system and developer toolkit that makes building and scaling monorepos faster and less resource-heavy. It helps with:

• Build speed (via caching). Nx caches builds, tests, and lints (locally, and remotely with Nx Cloud) so you can skip re-running anything that hasn't changed.
• Project graph analysis. It maps the dependencies between every project in your repo, so you can see what a change will touch before you make it.
• Fewer whole-repo checks. It uses the project graph to work out what your change affects and runs tasks for only those projects, cutting local build time and speeding up CI.
• Task orchestration. It coordinates task dependencies automatically.

Choose Nx if: your codebase is mostly JavaScript/TypeScript and you want a build system focused on developer experience.

Turborepo

Turborepo covers similar ground to Nx, but it's a lighter-weight build tool.

Turborepo also offers smart caching, task orchestration, and faster builds, and it's quick and simple to get running. Nx offers a broader feature set beyond running tasks, while Turborepo keeps its scope narrower.

Choose Turborepo if: you're a leaner team that wants speed and simplicity in a build tool rather than a more full-featured toolkit like Nx.

Bazel

Bazel is a build and test tool designed for very large repos. It's the open source version of Google's internal build system, and it's built for polyglot codebases (monorepos that use multiple programming languages). It can handle massive monorepos with multi-million-line codebases and complex dependency graphs.

Bazel uses caching, incremental builds, parallelism, and, most importantly, a test runner that re-runs only the tests that need to run. It's a go-to build system for codebases with millions of lines of code, and a strong choice for any monorepo with many dependencies across multiple languages, which most build tools can't handle well.

Choose Bazel if: you're working with millions of lines of code in a polyglot codebase and need a build tool that will keep scaling with you, despite more setup and a steeper learning curve.

Pants

Pants is to Bazel roughly what Turborepo is to Nx. That's an oversimplification, but it gets at the idea. Pants is also a polyglot build system that helps automate testing, compilation, linting, packaging, and dependency management in monorepos.

It coordinates development tools, reduces build times with smart caching, and supports multi-language monorepos.

Compared with Bazel, it's lighter, faster to get running, and trades some power for ease of use. It also infers dependencies automatically, rather than requiring you to maintain dependency lists in configuration files.

Choose Pants if: you have a polyglot monorepo (especially a Python-centric one) and don't need everything Bazel offers.

Greptile

Greptile is an AI code review tool built for complex codebases and monorepos, with context-aware review and sandbox testing that validates how code actually runs. Any team can use Greptile (it's not monorepo-specific), but a few things make it a strong fit for monorepos:

• Self-updating knowledge base. Greptile builds and indexes a graph of your codebase: where everything lives, how it all fits together, and what touches what. That context is what makes review work in a large, messy monorepo.
• Context-rich review. Many review tools only see the diff. Greptile reviews PRs with the context of your entire codebase. It holds context no single senior dev can keep in their head, and traces issues across files, services, and dependencies to catch bugs a diff-only read misses.
• Self-hosted options for enterprise teams. Greptile can run fully self-hosted, including in air-gapped environments, for teams with strict security requirements.
• Built-in security review. Security gets harder in a complex codebase, too. Greptile combines rule-based scanning, software composition analysis (SCA) for known CVEs in your dependencies, and AI security review on PRs to catch vulnerabilities that don't show up in the diff.
• Runtime validation with TREX. TREX runs the change in a sandbox: it installs your dependencies, starts the services the change touches, and exercises the code with targeted tests. When a run fails, it leaves a PR comment with the evidence attached (logs, screenshots, traces, or videos), so your developers can see exactly what went wrong and where.

See how Scale rolled out Greptile to engineers working across Python, Go, TypeScript, and React to ease the code review bottleneck →

Are monorepos better for AI?

Short answer: you can make AI work for you wherever you are. That said, monorepos have some real advantages for agentic coding.

First, AI coding and code review need context. A monorepo is the simplest way to give agents unified, whole-codebase context. An agent can "read" your entire system without hitting repo boundaries and access limits. And a build tool (like Nx or Bazel) or a code review tool (like Greptile) that builds dependency graphs of your codebase can share that structure with your coding agents for even clearer context. (For more on picking agents for a large codebase, see our guide to AI coding tools for complex codebases.)

Monorepos also make it easier for agents to work across files, dependencies, and projects. Atomic commits let agents update shared libraries and the services that use them in one change and keep your codebase aligned, rather than handing off to developers to coordinate commits across repos.

However, monorepos also add complexity that can make agentic coding harder. Agentic coding, especially in a complex monorepo, needs agentic code review that can catch cross-file bugs that don't show up in a diff and are hard for humans to spot. AI can make these kinds of logic errors, and in a monorepo they can spread further.

At the end of the day, your repo setup isn't everything. The right tools can help you use AI and agentic workflows no matter how your code is organized.

We've designed Greptile to work for any setup: complex monorepos, solo devs moving fast, mid-sized teams on multi-repo setups, and everything in between. That's because Greptile's core features make code review easier in any context:

• Context: If you've got a messy monorepo, Greptile maps and indexes your entire codebase for full-context reviews. Small codebase? No problem. If you've got many repos and need cross-repo context, Greptile can read related repositories during review through Repo Clusters, which can hold up to 20 GB of related repositories.
• Runtime validation: TREX works for massive monorepos and lean teams with many repos alike. It uses Greptile's context to spin up disposable sandboxes that run your changes and catch bugs that only show up at runtime.
• Independence and model inversion: Greptile works with any coding agent as an independent, agent-agnostic validation layer, whether you have 10 engineers or hundreds. And model inversion, an experimental feature, routes a review to a different model than the one that wrote the code, since our research found models catch more bugs in code written by another model.

Together, these make Greptile flexible enough for lean teams while handling the complexity of large teams on monorepos.

Make your monorepo easier to manage

So, in our opinion: monorepos are not worse to maintain, just different.

• They're (often) more complex, which takes more care to maintain well.
• They usually need tooling designed for monorepos. That isn't necessarily a downside, but it's worth planning for.
• They often eliminate silos, but need more coordination around builds and merges.

Most importantly, teams running monorepos depend on context. If you're running a monorepo, your tools need to understand and review your codebase the way a senior developer would: in the details, with the big picture in mind. On a codebase so complex that no one knows it end to end, you need tools that can see what everything touches and cover your blind spots.

That's why teams on complex monorepos, like Brex, use Greptile.

Brex has 400+ engineers working in an eight-year-old monorepo across TypeScript, Python, and Go. Other code review tools struggled with that monorepo and technical stack: the feedback was generic and didn't seem to understand how the codebase fit together.

Greptile learns the monorepo's boundaries, call paths, contracts, and test topology, then uses PR diagrams to show exactly what a change touches and where risk clusters. It was the only tool that really caught issues and gave context-aware feedback, and today Greptile reviews 100% of the code Brex writes.

Want to see how much easier and more effective code review gets on your monorepo? Try Greptile free for 14 days →