Getting your Azure Web site to use node v0.8.1 now

In my last post about a week ago, I talked about the recent release of node 0.8.0. Well just today node 0.81 was released which addressed a few bugs. Gotta love the speed of the node community!

Since the recent releases a few folks have been asking “Can I run v0.8.1 in a Windows Azure Web site today?” The answer is YES and in this post I will show you how to do it.

How to do it

By default when you deploy a node app to an Azure Web site, we use the default version of node that is preconfigured in Azure, which is currently v0.6.17. You can however deploy your own version of node.exe and via iisnode.yml tell us to use it instead.

Create the site and configure it

Create a new folder where to store your node app.
Add a server.js to the folder. I am going to use the following code which will just output the version.

Now create your site. I’ll call mine “node081test” using this command:

Now comes the part about setting node version. First create a child bin folder and change to it.
Next go download node.exe from nodejs.org and put it in that folder. If you have curl you can use this command.

Next open up your iisnode.yml in your favorite editor and add the following entry. This specifies the absolute location for your node.exe.

For your site you will need to change node081test in the path to whatever name you chose.
Logger.js is a loader that will override node’s logging mechanism so that it writes to our Azure logs location. It will also load your app startup js file i.e. app.js or server.js.

Push it!

Now that the site is configured, we can go push it to github.

And voila, we’ve deployed Node v0.8.1

Upgrading later to a different version

One caveat here, once you have a site with a custom node version deployed, you need to stop the site before you push the upgrade. This is because the file may be locked by iisnode. To do this just just use the “azure site stop” command from the directory where your app lives and then restart it with “azure site start”. You only have to do this if you are changing the version.

What about versioning for Web sites in general?

One question you might be asking is what about our versioning story in general, will we only support 0.6.17 out of the box for the foreseeable future and then require you to push a specific node after that?

The answer is no ;-). We are planning to add versions pretty frequently (monthly) and are about to roll out a versioning story for in-the-box versions in a few weeks.

In the meanwhile, you can get going with using 0.8.1 now. Also using this technique you will always be able to get the version you want, when you want it!

This entry was posted in azure, node.js. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Glenn Block

No, we just rolled out new support for using engines in package.json. What you can do now, is just put engines: { node: 0.8.x} in your package.json and then push to git.

I definitely need to blog on this, but Tomek already has here:http://tomasz.janczuk.org/2012/09/selecting-nodejs-version-in-windows.html
http://twitter.com/woodjoe Joeyw

Thanks Glenn, just to clarify….
My version of node.exe is 0.6x, do I need to manually upgrade that to 0.8.1? I wanted to see if npm link is fixed in the newer version.
If there is an update to IISNode should I see this as an update to Web Platform Installer? Or do I need to uninstall and reinstall?
I understand the npm engine setting for engine selection at deployment time, but npm update won’t up upgrade the local node.exe instance.
http://blogs.msdn.com/gblock Glenn Block

Yes. It should already be updated to include it. You need to set engines in your package.json to use it though as by default for now we use 0.6.x. We’ll change that soon to a more recent version.
http://twitter.com/woodjoe Joeyw

Will iis-node be updated on the web platform installer to include 0.8x?
http://blogs.msdn.com/gblock Glenn Block

Julie, Glad it helped.

We have a better mechanism coming shortly that will allow you to choose a version via package.json. For most situations this will mean you don’t have to jump through the few hoops I mentioned. However it’s still nice to have the control to use WHICHEVER version you like whether we support it or not.
http://weblogs.asp.net/shijuvarghese/ Shiju Varghese

Thanks for the post.