Monorepo Architecture: Nx, Turborepo, and Rush for Large-Scale Projects

Last updated October 2026

Monorepo architecture is the practice of storing multiple related projects — frontend applications, backend services, shared libraries, and configuration packages — in a single version-controlled repository, using build orchestration tools like Nx, Turborepo, or Rush to manage dependencies, caching, and parallel task execution across the codebase efficiently.

What Problem Does a Monorepo Solve?

As software projects grow, teams typically split code into multiple repositories (polyrepo): one for the React frontend, one for the Node.js API, one for the mobile app, one for shared utilities. This seems clean at first but creates compounding problems:

Dependency drift: Each repo has its own package.json. Over 6 months, your frontend uses React 18.3 while your shared component library still targets React 18.0. Testing compatibility across repos becomes a manual coordination problem.

Code duplication: Common utilities (date formatting, validation, API client wrappers, type definitions) get copy-pasted across repos because sharing via a private npm package adds publishing overhead. Eventually, you have three different implementations of the same email validation regex.

Cross-repo changes are painful: A change to a shared API contract requires coordinated PRs across 3-4 repos, merged in the right order, with manual testing between each merge. A monorepo makes this a single PR.

CI/CD complexity: Each repo has its own CI pipeline. When the shared types repo changes, you need to trigger rebuilds in consuming repos — often through fragile webhook chains or manual intervention.

A monorepo solves these problems by co-locating all related code. But a naive monorepo (just putting everything in one repo without tooling) creates a different problem: every npm install takes 10 minutes, every git pull downloads the entire history, and every CI run builds everything. This is where monorepo tools come in.

Comparing the Big Three: Nx vs Turborepo vs Rush

Nx (by Nrwl)

• Approach: Full-featured monorepo framework with code generation, dependency graph visualization, and deep framework integrations
• Language support: JavaScript/TypeScript (first-class), React, Angular, Vue, Node.js, Go, Rust, Java, .NET (via plugins)
• Key features:
  • Intelligent computation caching (local + remote via Nx Cloud)
  • Affected command: only build/test/lint what was changed and its dependents
  • Code generators (scaffolding new apps, libraries, components with best practices)
  • Module boundary enforcement: define which libraries can import from which
  • Dependency graph visualization: nx graph shows the visual dependency tree
  • Task pipeline orchestration: define task dependencies (build must run before test) across all projects
• Best for: Teams wanting an opinionated, comprehensive framework with strong TypeScript and frontend framework support. Ideal for 5-50 developer teams building web applications.
• Pricing: Core is open source. Nx Cloud (remote caching, distributed CI) has a free tier and paid plans starting at $99/month for teams.

Turborepo (by Vercel)

• Approach: Lightweight, fast build orchestration layer. Does less than Nx but does it with minimal configuration
• Language support: JavaScript/TypeScript primarily, though it can orchestrate any command-line task
• Key features:
  • Written in Rust — task hashing and orchestration is extremely fast
  • Minimal configuration: turbo.json defines task pipelines in a few lines
  • Remote caching via Vercel (or self-hosted)
  • Works with any package manager (npm, yarn, pnpm)
  • Incremental adoption: add Turborepo to an existing monorepo without restructuring
• Best for: Teams that want speed improvements without framework lock-in. Excellent for Next.js/Vercel-based projects. Good for 2-20 developer teams.
• Pricing: Open source. Remote caching through Vercel’s free tier includes generous limits; paid Vercel plans for higher usage.

Rush (by Microsoft)

• Approach: Enterprise-grade monorepo manager designed for very large codebases with strict governance requirements
• Language support: JavaScript/TypeScript
• Key features:
  • Phantom dependency prevention: ensures packages only use dependencies they explicitly declare
  • Deterministic installs with shrinkwrap files
  • Strict version policy management across hundreds of packages
  • Automated changelogs and version bumping
  • Built-in support for publishing packages to npm
  • Heft build system for TypeScript compilation with full incremental support
• Best for: Large organizations (50+ developers) publishing many npm packages, needing strict dependency governance. Used by Microsoft’s own teams for projects like SharePoint Framework and FluidFramework.
• Pricing: Fully open source (MIT license).

Setting Up a Monorepo With Nx: Step-by-Step

We will walk through Nx as it has the broadest feature set:

npx create-nx-workspace@latest my-company \
  --preset=ts \
  --nxCloud=skip \
  --packageManager=pnpm

This creates the workspace structure:

my-company/
├── apps/               # Application projects
│   ├── web/            # React/Next.js frontend
│   └── api/            # Node.js/Express backend
├── libs/               # Shared libraries
│   ├── shared-types/   # TypeScript interfaces/types
│   ├── ui/             # Shared React components
│   └── utils/          # Shared utility functions
├── nx.json             # Nx configuration
├── package.json        # Root dependencies
├── pnpm-workspace.yaml # pnpm workspace config
└── tsconfig.base.json  # Shared TypeScript config

Adding an Application:

nx generate @nx/react:application web --directory=apps/web
nx generate @nx/node:application api --directory=apps/api

Adding a Shared Library:

nx generate @nx/js:library shared-types --directory=libs/shared-types

Now both web and api can import from @my-company/shared-types. When you change a type definition, Nx automatically knows to rebuild and retest both consuming applications.

Running Tasks:

# Build only what changed and its dependents
nx affected --target=build

# Run all tests with caching (second run is instant)
nx run-many --target=test --all

# Visualize the dependency graph
nx graph

CI/CD Optimization for Monorepos

The biggest performance concern with monorepos is CI/CD time. Without optimization, every PR triggers a full build of every project. Here is how to solve this:

1. Affected Commands
All three tools support “affected” analysis — comparing the current branch to the base branch and identifying only the projects that were changed or depend on changed code. This can reduce CI time by 60-90%.

# Nx
nx affected --target=build --base=main

# Turborepo
turbo run build --filter=...[main]

# Rush
rush build --changed-projects-only

2. Remote Caching
Store build outputs (compiled code, test results, lint results) in a shared cache. When developer A builds a library on their machine, the cache stores the output. When developer B (or CI) runs the same build with the same inputs, the cached output is downloaded instead of rebuilding.

Time savings: a full build that takes 8 minutes drops to 30 seconds when most outputs are cached.

3. Distributed Task Execution
For large monorepos, Nx Cloud and Turborepo can distribute build tasks across multiple CI agents in parallel. A build that takes 20 minutes on a single machine can complete in 4 minutes across 5 parallel agents.

Migration Strategy: Polyrepo to Monorepo

If you have existing separate repositories, here is the recommended approach:

Phase 1 — New monorepo with shared code only (Week 1-2): Create the monorepo. Move shared libraries (types, utils, UI components) first. Existing apps still live in their own repos and consume shared libs via npm package or git submodule temporarily.

Phase 2 — Move one application (Week 3-4): Move your simplest application into the monorepo. Validate the development workflow: can the team run it locally, test it, and deploy it from the monorepo? Fix any CI/CD integration issues.

Phase 3 — Move remaining applications (Week 5-8): Migrate remaining apps one by one. Keep the old repos as read-only archives. Update deployment pipelines to build from the monorepo.

Phase 4 — Cleanup and optimization (Week 9-12): Consolidate duplicate dependencies, enable remote caching, set up module boundary rules, train the full team on monorepo workflows.

When NOT to Use a Monorepo

• Completely unrelated projects: If your React marketing site and your Python ML pipeline share nothing, putting them in one repo adds coordination overhead without benefits
• Very small teams (1-2 developers): The tooling overhead may not be worth it when a single developer can keep a few small repos consistent manually
• Different deployment frequencies: If your frontend deploys 5 times/day but your backend deploys weekly, monorepo CI changes must be carefully configured to avoid blocking one team with the other’s builds
• Different language ecosystems: A monorepo mixing JavaScript, Python, Java, and Go is possible but each language’s build tooling works differently. The monorepo tools are primarily optimized for the JavaScript ecosystem

Frequently Asked Questions

Does a monorepo mean deploying everything together?

No. A monorepo is a code organization strategy, not a deployment strategy. Each application within the monorepo has its own deployment pipeline and can be deployed independently. The monorepo tools (Nx, Turborepo) help you build and deploy only the applications that changed, not everything.

Will git performance degrade with a large monorepo?

Potentially, but modern solutions exist. For repositories under 5 GB, standard git performs well. For larger repos, git sparse checkout (clone only the directories you need) and git shallow clone (limit history depth) keep performance acceptable. Microsoft uses a monorepo for Windows (300 GB) with their VFS for Git tool. For most companies, git performance is not a practical concern.

Which tool should we choose: Nx or Turborepo?

Choose Nx if you want a comprehensive framework with generators, plugins, and strong opinions about project structure. Choose Turborepo if you want minimal configuration and already have a working monorepo structure — Turborepo layers build orchestration on top without restructuring your code. Choose Rush if you are an enterprise with 50+ developers needing strict dependency governance and automated publishing.

Can we use a monorepo with microservices?

Yes, this is a common and well-supported pattern. Each microservice is a separate application within the monorepo, sharing types, validation logic, and utilities through internal libraries. The monorepo ensures that a change to a shared type is validated against all consuming services at CI time, catching breaking changes before deployment.

How do we handle different teams owning different parts of the monorepo?

Use CODEOWNERS files (GitHub/GitLab feature) to require reviews from specific teams for changes in their directories. Nx’s module boundary rules can enforce that Team A’s code does not depend on Team B’s internal libraries without explicit approval. Combined with branch protection rules, this gives each team autonomy while maintaining the benefits of co-location.