To get this example working, you’ll need to create an IIS 7/8 app on your IIS host and add the directory containing the Node.js Web App as the Physical Directory. Ensure that your Application/Application Pool Identity can access the Node.js install. This example uses the Node.js 64-bit installation.

Project Strucure

This is the basic project structure of a IISNode/Node.js Web app. It looks almost identical to any non-IISNode Web App except for the addition of the Web.config.

- /app_root
  - package.json
  - server.js
  - Web.config

server.js - Express Application

const express = require('express');
const server = express();

// We need to get the port that IISNode passes into us 
// using the PORT environment variable, if it isn't set use a default value
const port = process.env.PORT || 3000;

// Setup a route at the index of our app    
server.get('/', (req, res) => {
    return res.status(200).send('Hello World');
});

server.listen(port, () => {
    console.log(`Listening on ${port}`);
});

Configuration & Web.config

The Web.config is just like any other IIS Web.config except the following two things must be present, URL <rewrite><rules> and an IISNode <handler>. Both of these elements are children of the <system.webServer> element.

Configuration

You can configure IISNode by using a iisnode.yml file or by adding the <iisnode> element as a child of <system.webServer> in your Web.config. Both of these configuration can be used in conjunction with one another however, in this case, Web.config will need to specify the iisnode.yml file AND any configuration conflicts will be take from the iisnode.yml file instead. This configuration overriding cannot happen the other way around.

IISNode Handler

In order for IIS to know that server.js contains our Node.js Web App we need to explicitly tell it that. We can do this by adding the IISNode <handler> to the <handlers> element.

<handlers>
  <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
</handlers>

URL-Rewrite Rules

The final part of the configuration is ensuring that traffic intended for our Node.js app coming into our IIS instance is being directed to IISNode. Without URL rewrite rules, we would need to visit our app by going to http://<host>/server.js and even worse, when trying to request a resource supplied by server.js you’ll get a 404. This is why URL rewriting is necessary for IISNode web apps.

<rewrite>
    <rules>
        <!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
        <rule name="StaticContent" patternSyntax="Wildcard">
            <action type="Rewrite" url="public/{R:0}" logRewrittenUrl="true"/>
            <conditions>
                <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
            </conditions>
            <match url="*.*"/>
        </rule>

        <!-- All other URLs are mapped to the Node.js application entry point -->
        <rule name="DynamicContent">
            <conditions>
                <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
            </conditions>
            <action type="Rewrite" url="server.js"/>
        </rule>
    </rules>
</rewrite>

This is a working Web.config file for this example, setup for a 64-bit Node.js install.

That’s it, now visit your IIS Site and see your Node.js application working.