Scott Hanselman

GitKraken Pro git client teaming up with NightScout to support Open Source Diabetes software

August 1, '16 Comments [11] Posted in Diabetes
Sponsored By
GitKraken + NightScout

There's a great new cross-platform Git client available now called GitKraken. It's totally free to download and but the optional Pro version includes some great features like a Merge Conflict editor, profile support to keep work and personal separate and more. It's $6 a month or just $5 a month if you go annually.

We've talked to the folks at GitKraken and we've brokered an amazing deal. My friend Hamid Shojaee who owns Axosoft has always supported open source and is a generous charitable giver. He's always asking about my diabetes and the software I use to manage it. As you may know, I use the open source Nightscout application running in Azure to visualize my blood sugar in near-real-time. My wife and family can see my numbers and support me remotely. If you are diabetic or have anyone with diabetes in your life, you'll quickly find that NightScout is indispensible. For parents of children with diabetes it's truly life-changing.

Since GitKraken is great for Git and working with software hosted on GitHub and Nightscout is all open source and hosted on GitHub partnering up seemed very natural. GitKraken is going to give all the revenue for the first month's sales to the Nightscout Foundation!

As well as providing awesome additional features, upgrading to GitKraken Pro is an opportunity to help raise money and increase awareness for the Nightscout Foundation, a nonprofit that is improving the lives of people and families affected by type 1 diabetes, through their support and creation of open source diabetes management systems.

So, until August 28, 2016, 100% of first month revenues from the sales of GitKraken Pro will be donated to the Nightscout Foundation. There is no upper limit to how much money Axosoft will donate for the month, but we’ll be making a minimum commitment of $5,000!

GitKraken is written in Electron and is totally cross-platform. It's tree-view is a standout feature in my opinion and makes it a lot easier to visualize complex repositories and branches.


Again, it's free but you can optionally upgrade to Pro if you like it and want some more advanced features. And, for the next month if you do upgrade GitKraken to Pro you'll be helping the Nightscout Foundation support the development of opens source software to fight diabetes!

Sponsor: I want to thank Stackify for sponsoring the blog this week, and what's more for gifting the world with Prefix. It's a must have .NET profiler for your dev toolbox. Do yourselves a favor and download it now—free!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

The Promising State of Diabetes Technology in 2016

June 16, '16 Comments [23] Posted in Diabetes | Open Source
Sponsored By

Glucopilot helped PalmPilots users in the 90sI've been a Type 1 Diabetic now for nearly 25 years. The first thing that every techie does once they've been diagnosed with Diabetes is they try to solve the problem with software or hardware. Whatever tool they have, they use that too to "solve their Diabetes." Sometimes it's Excel, sometimes it's writing a whole new system. We can't help ourselves. We see the charts and graphs, we start to understand that this is a solvable problem.

However, innovation in Diabetes technology has two sides. There's the "what can we do within the medical establishment" side, and there's the "what components do I, the actual diabetic, have to work with" side. We are given insulin pumps, glucose meters, and drugs but we aren't involved in the development, which makes sense to a point.

Fifteen years ago (yes, really, 15) I went on a trip with a PalmPilot, OmniSky wireless modem, Blood sugar meter, and insulin pump and quasi-continuously sent my blood glucose numbers back to a server and my doctor. Many many years later I demonstrated on stage at a Microsoft conference (video) how a remote management system like NightScout along with other innovations in IoT are taking these concepts so much further. It's through the work of hundreds of innovators and tinkerers that I think we're on the cusp.

Aside: If you are wholly unfamiliar with how Type 1 Diabetes works, please take a moment and read Diabetes Explanation: The Airplane Analogy. This post pretty clearly explains how blood sugar rises and falls and why fixing this isn't a simple problem.

Four years ago - four years ago this week in fact - I wrote a post called The Sad State of Diabetes Technology in 2012, largely in frustration. It became one of my most popular posts. For some it was a turning point and was called "seminal." For most Diabetics, though, the post said what everyone already thought and already knew. Diabetes sucks deeply, the technology we are given to manage it sucks deeply, and we are pretty much tired of waiting. We've been told a "cure" (or at least, a mostly fool-proof way to manage it) is just 5 years out. I've been told this, personally, every year for the last 25.

Here we are four years after I wrote my angry post and I'm actually feeling like we are on the edge of something big.

I believe that now we are inside a 5 year window of time where we WILL make Type 1 Diabetes MUCH MUCH easier to deal with.

Using this generation diagram from the JDRF, it's totally clear that the open source diabetes community is making Stage 4 happen today.

6 stages of "Artificial Pancreases"

Let's stop and level set for a moment. Here's a generalization of your day if you're not diabetic.

The "Normal Sugared" have it easy.

Here's what a Type 1 diabetic (like me) does:

Diabetics have to constantly manage their sugar, manually

What we need is for the "loop to be closed."

Is a Closed-Loop System for Diabetes Management like a Self-driving Car?

You know how the press just loves to call the Tesla a "Self-driving car?" It's not. I've driven one for over 15 thousand miles. It has two main features and they are both effectively cruise-control. There's the cruise control that slows down when there's a car in front of you, and then there's the "Tesla Auto-Pilot" feature. Amazing, sure, but realistically it's effectively "side to side cruise control." It will keep you in the lanes, usually, to a limit. You can't go to sleep, you shouldn't be texting. You are in charge. This isn't to minimize the amazing work that Tesla has done, but using a closed-loop insulin stages above as a parallel, a Tesla is barely stage 3 or 4.

However, this is still a fantastic innovation and for a diabetic like myself, I *would* like to take my hand off the diabetic wheel as it were, at least for the easy stuff like staying in the lanes on the freeway while going straight. Automatic basal insulin dosing (background insulin dosing) would free my mind up a LOT.

It's possible and it's happening.

What's required for a closed loop?

In order to close the loop, what are the components we need? For this simple exercise please assume that "safely and securely" applies to all of these statements.

  • The ability to tell an insulin pump to deliver insulin
  • The ability to read data from the insulin pump.
  • The ability to read current blood sugar from a continuous glucose meter
  • Some CPU or "brain" where an algorithm or controller lives to coordinate all this.
  • Storage, cloud or otherwise, to keep all this historical data

There are a number of issues to think about, though, if the open source community wants to solve this before the commercial companies do.

  • Most pump manufacturers don't like the idea of remotely controlling them after a series of insulin pump proof of concept "attacks."
    • This means that some systems require the use of an older pump to allow remote control. We, the community, need to encourage pump manufacturers to create pumps that allow secure remote control.
  • Most CGM manufacturers don't publish their specifications or like 3rd party apps or systems talking to their stuff.
    • We, the community, need to encourage manufacturers to create glucose meters that allow secure access to our sugar data. 'Cause it's our data.
  • Universal concern that someone will accidentally hurt or kill themselves or someone else.
  • Where should the "closed loop brain/algorithm" live? The cloud? Your phone? Another CPU in your pocket?

What happened in the Diabetes Technology Ecosystem in the last 4 years to make this possible?

The interesting part about this problem is that there are many ways to solve this. In fact, there are multiple closed loop OSS systems available now. Lots of things have made this possible.

Here's a rough timeline of the Open Diabetes Ecosystem.

  • Insulaudit -  Ben West starts an open source driver to audit medical devices
  • Decoding CareLink -  Driving an insulin pump with Python, Oct 2012
  • Decoding Dexcom - Pulling data off a Dexcom CGM 3 years ago!
  • CGM-Simple-Reader - Using Windows 8 DLLs from Dexcom Studio to get CGM data. Next step was uploading it somewhere!
  • Pebble - Being able to remotely view Nightscout Data on your wrist on a pebble.
  • Nightscout - Remote viewing of glucose data by pulling from a CGM and uploading to a web app. The addition of a REST API (Web API) was the killer that kick started other apps.
  • Parakeet Google App Engine - Gets data from The Parakeet Unit and talks to xDrip over the cell network. "OnStar for diabetes"
  • Nightscout Share Bridge - Takes Dexcom G5 data and copies it over to Nightscout.
  • xDrip - Talk to a CGM without a Receiver. Pulling the signal off the air itself. Can we improve their algorithm ourselves?
  • PingRF - Talking to the Animas Ping Pump via RF
  • OpenAPS - Open Artificial Pancreas System. A platform for building a closed-loop with open tools. There are almost 100 people running their own closed loops, today.
  • Watch Dana Lewis talk about OpenAPS at OSCON this year!
  • RileyLink - A bridge that can talk a Medtronic Pump. Make a the pump's RF programmatically available via Bluetooth
  • Loop - iPhone-based closed loop that uses RileyLink
  • xDripG5 - iOS Framework for talking to Dexcom CGMs over Bluetooth
  • OmniAPS - Talking to an OmniPod Pump

I realize this isn't comprehensive, but the point here is to understand there are dozens of ways to solve this problem. And there are dozens (hundreds?) of excited and capable people ready to make it happen.

Here's the systems that I have. This is my Dexcom G5 on my iPhone showing my blood sugar in near-realtime. Here I can see my sugar, but I have to make my own decisions about dosing.

Dexcom G5 on an iPhone

Here is a Raspberry Pi running OpenAPS. This is the brain. The algorithm runs here. It's talking to my Dexcom, to Nightscout in the cloud, and to my Medtronic Pump via RF via a USB device called a CareLink.

OpenAPS on a Raspberry Pi

Here is OpenAPS again, this time running on an Intel Edison sitting on a SparkFun Block with a battery and a TI C1111 RF transmitter. The Edison is the brain and has Bluetooth. The TI transmitter can replace the CareLink.


As an alternative to OpenAPS, here is a RileyLink custom board that can also talk to the pump, but doesn't have a brain. There is no algorithm here. Instead, this is a bridge with RF in one hand and Bluetooth in the other. It makes a pump controllable and readable. The brain lives elsewhere.


Here's the RileyLink in a 3D printed case. I can keep it all in my pocket and it will run all day.

RileyLink in a 3D printed case

Here is a build of Loop from Nathan Racklyeft that uses Bluetooth to talk to both my CGM (Glucose Meter) and the Pump via the Riley Link. In this example, the phone is the brain. This is good and bad. You can't really trust your phone to keep stuff running if it also runs Candy Crush AND has a crappy battery. However, if both my Pump AND CGM spoke Bluetooth, we can imagine a world where the brain of my "artificial pancreas" is just an app on my phone. No additional hardware.

Loop puts the brain on your phone

The most important point here is that a LOT of stress could have been avoided if the manufacturers had just created open APIs in the first place.

There's also amazing work happening  in the non-profit space. Howard shared this common on my original "Sad State" Diabetes Post:

Great article, Scott. You've accurately captured the frustration I've felt since my 12 year old daughter was diagnosed with T1D nine months ago. She also wears a pump and CGM and bravely performs the ritual you demonstrate in your video every three days. The technology is so retro it's embarrassing.

Since then, Howard created Tidepool and recently spoke at the White House! On the commercial side, there are lots of players rushing to market. Medtronic may '>'>'>have a hybrid closed loop called the 670g by spring next year although trials move slowly so I'm thinking later or possibly 2018. Lane Desborough from Bigfoot Biomedical has also closed the loop and they are bringing it to market...soon we hope!

For more information, go watch Mark Wilson's talk at D-Data Exchange 2016. It is an excellent 30 minute overview of the ecosystem and a call to action to everyone involved.

Check out this visualization of 6 years of Hacking Diabetes. These are all the projects and commits as folks dump into Open Diabetes Hacking Community.

What's the take away? It's an exciting time. It's happening. It can't be stopped.

More Diabetes Reading

Sponsor: Big thanks to Redgate for sponsoring the feed this week. How do you find & fix your slowest .NET code? Boost the performance of your .NET application with ANTS Performance Profiler. Find your bottleneck fast with performance data for code & queries. Try it free!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Diabetes Technology: Dexcom G5 CGM Review - So much wasted potential

October 13, '15 Comments [56] Posted in Diabetes
Sponsored By

Dexcom G5 for iPhoneAs you may know, I'm a Type 1 Diabetic and have been for well over 20 years. I wear a Medtronic Insulin Pump 24 hours a day and use a Dexcom CGM (Continuous Glucose Meter) to monitor my blood sugar, also 24 hours a day.

This post won't explain how diabetes works to you, so check these posts out (or this video) first if you're not familiar.

Moving from a Dexcom G4 to a Dexcom G5

A CGM (Continuous Glucose Meter) doesn't keep you from pricking your fingers. You'll still do finger sticks in order to calibrate a CGM, at least twice a day.

The Dexcom G4 "with Share" worked like this. There was a small transmitter that is attached to me, and it talks a proprietary RF wireless format to a Receiver and then the Receiver talks Bluetooth LE to your iPhone, like this picture below.

Once the sugar number got to my iPhone it's then optionally uploaded to  the Dexcom Share Cloud. My wife can install the Dexcom Follow application on her iPhone and see my sugar on her phone. She also gets the same notifications and warnings I get.

How the Dexcom G4 system works

When you "upgrade" to the G5 from the G4, you'll likely do what I did. I called Dexcom support to see if I was eligible. They had a US$199 upgrade fee which I paid, and the G5 transmitter showed up a week later. I then called them back to get an "upgrade code" which was a 12 digit unique number (GUID) that I had to enter into their Dexcom Studio application on my Windows machine. I plugged in my Dexcom G4 with Share Receiver to my Windows machine using Microsoft USB and ran the upgrader. I needed that upgrade key. Then about 20 minutes later the G4 receiver (remember it talked RF to the G4 transmitter) is now a G5 and only speaks Bluetooth directly to the Bluetooth-enabled G5 transmitter. That means it works like this now:

How the Dexcom G5 system works

The G5 software that runs on the iPhone can also upload to the same Dexcom Cloud which means my wife's Dexcom Follow app *works unchanged*. This was a relief.

The Good

  • If I forget my Receiver device at home I can still see my sugars on my phone. This is huge if you're someone who didn't want to get a Dexcom CGM simply because you didn't want another device in your pocket. That is no longer a blocker.
    • You can carry and use either or both of them. However, if a family member is "Following" you and needs to see your numbers, only the phone is uploading them.
    • You can calibrate on either device and they'll both stay in sync. This was a nice touch as I was concerned I'd have to treat the iPhone as a "Virtual Receiver" and calibrate on both devices twice. Just calibrate on either device and the other sees it.


The Bad

First I want to say that I REALLY appreciate Dexcom, the company, the product, and the people, and I appreciate what you've done for myself and for Diabetics everywhere. The Dexcom sensor technology is unparalleled and a fundamental life changer. I can't imagine living without my CGM and I wholly and completely recommend a Dexcom CGM for ANY and ALL Type 1 Diabetics who want to get a real clear view of what's happening inside your body.

That said, I'm going to be very honest here, so if you work for Dexcom, please take my feedback as what it is. It's firm, crisp, actionable feedback. You should fix these things. They are bad and wrong.

There's no gap filling.

With the G4, if I had the receiver in my pocket but my phone was elsewhere, the phone would "fill the gaps" and load in missed readings that might have happened while the phone and receiver were apart. This doesn't happen anymore and it sucks. Sometimes the phone misses readings and sometimes the receiver misses them and I don't get a complete smooth curve even though the data seems to be available in the ether. As a techie, I'm assuming this means that the new Transmitter has no memory and just yells out the last reading over Bluetooth until a new reading shows up. IMHO it should remember maybe 5 to 10 and sync up gaps when possible. And if the receiver has records the phone doesn't or vice versus, for goodness sake, close the gaps.


The phone just isn't a reliable receiver.

Remember when I said that having the G5 means you don't need the phone with you all the time? Well, kind of. I'm not sure that's 100% true. Here's 3+ hours of data that was completely missed this morning. The phone was 3 feet from my transmitter at all times, sitting on my night stand. My physical receiver was under my pillow and picked up the whole nights numbers, but the fact is, numbers were missed.

Yes, Bluetooth is a troublesome thing, but my Tile BT devices NEVER lose a connection. My Apple Watch never loses connection. My Microsoft Band doesn't lose connections. My car doesn't lose connections. You get the idea. I don't trust the Dexcom G5 software to use only my phone to view my data. I just can't avoid a lost hour.

Also, it's unclear to me how this data gets over the the iPhone from a software perspective. Is it a background task? Can the Dexcom software get ejected from memory when playing high memory pressure games? I need these answers.

I'd like to have a Dexcom engineer tell me/us that this is a transmitter/phone/software/hardware/radio/whatever problem, but who knows. They must know it's not as reliable as the physical device.


The Missed Opportunities

Please, Dexcom Engineer who must be reading this post, read these and explain.

  • There's no Watch app? The Dexcom G4 has an Apple Watch app, but this "upgrade" doesn't include one. Not cool. Don't remove functionality. I don't want to  pick up my iPhone and run an app every time I want to see my sugar. Glance-able data, people. 
    • complications_explained_2xWatch OS2 has the idea of "complications" which are AMAZING. Dexcom needs to let me put my sugar in an active area on my watch screen. To not to do this hurts. It hurts every day as I glance at my numbers hundreds of times a  day.
  • There's a HUGE amount of wasted whitespace in the chart. Huge. Notice that my goal area (the gray area) is less than 10% of my screen space. The area that I'm NOT supposed to be in (from 150 and up is huge). Please let us change the Y-Axis. Please. 300 to 400 mg/dl is far too much Y-axis for many folks. Give us a logarithmic scale. Let me change it to 200 or 250 until I get higher.
  • The app scales on iPhone 6+. If you want to play in the Apple App Store then play correctly. Make nice scalable graphics, and make it look pleasant everywhere.
  • No interactive graph until I landscape the device. The main screen is static. I can't change the axes (Y or X!) and I can't touch existing records. This is a dumb app on a pocket super-computer. Not being able to explore my data is unacceptable.
    • That said, I can flip the device into landscape and look at up to 24 hours in the past, and run my fingers over the results. Why not portrait?
  • No "iOS widgets." iOS has the notion of Widgets. Little active areas of contact for data like my calendar or the weather. I need to see my Glucose here. Again, this is a huge missed opportunity. Huge. Do it now.

Net net, was it a good upgrade? I'm not sure yet. The sensor tech is amazing. The accuracy remains amazing. I like having the option to not take my receiver with me, but the fact that I can't trust the phone not to disconnect when it's in my pocket on the same side the transmitter is remains a serious concern. Buy the G5 if you like Tech and new Stuff, but know that the G4 is still a great device, it's just one you have to carry with you no matter what.

Sponsor: Thanks to Infragistics for sponsoring the feed this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Bridging Dexcom Share CGM Receivers and Nightscout

March 14, '15 Comments [20] Posted in Diabetes | Hardware | Open Source
Sponsored By

Dexcom Share

I've long lamented the sad state of Diabetes technology. For the last 20 years I've been told that it'll be cured in the next few years. (Spoiler: That hasn't happened.)

Fortunately some technological breakthroughs have happened, like the CGM (Continuous Glucose Meter). This device has a transmitted embedded in my belly that transmits to a small receiver. However, my wife couldn't see my blood sugar remotely, so the Nightscout open source project pretends to be computer connected to the receiver, then uploads it to your own website. Then you can see your blood sugar on your watch, or family and friends can log in also. This project has been moving along nicely for a year or so now.

Just last month Dexcom, the CGM maker, released an update to their receiver that includes Bluetooth, called the Dexcom Share. Now my transmitter goes to my Dexcom device which then bounces via Bluetooth LE to my phone, which is then uploaded to the Dexcom site. The Dexcom iPhone app will support the Apple Watch in the future as well, they say.

However, I'd like more control over my data. Dexcom's solution (as of the time of this writing) is iPhone/iPad only. Not everyone can afford an iWatch and iDevices. I'd like to use my Pebble Watch, for example, which is supported in Nightscout today.

I got the Dexcom Share at 3:30pm today in the mail. By 4:40pm it was paired to my iPhone and working nicely. So what I really need is a simple bridge that takes my Dexcom Share data and copies it to Nightscout. From there I can analyze it, send it to my Pebble, or do whatever.

Watching iPhone Traffic from a Windows Machine

First, I need to understand the Dexcom Api. Let's watch the iPhone talk to Dexcom. I'll install Fiddler on my Windows machine and configure Fiddler as a proxy server. I'll need to trust the Fiddler SSL cert (only for dev purposes) on both the iPhone and the Windows machine. My machine is called Hexpower7 and the proxy is on port 8888. I'll visit http://hexpower7:8888 on my iPhone and install the cert there also, which will allow me to watch the traffic and learn about the API.

I learned a few things by watching the traffic.

Watching Traffic

Calling Dexcom with CURL

First, when you login to the Dexcom API you get a Session ID, which is common and to be expected. With that Session ID you can get your sugar values. After the login I retrieved my latest sugar number:

curl -k -X POST "" -H "Accept: application/json" -H "Content-Length: 0"

resulting in:


Here's a screenshot:

Talking to Dexcom Share from CURL

Cool. So I pair-programmed with Benjamin West from the Nightscout project and we spent an hour writing a script to get my Dexcom Share data and bridge/POST it to Nightscout.

I put the script in an Azure WebJob and it's pulling my Share data and putting it into Nightscout every few minutes. I won't post the code here, rather the Nightscout team will take our prototype from here, but the result is lovely.

I don't have to carry an extra Android device anymore, I just use my Dexcom Share and its supported iPhone uploader application. Very cool.

Now it's 7:30pm, just a few hours after I got my Dexcom Share and I've got the best of both worlds. The API was easy to use and we didn't spend more than two hours on it. Most of the time was waiting for the transmitter to complete its warmup cycle.

My Blood Sugar in the Cloud

I'll do a formal Dexcom review soon, but I can already tell you it's a winner. Everyone who can get a CGM should get a Dexcom Share. It's a thrilling device. I would like the iPhone app to support iPhone 6 and 6+ screen-sizes better, and a nicer UI, but all in all, it's a great device.

Don't forget, visit, tell your friends and tweet us at #MarchIsForMakers!

Sponsor: Big thanks to Aspose for sponsoring the blog feed this week! Are you working with Files?Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and many other formats in your applications. Start a free trial today.


About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Enabling Websockets for Node apps on Microsoft Azure

November 3, '14 Comments [13] Posted in Azure | Diabetes | nodejs | Open Source
Sponsored By

Whoa my Blood Sugar is a CGM in the Cloud!NOTE: This is a technical post, I'll blog more about Nightscout later this week. Subscribe and watch for my take, or visit

I'm running an application called Nightscout that is a node app with a MongoDB backend that presents a JSON endpoint for a diabetic's blood sugar data. I use my Dexcom G4 CGM (Continuous Glucose Meter) connected with a micro-USB OTG cable to an Android phone. An Android app bridges the device and POSTs up to the website.

Azure is well suited to run an app like this for a few reasons. Node works great on Azure, MongoLabs is setup in the Azure Store and has a free sandbox, Azure supports WebSockets, and * has a wildcard SSL cert, so I could force SSL.

Enabling Websockets and Forcing SSL

So my goal here is to do two things, make sure Websockets/ is enabled in my app because it's been using polling, and force my app to use SSL.

Setting up a node.js site on Azure is very easy. You can see a 3 minute video on how to do a Git Deploy of a node app here. Azure will see that there's a app.js or server.js and do the right thing.

However, because IIS and node are working together to host the site (IIS hands off to node using a thing called, wait for it, iisnode) you should be aware of the interactions.

There's a default web.config that will be created with any node app, but if you want to custom stuff like rewrites, or websockets, you should make a custom web.config. First, you'll need to start from the web.config that Azure creates.

Related Link:  Using a custom web.config for Node apps

Let's explore this web.config so we understand what's it's doing so we can enable Websockets in my app. Also, note that even though our project has this web.config in our source repository, the app still works on node locally or hosts like Heroku because it's ignored outside Azure/IIS.

  • Note that we say "webSocket enabled=false" in this web.config. This is confusing, but makes sense when you realize we're saying "disable Websockets in IIS and let node (or whomever) downstream handle it"
  • Note in the iisnode line you'll put path="server.js" or app.js or whatever. Server.js appears again under Dynamic Content to ensure node does the work.
  • I added NodeInspector so I can do live node.js debugging from Chrome to Azure.
  • Optionally (at the bottom) you can tell IIS/Azure to watch *.js files and restart the website if they change.
  • We also change the special handling of the bin folder. It's not special in the node world as it is in ASP.NET/IIS.
<?xml version="1.0" encoding="utf-8"?>
This configuration file is required if iisnode is used to run node processes behind
IIS or IIS Express. For more information, visit:

<!-- Visit for more information on WebSocket support -->
<webSocket enabled="false" />
<!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
<add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
<!-- Do not interfere with requests for node-inspector debugging -->
<rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^server.js\/debug[\/]?" />

<!-- 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}"/>

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

<!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
<remove segment="bin"/>

<!-- Make sure error responses are left untouched -->
<httpErrors existingResponse="PassThrough" />

You can control how Node is hosted within IIS using the following options:
* watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
* node_env: will be propagated to node as NODE_ENV environment variable
* debuggingEnabled - controls whether the built-in debugger is enabled

See for a full list of options
<!--<iisnode watchedFiles="web.config;*.js"/>-->

Next, turn on Websockets support for your Azure Website from the configure tab within the Azure Portal:

Turn on Websockets in the Azure Portal

Now I need to make sure the node app that is using is actually asking for Websockets. I did this work on my fork of the app.

io.configure(function () {
- io.set('transports', ['xhr-polling']);
+ io.set('transports', ['websocket','xhr-polling']);

It turns out the original author only put in one option for to try. I personally prefer to give it the whole list for maximum compatibility, but in this case, we clearly need Websockets first. When will Websockets fall back if it's unavailable? What Azure website pricing plans support WebSockets?

  • Free Azure Websites plans support just 5 concurrent websockets connections. They're free. The 6th connection will get a 503 and subsequent connections will fallback to long polling. If you're doing anything serious, do it in Shared or above, it's not expensive.
  • Shared Plans support 35 concurrent websockets connections, Basic is 350, and Standard is unlimited.

You'll usually want to use SSL when using Websockets if you can, especially if you are behind a proxy as some aggressive proxies will strip out headers they don't know, like the Upgrade header as you switch from HTTP to Websockets.

However, even free Azure websites support SSL under the * domain, so doing development or running a small site like this one gets free SSL.

I can force it by adding this rule to my web.config, under <system.webServer>/<rewrite>/<rules/>:

<rule name="Force redirect to https">
<match url="(.*)"/>
<add input="{HTTP_HOST}" pattern=".+\.azurewebsites\.net$" />
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}"/>

Note the pattern in this case is specific to, and will take any Azure website on the default domain and force SSL. You can change this for your domain if you ike, of course, assuming you have an SSL cert. It's a nice feature though, and a helpful improvement for our diabetes app.

I can confirm using F12 tools that we switched to WebSockets and SSL nicely.


The whole operation took about 15 minutes and was a nice compatible change. I hope this helps you out if you're putting node.js apps on Azure like I am!

Sponsor: Big thanks to Aspose for sponsoring the feed this week! Working with Files? Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and many other formats in your applications. Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Page 1 of 15 in the Diabetes category Next Page

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.