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:
1npm install2npx turbo run build --filter=app-13npx turbo run build --filter=app-24npx turbo run build --filter=app-35
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:
1cd apps/app-12npm run build3npm run start -- -p 30014
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:
1apps/app-1/.env.production2apps/app-2/.env.production3apps/app-3/.env.production4
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?