Setup MonoRepo in Nest.js

Published: (January 16, 2026 at 11:14 PM EST)
4 min read
Source: Dev.to

Source: Dev.to

Monorepos are becoming the default choice for backend teams that manage more than one service or shared library. Nest.js works very well in a monorepo setup, and it even has built‑in support for it.

In this post you’ll learn:

  • What a monorepo is and why it’s useful
  • How Nest.js supports monorepos
  • How to set up a Nest.js monorepo step‑by‑step
  • A clean folder structure that scales
  • Common tips and pitfalls

No fluff. Just what you need to get it working.

What Is a Monorepo?

A monorepo is a single repository that contains multiple applications and shared libraries.

Instead of having separate repos:

api-repo/
auth-repo/
shared-utils-repo/

you have one repo with a unified layout:

backend/
 ├─ apps/
 └─ libs/

Why Teams Use Monorepos

  • Shared code lives in one place
  • Easier refactoring across projects
  • One set of tooling and configs
  • Simpler dependency management

For Nest.js projects with microservices, background workers, or shared modules, a monorepo is a natural fit.

Nest.js Monorepo Support (Built‑In)

Nest.js comes with first‑class monorepo support via the Nest CLI. You don’t need Nx or Turborepo to get started—the CLI can generate apps and libraries inside one workspace.

Benefits

  • Simple
  • Official
  • Easy to maintain

Monorepo Folder Structure

The structure we’ll build:

nest-monorepo/
├─ apps/
│  ├─ api/
│  └─ auth/
├─ libs/
│  ├─ common/
│  └─ database/
├─ nest-cli.json
├─ tsconfig.base.json
└─ package.json

Meaning

  • apps/ → runnable Nest.js applications
  • libs/ → shared modules, services, DTOs, helpers
  • common/ → filters, guards, interceptors
  • database/ → Prisma, TypeORM, or other DB logic

Architecture Diagram

Nest.js Monorepo Architecture

Image idea: a single repository box containing apps/api, apps/auth, and shared libs/common & libs/database with arrows indicating shared usage.

Step‑by‑Step Setup

Step 1: Create a New Nest.js Workspace

Make sure the Nest CLI is installed:

npm i -g @nestjs/cli

Create a monorepo workspace:

nest new nest-monorepo

During setup choose npm, yarn, or pnpm and optionally enable ESLint and Prettier. Nest automatically creates a workspace‑ready project.

Step 2: Enable Monorepo Mode

Edit nest-cli.json to enable monorepo mode:

{
  "monorepo": true,
  "root": "apps/api",
  "sourceRoot": "apps/api/src",
  "projects": {}
}

Setting "monorepo": true tells Nest this repo will contain multiple apps and libraries.

Step 3: Create Your First Apps

Generate the api app:

nest generate app api

Generate the auth app:

nest generate app auth

Resulting apps/ folder:

apps/
├─ api/
└─ auth/

Each app is a fully independent Nest.js application.

Step 4: Create Shared Libraries

Create a common library:

nest generate library common

Create a database library:

nest generate library database

Resulting libs/ folder:

libs/
├─ common/
└─ database/

Each library includes its own module, tsconfig, and clean import paths.

Step 5: Import a Library Into an App

Example: use CommonModule in the API app.

// apps/api/src/app.module.ts
import { Module } from '@nestjs/common';
import { CommonModule } from '@app/common';

@Module({
  imports: [CommonModule],
})
export class AppModule {}

The @app/* alias is auto‑configured by Nest, so you avoid relative‑path mess.

Step 6: Run Apps Independently

Run the API app:

nest start api

Run the Auth app:

nest start auth

Each app:

  • Has its own port
  • Has its own environment variables
  • Can be deployed separately

Step 7: Build for Production

Build a specific app:

nest build api

Build all apps:

nest build

Compiled output goes to the dist/ folder, separated by app name.

Best Practices for Nest.js Monorepos

  • Keep libraries small – each library should solve one problem; avoid dumping everything into common.
  • Avoid circular dependencies – if two apps depend on each other, rethink the design.
  • Share DTOs and interfaces – prevents duplication and keeps APIs consistent.
  • One database library – centralize DB logic instead of duplicating connections.

When NOT to Use a Monorepo

A monorepo might not be ideal if:

  • You have a single small service
  • Teams are fully independent with separate roadmaps
  • Deployment pipelines are vastly different

For most growing backend systems, however, a monorepo is worth the investment.

Final Thoughts

Nest.js monorepos are:

  • Easy to set up
  • Officially supported
  • Scalable for multiple services and shared code

Give it a try, and enjoy the streamlined development experience!

Additional Support

What’s Next?

  • Add Nx on top of this
  • Convert it to a Medium‑style blog
  • Create a real architecture diagram image
  • Add Docker + monorepo deployment

Just let me know what you need.

Back to Blog

Related posts

Read more »