Hi Kishor,

For IIS, I’d separate the problem into two parts: Turborepo build orchestration and how each Next.js app is served.

Turborepo itself is not something you “deploy” to IIS as one running app. Usually you build each app separately, and the shared packages from packages/ are bundled/compiled into whichever app depends on them.

From the monorepo root, the basic shape is usually:

1
npm install
2
npx turbo run build --filter=app-1
3
npx turbo run build --filter=app-2
4
npx turbo run build --filter=app-3
5

Then for each app you need to decide whether it is static or server-rendered.

If an app is fully static, you can use output: "export" and serve the generated out folder from IIS as static files.

If the app uses SSR, API routes, server actions, image optimization, middleware, etc., IIS should usually sit in front as a reverse proxy while the Next.js app runs as a Node process on a local port, for example:

1
cd apps/app-1
2
npm run build
3
npm run start -- -p 3001
4

Then configure IIS/ARR to proxy a hostname or path to http://localhost:3001. Microsoft’s IIS ARR reverse proxy guide is here:

https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing

For the environment variables, keep them per app. For example:

1
apps/app-1/.env.production
2
apps/app-2/.env.production
3
apps/app-3/.env.production
4

or set them in the Windows/server process environment for each running app. One important Next.js detail: variables prefixed with NEXT_PUBLIC_ are baked into the browser bundle at build time, so changing them later means rebuilding that app.

If all three apps are served under one domain as paths like /admin, /store, /dashboard, you may also need basePath in each app’s next.config.js. If you can use separate hostnames/subdomains, that is usually simpler.

One detail that would help: are these three apps static exports, or do any of them use SSR/API routes/server actions?