What Is a Monorepo?
A monorepo is a single version-control repository that holds the code for many projects, multiple apps, shared libraries, and services, instead of splitting each into its own separate repository. Teams like Google and Meta use monorepos so related projects can share code, tooling, and a single history, making cross-project changes easier to coordinate. The opposite pattern, called polyrepo, gives each project its own repository. A monorepo is not one giant tangled application; it's one repository containing many clearly separated projects.
- Definition
- One repository holding many projects and shared code
- Opposite
- Polyrepo, a separate repository per project
- Notable users
- Google, Meta, and Microsoft run large monorepos (monorepo.tools)
- Common tooling
- Nx, Turborepo, Lerna, and pnpm/Yarn workspaces (Nx docs)
- Not the same as
- A monolith (one deployable app); a monorepo can hold many apps
What a monorepo really is #
A monorepo, short for monolithic repository, is a single code repository that contains multiple distinct projects. Inside it you might find a customer-facing website, an internal admin dashboard, a shared component library, and a few small services, each in its own folder but all versioned together under one repository. The key idea is unified storage: everything lives in one place, shares one commit history, and can be changed together in a single coordinated update. This is not a new invention; large engineering organizations have used the pattern for decades because it simplifies sharing code across many projects. The alternative, giving every project its own repository, is common too, and neither is inherently right. A monorepo simply trades some isolation for tighter integration and easier code sharing. For agencies juggling several client sites or a business running a website plus companion tools, understanding the monorepo pattern clarifies how a modern /services/web-app-development codebase can be organized as it grows beyond a single application.
Monorepo versus polyrepo #
The counterpart to a monorepo is the polyrepo approach, where each project, each app, each library, each service, gets its own separate repository. Most small projects start as polyrepos simply because they begin as one thing. The difference becomes meaningful once several related projects share code or need to change in lockstep. In a polyrepo world, updating a shared component means publishing a new version, then updating each consuming project separately and hoping nothing drifts out of sync. In a monorepo, that same change happens in one commit across every affected project, with tests running against all of them at once. The trade is real: polyrepos give strong isolation and independent release schedules, while monorepos give unified tooling and atomic cross-project changes at the cost of a larger, busier repository. Choosing between them depends on how tightly coupled your projects are and how much they share, not on which is fashionable, and the honest answer is that both patterns run successful products at scale.
A monorepo is not a monolith #
A common misunderstanding is to equate 'monorepo' with 'monolith,' but they describe different things. A monolith is an architectural style where one large application handles everything in a single deployable unit. A monorepo is purely about code storage, how many repositories you use, and says nothing about how the software is deployed. You can have a monorepo containing dozens of small, independently deployed services, which is the opposite of a monolith. You can also have a monolith living in its own repository. The two words are often confused because both start with 'mono,' yet they answer separate questions: a monolith answers 'how is the app structured and deployed?' while a monorepo answers 'how is the code organized in version control?' Keeping them distinct matters when a developer proposes a structure for your project, because a monorepo can hold a clean set of modern, separately deployed pieces without any of the rigidity people associate with a traditional monolithic /services/web-app-development build.
A typical monorepo layout #
Monorepos usually group deployable apps and shared code into top-level folders, wired together with workspaces.
my-company/
apps/
website/ # public site
admin/ # internal dashboard
packages/
ui/ # shared components
utils/ # shared helpers
package.json # workspaces config
turbo.json # build pipeline
// package.json
{
"workspaces": ["apps/*", "packages/*"]
}The advantages of a monorepo #
Monorepos shine when projects share code and need to evolve together. The biggest win is code reuse without publishing overhead: a shared UI or utility package sits right there, and every app uses the current version instantly. Cross-cutting changes become atomic, updating a shared function and every consumer in one commit, with a single test run catching breakage everywhere. Tooling is unified too: one set of linting, formatting, and build configuration applies across all projects, reducing drift and 'it's set up differently over here' friction. Onboarding can be simpler, since a new developer clones one repository and sees the whole system. Refactoring across boundaries is far easier than coordinating many separate repos. For an agency maintaining a portfolio of related tools, or a business whose site, admin panel, and marketing pages share components, these benefits compound. They translate into fewer version-mismatch bugs and faster changes, which is why so many mature engineering teams adopt the pattern despite the added tooling it requires.
The drawbacks and costs #
Monorepos are not free of downside. As the repository grows, it can become large and slower to clone, and naive builds may rebuild everything on every change unless smart tooling only rebuilds what changed. That tooling, task runners, caching, dependency graphs, adds setup complexity that a simple single-project repo never needs. Access control is coarser: everyone with repository access typically sees all projects, which can be undesirable when different clients or teams should stay separated. Continuous-integration pipelines get more intricate, since a commit might touch several projects at once. And a broken shared package can ripple outward, briefly affecting many apps until it's fixed. None of these are dealbreakers, but they mean a monorepo pays off mainly when the sharing and coordination benefits outweigh the tooling investment. For a single small website with no companion apps, a monorepo is usually overkill, adding machinery you do not need to manage during routine /services/care-plans maintenance. The pattern earns its keep only when the coordination it enables outweighs the ongoing tooling it demands.
The tooling that makes it work #
A monorepo at any real scale relies on tooling to stay fast and manageable. Package managers provide 'workspaces,' a built-in way for npm, Yarn, or pnpm to link multiple projects in one repository so shared packages resolve locally without publishing. On top of that sit build systems like Nx and Turborepo, which understand the dependency graph between projects and rebuild or test only what a change actually affects, caching the rest. Lerna, an older tool, helped popularize the pattern for publishing many packages. These tools solve the monorepo's central challenge: doing work proportional to what changed, not to the size of the whole repository. Without them, a large monorepo would grow painfully slow. With them, teams get the sharing benefits while keeping builds quick. For a business, the specifics rarely matter, but knowing these names helps you recognize a well-organized codebase and ask whether a growing /services/web-app-development project has the tooling to scale cleanly rather than seizing up.
When a monorepo suits a smaller team #
You do not have to be Google to benefit from a monorepo, but the case has to fit. It's worth considering when you have two or more projects that genuinely share code, say a public website and an admin dashboard built from the same component set, or when a small team wants one place to manage everything with consistent tooling. Agencies sometimes group a client's related sites and tools this way for easier maintenance. It's usually not worth it for a single standalone site, a one-off marketing page, or projects that share nothing and belong to different clients who need isolation. The honest test is simple: are these projects changing together and sharing meaningful code? If yes, a monorepo reduces friction. If they're independent, separate repositories keep things simpler. Starting small and consolidating later is perfectly reasonable, so this rarely needs deciding up front, especially early in a /services/website-redesign when the shape of the system is still settling.
What it means for an agency or business #
For a business or agency, the monorepo question is really about scale and coordination, not fashion. If you run a single website, it simply will not come up, and that is fine. But as an operation grows, say a public site, a customer portal, and an internal dashboard that share branding and components, the way that code is organized starts to affect cost and reliability. A well-structured monorepo can make shared changes faster and reduce the version-mismatch bugs that plague loosely connected projects, while a poorly tooled one can become slow and unwieldy. The practical signals of a healthy setup are unified tooling, a clear folder structure, and build tools that only rebuild what changed. You do not need to manage any of this yourself, but understanding the concept lets you ask a developer sensible questions about how a multi-project codebase will be maintained. Whether it lives in one repository or several, what matters is that a /services/care-plans arrangement keeps every project patched, tested, and reliably deployed over time.
FAQ
Is a monorepo the same as a monolith?
No. A monolith is an architecture where one application does everything in a single deployable unit. A monorepo is about code storage, many projects in one repository, and says nothing about deployment. A monorepo can contain many small, independently deployed apps, which is the opposite of a monolith. The similar names cause the confusion.
Do small businesses need a monorepo?
Usually not for a single website. Monorepos pay off when you maintain several projects that share code, a site plus an admin dashboard or companion tools, for instance. For one standalone site, a monorepo adds tooling and complexity with little benefit. Start with a simple repository and consider consolidating only if related projects accumulate over time.
What tools are used to manage monorepos?
Package-manager workspaces in npm, Yarn, or pnpm link the projects together, and build systems like Nx or Turborepo speed things up by rebuilding only what changed and caching results. Lerna is an older option for publishing many packages. These tools keep a growing monorepo fast, which is essential once it holds several projects.
What's the difference between a monorepo and a polyrepo?
A monorepo stores many projects in one repository; a polyrepo gives each project its own separate repository. Monorepos make sharing code and coordinating changes easier but grow large; polyrepos keep projects isolated with independent release schedules but make shared changes more work. Both approaches run successful products; the right choice depends on how tightly your projects are coupled.
Does a monorepo make my site slower?
No. A monorepo affects how code is stored and built, not how your live website performs for visitors. Site speed depends on the deployed application, hosting, and optimization, not repository structure. A monorepo can, if poorly configured, make developer builds slower, but that's an internal workflow concern, not something your visitors ever experience.
Can I switch from separate repos to a monorepo later?
Yes. Many teams start with separate repositories and consolidate once several projects begin sharing code. Merging repos while preserving history is a known, doable process, though it takes planning. Because you can migrate later, there's rarely pressure to choose a monorepo up front; adopt one when the sharing benefits clearly appear.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?