Setting Up TurboRepo Is Easy… Until You Add Another App

Introduction

Setting up a monorepo is usually a straightforward task, you just run this command:

pnpm dlx create-turbo@latest 

and you think you are done, right ?

The setup feels complete as soon as the command finishes, but in practice, that’s rarely the case.

The command generates a ready-to-use boilerplate with this structure:

apps/
  ├── web/
  ├── docs/
packages/
  ├── ui/
  ├── config/
turbo.json
package.json

At this stage, you simply install the dependencies, and you already have a working Next.js web application along with a ready-to-use Next.js documentation app.

But what if you want to add another application to this structure?

Here I will focus on two cases, but the same approach applies to any framework or library you might want to add: NestJS and Django.

Adding a New Application

First you navigate to apps folder:

cd apps

Then you install your application in the usual way:

• for Nest.js

pnpm dlx @nestjs/cli new api

• for Django

django-admin startproject api

Then you continue by installing the required dependencies for each application. Everything is fine till now, right ?

The First Issue: Application Not Running

However, once you navigate back to the root of your monorepo and try to run everything:

cd ../..
pnpm dev

only the web and documentation applications start, but why ?`

Understanding the Problem

TurboRepo doesn’t “discover” how to start each application automatically, it look for a specific script in each application, this script is “dev”.

You can take a look to the turborepo package.json file and confirm that:

{
	"name": "...",
	"private": true,
	"scripts": {
		"build": "turbo run build",
		"dev": "turbo run dev",
		"lint": "turbo run lint",
		"format": "prettier --write \"**/*.{ts,tsx,md}\"",
		"check-types": "turbo run check-types"
	},
	"devDependencies": {
		...
	},
	...
}

However in the Nest.js case you have this:

{
	"scripts": {
		...
		"start:dev": "nest start --watch",
		...
	},
	...
}

Renaming start:dev to dev allows the monorepo to pick up the application. However, when running it, the service crashes — revealing another issue.

The Second Issue: Port Conflict

The root cause is a port conflict.

By default, both the Next.js application and the NestJS server attempt to run on the same port. As a result, it fails to start.

The solution is straightforward: assign a different port to one of the services.

For example, you can update the NestJS application to run on port 4000:

	await app.listen(process.env.PORT  ??  4000);

Now that the NestJS case is resolved, what about the Django application, which doesn’t belong to the JavaScript ecosystem?

Integrating Django

Unlike NestJS, Django doesn’t rely on a package.json, so TurboRepo has no direct way to detect or run it.

To integrate it into the monorepo workflow, you need to explicitly define how it should be executed.

One practical approach is to add a minimal package.json inside the Django application directory and expose a dev script:

{
    "name": "api",
    "scripts": {
      "dev": "python manage.py runserver 0.0.0.0:8000",
      "migrate": "python manage.py migrate",
      ...
    }
}

This allows TurboRepo to treat the Django app like any other workspace and include it when running, also as before, make sure the Django server runs on a different port to avoid conflicts with other services.

Conclusion

Setting up a monorepo is fast, but integrating multiple applications into the workflow requires more attention.

Whether you’re working with JavaScript frameworks like NestJS or external ecosystems like Django, the key is to make every application conform to the unified interface.

And now you can enjoy your monorepo.