Port being undefined in the Azure Node.js applicat

I have an Azure App Service running Node.js application using IISNode. The problem is that process.env.PORT is undefined. I have read that IISNode uses a thing called named pipes and that the port information might not be easily readable (?), but in my case I only get undefined.

The project I try to deploy can be found from GitHub.

I do have a Web.config file defined and it looks like this:

    <handlers>
        <!-- indicates that the app.js file is a node.js application to be handled by the iisnode module -->
        <add name="iisnode" path="index.js" verb="*" modules="iisnode" />
    </handlers>

    <rewrite>
        <rules>
            <!-- Don't interfere with requests for node-inspector debugging -->
            <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
                <match url="^index.js\/debug[\/]?" />
            </rule>

            <!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
            <rule name="StaticContent">
                <action type="Rewrite" url="public{REQUEST_URI}" />
            </rule>

            <!-- All other URLs are mapped to the Node.js application entry point -->
            <rule name="DynamicContent">
                <match url="/*" />
                <action type="Rewrite" url="index.js" />
            </rule>
        </rules>
    </rewrite>

    <!-- You can control how Node is hosted within IIS using the following options -->
                <!--<iisnode      
                  node_env="%node_env%"
                  nodeProcessCountPerApplication="1"
                  maxConcurrentRequestsPerProcess="1024"
                  maxNamedPipeConnectionRetry="3"
                  namedPipeConnectionRetryDelay="2000"      
                  maxNamedPipeConnectionPoolSize="512"
                  maxNamedPipePooledConnectionAge="30000"
                  asyncCompletionThreadCount="0"
                  initialRequestBufferSize="4096"
                  maxRequestBufferSize="65536"
                  watchedFiles="*.js"
                  uncFileChangesPollingInterval="5000"      
                  gracefulShutdownTimeout="60000"
                  loggingEnabled="true"
                  logDirectoryNameSuffix="logs"
                  debuggingEnabled="true"
                  debuggerPortRange="5058-6058"
                  debuggerPathSegment="debug"
                  maxLogFileSizeInKB="128"
                  appendToExistingLog="false"
                  logFileFlushInterval="5000"
                  devErrorsEnabled="true"
                  flushResponse="false"      
                  enableXFF="false"
                  promoteServerVars=""
                 />-->
    <iisnode watchedFiles="*.js;node_modules\*;routes\*.js;views\*.jade;views\account\*.jade;iisnode.yml" />
</system.webServer>

I have written a Kudu scripts that will build the assets and copy them to %DEPLOYMENT_TARGET%.

What is it that I am missing here? Any help is appreciated!

Update

I spent hours on multiple days to find out what could be the cause why the process doesn't start and therefore env variables are undefined. I got the app up and running on Heroku in 15 minutes, so I guess this stays mystery (for me at least).

The "Starter Site" app does not deploy for me, looks like many of its dependencies are now broken. That being said, here's the minimal stuff you need to get going on Azure App Service:

var http = require('http');

function onRequest(request, response) {
    response.writeHead(200, {
        'Content-type': 'text-plain'
    });
    response.write('Hello from Node.');
    response.end();
}

// provess.env.PORT will expand to the name pipe value on App Service
// request --> Frontends (ARR) --> Web Worker (IIS) --> iisnode --> 
//    --named-pipe--> node.exe server.js

http.createServer(onRequest).listen(process.env.PORT || 3000);
console.log('Listening for requests on port ' + (process.env.PORT || 3000));

You don't have to worry about what process.env.PORT returns, it's handled by the platform at runtime and it's guaranteed to return the right thing.

Here's how things look under the hood: