Deploying a node.js application on Azure

Recently I needed to publish a simplish node.js application on Azure. It were already running smoothly on heroku so I figured that it shouldn’t be any issue to just deploy and be done with it.


Deploying on Azure is simple enough. You can use Kudo to browse logs instead of using ftp or the azure powershell.

The if(require.main===module) pattern does not work on azure due to some IIS interceptor script. A workaround needs to be used.


By clicking custom create we can set up the source control link right of the bat. So that is what we will do.


Next we will need to set up the source control link. In this example I will allow azure access to my bitbucket repos.

After logging in on bitbucket/github or some other of the integrated services we get to choose the repository and branch that we want to deploy.


There we go! Now whenever somebody pushes a commit to the release branch it will automatically redeploy. In bitbucket I can see that a hook is added to the repository that posts the code to my website.

Going to the page we can now see


No release branch yet. Woops. Easy enough to fix, just create and push and magic things should occur.

git checkout -b release
git push --set-upstream origin release


There we go, a few seconds later the site is deployed. Going to the page now we will see the good stuff right?


Wait, what? Something obviously is not working, we just need to find some form of error log to see what it could be.

Debugging the deployed code

The project were using console.log to print out some info so first things first. We need to make stdout go into some logfile. To do this we need a file called iisnode.yml in the root of the project.

As I did not feel like adding this file to the repository I went the roundabout way and enabled editing of source code. You can do this under configure on the site in the azure portal.


All changes will be overridden on a real deploy? Perfect! I’m not really intending to do anything other than enabling debug either way.


Edit button now exists in the dashboards quick glance list.

Opening VS-Online gives us a simple enough user interface to deal with.


Here we add the iisnode.yml file


loggingEnabled: true
devErrorsEnabled: true

The first line will save the stdout and the second line will return something useful (hopefully) when accessing the page.

Then after hitting the restart button in the portal we try checking the page again.

iisnode encountered an error when processing the request.


HTTP status: 500

HTTP subStatus: 1001

HTTP reason: Internal Server Error

You are receiving this HTTP 200 response because system.webServer/iisnode/@devErrorsEnabled configuration setting is ‘true’.

In addition to the log of stdout and stderr of the node.exe process, consider using debugging and ETW traces to further diagnose the problem.

Ok… not that helpful. Let’s see if we can’t find the stdout file somewhere. There is a webtool called Kudo that can be used for these kinds of things. Going to allows us to access it(where uniquesitename is the name of your website). Under DebugConsole we find a simple enough interface to let us explore the logs.


Under LogFiles/Application we find a file named something unique looking with stdout smack in the middle.
In the log file there is only one line that reads ‘Using “development” environment config’
That needs to be fixed, but it should still work. More than that, I expected more stuff to be in the log. But at least I now know that some of the code is running.

Looking over the server.js file I see this little snippet at the end:

if (require.main === module) {

Doing a quick and ugly console.dir on require.main shows us the issue

{id: '.',
  exports: {},
  parent: null,
  filename: 'D:\\Program Files (x86)\\iisnode\\interceptor.js',
  loaded: false,
   [ { id: 'D:\\home\\site\\wwwroot\\server.js',
       exports: [Object],
       parent: [Circular],
       filename: 'D:\\home\\site\\wwwroot\\server.js',
       loaded: false,
       children: [Object],
       paths: [Object] } ],
   [ 'D:\\Program Files (x86)\\iisnode\\node_modules',
     'D:\\Program Files (x86)\\node_modules',
     'D:\\node_modules' ] }

The module is not at all the require.main that we expect it to be. Rather it is a child of some interceptor.js thingy. To deal with this I modified the code to look like the following

if (require.main === module || (
    require.main.filename.indexOf('interceptor.js')!==-1 && 
    (require.main.children || []).indexOf(module)!==-1)
) {

Yuck! But hey, it gets the job done! If you have a better solution to this problem I’m all ears.

All that is left to do is commit the change and push it to the release branch and we are back in business.

Leave a Reply