Skip to main content
Logo
Overview

Hosting a Next.js 14 app on IIS (with cookies & HTTPS)

Pavan Shinde Pavan Shinde
February 22, 2026
4 min read
nextjs
iis
windows
deployment

Hosting a Next.js 14 app on IIS (with cookies & HTTPS)

Sometimes you don’t get to pick the “correct” infrastructure.

On a client project, we had to ship an enterprise SaaS built with Next.js 14 into an environment where the only approved hosting option was a conventional Windows IIS server. No Vercel. No containers. No budget for a Node-friendly hosting stack.

We tried static export first. It looked promising, but it fell apart for our use case: cookie-based authentication.

So we went the pragmatic route: run Next.js as a real Node server behind IIS using iisnode + URL Rewrite, terminate TLS on 443, and expose the site on the internal network.

It worked like a charm.

Why static export didn’t work for us

Static export is great when your app is truly static, or when you can move all server behavior to external APIs.

Our app needed:

  • Cookie-based auth/session behavior (request-aware)
  • A server runtime to handle routing and auth consistently

In short: static export wasn’t a drop-in replacement for what we shipped.

The working setup (architecture)

The successful setup looked like this:

  1. IIS hosts the site and terminates HTTPS on port 443 (certificate bound in IIS).
  2. URL Rewrite forwards application requests to a Node entrypoint.
  3. iisnode runs and manages the Node process under IIS.
  4. The Next.js app runs as a real server (so cookies/auth behave normally).

This pattern lets you stay inside enterprise constraints (IIS governance, certificates, internal networking) while still running Next.js in its intended server mode.

What we used

  • Next.js: 14
  • Server: custom server.js
  • TLS: HTTPS on port 443 with a certificate bound in IIS
  • Network: exposed inside an internal network (host entries / internal DNS)

Prerequisites

1) Install Node.js on the server

Pick a Node version compatible with your Next.js 14 app.

2) Install URL Rewrite for IIS

URL Rewrite is what enables you to route requests cleanly.

Download: IIS URL Rewrite

3) Install iisnode

iisnode enables IIS to host Node applications.

Repo: iisnode

Building the app

This is a standard production build:

  • next build
  • start via your custom server.js

A custom server was the right fit for IIS because it gives you a single, explicit Node entrypoint that IIS can route to and manage.

IIS configuration (high-level)

Every IIS deployment differs a bit, but these were the key pieces:

  • Create a site/application in IIS pointing at the deployed app directory
  • Ensure the app pool/site is configured to run the Node entrypoint via iisnode
  • Use URL Rewrite to:
    • serve static files normally
    • forward all other requests to the Node handler

I’m not including the exact web.config here because it varies by setup (and I don’t want to publish a config that’s not yours).

If you’re doing this yourself, expect a couple iterations on rewrite rules until:

  • / and app routes resolve correctly
  • static assets load (Next static + any public assets)
  • cookies are set/returned as expected

HTTPS on port 443 (why it matters)

We hosted the app over HTTPS with a certificate bound in IIS on port 443.

This wasn’t just “nice to have”—it’s essential for modern auth flows:

  • Secure cookies require HTTPS
  • SameSite policies behave differently depending on context
  • hostnames must match the certificate and the cookie domain expectations

Internal network access (host entries)

Once deployed, we created the required host entries and exposed the IIS site within the internal network.

Accessing the app through the correct hostname (not an IP or temporary alias) helped ensure cookie scoping and auth flows behaved consistently.

Results

After setting up iisnode + URL Rewrite + HTTPS + host entries:

  • cookies worked reliably
  • authentication worked end-to-end
  • the app was usable as a proper SaaS inside the enterprise network

Gotchas / lessons learned

A few things I’d watch for if you attempt this:

  • Static export isn’t compatible with every auth model (especially cookie-centric flows).
  • TLS + correct hostname are non-negotiable for stable cookie behavior.
  • Expect to tweak rewrite rules until both routes and static assets behave.
  • Plan your logging strategy early (IIS logs + Node logs + app logs).

References