(616) 371-1037

[email protected]

SignalR as a service in Azure

May 8, 2018 - John Waters


In a previous post, I wrote about using SignalR in AspNetCore. Today, I tried the next step up – SignalR as a service!

You will find the announcement here. This page has more details. So why would you want to run SignalR as a service, rather than embedding your Hubs in your API or Web back end? In short – scalability. If your service goes viral and expands to a farm, you would traditionally use a SignalR backplane, with Sql Server or Redis as a backing store. Turns out there is a lot of tricky programming behind getting this to work well, using sticky sessions and load balancing web sockets. Using the Azure SignalR service, this is all taken care of for you. There is a free tier, with one unit, or a paid tier, with multiple units, which will scale elastically. The free tier is good for 100 concurrent connection and 100,000 messages per day.

Switching to this service from regular SignalR is a breeze. First, you will want to add the Nuget package Microsoft.Azure.SignalR to your app (instead of Microsoft.AspnetCore.SignalR). Second, in your Startup.cs, add .AddAzureSignalR() to your AddSignalR.

Now, switch from UseSignalR to UseAzureSignalR.

Next, create you SignalR service in the Azure portal, and copy the Primary Connection String from it’s keys. For development, add this to your local User Secrets, like this:

When deploying your API to Azure, just add this same connection string as an app setting (with the key Azure:SignalR:ConnectionString).

That’s it! No changes to Hubs, or to your logic using IHubContexts. No changes to connections, groups, messages… and no changes to your client. Very straight forward. I did find though that I had to remove the explicit setting of HttpTransportType to WebSockets in my Angular client, leaving that setting as the default on both client and server worked. In my case, my JTW bearer authentication worked well out of the box too.

Welcome to SignalR as a Service!

John Waters

10 thoughts on “SignalR as a service in Azure

  • Nathan Abrams

    July 11, 2018 at 1:58 am


    I apologize in advance if this has been asked before, but what I’ve researched gives such a dizzying volume of material that I’m still perplexed.

    1. It sounds like Azure SignalR Service can/will “automatically” instantiate multiple instances of the same hub type “as needed” – I don’t need to manage that, nor do I “need” to be aware of those “physical” instances. Furthermore, it seems like it will “auto-magically” propagate Groups, Clients, etc. from one instance of a hub to another instance of that same hub type. So if one client happened to connect to one instance and another client happened to connect to a second instance, both instances would be “aware” of both clients. Same for Groups – if I modified a group, the change would be propagated to all instances. Bottom line: I don’t need to deal with setting up Redis, etc. (as I would if I was using SignalR “on-premise”).

    Is all of the above correct?

    2. If one of those instances “goes down” for whatever reason, will the OnDisconnectedAsync method on the remaining instance be called for the clients that were connected to the instance that went down.

    I guess what I really need to know is if I can truly treat a hub living in Azure SignalR Service as a logical entity (and write my code as if there was only one instance) and not be concerned with the fact that there may be multiple instances.

    Thanks in advance!

    • John Waters

      August 10, 2018 at 3:59 am

      I believe you are correct, although I have some blocking issues that have caused me to revert to regular SignalR for now. Even with regular SignalR, the backplane technology allows this kind of scenario, using Redis or SQL Server, so I am guessing that is what they do. The idea is you use it as a platform and don’t have to deal with all those tricky cases.

      • Jeff Webb

        August 10, 2018 at 1:15 pm

        Hey John, I would be curious to find out what your blocking issues are that caused you to revert to regular SignalR. I am looking at using the Azure service as well and curious to see what you found.

        • John Waters

          August 18, 2018 at 12:57 pm

          We are using an Angular SPA, downloaded from a different site than the API where the SignalR Hub is. For some reason, in this scenario, the OnConnected event on the Hub doesn’t fire. This is what I use to add the connection to a tenant specific group, so without this I can’t do the multi tenant setup correctly. It works if I remove the Authorize attribute from the Hub, but I don’t want to do that for security reasons. I have had a support ticket open with the Azure SignalR team but they have not been able to reproduce this – on the other hand their demo is hosted in the same app as the API, not a separate one. It doesn’t appear to be a CORS issue. The regular SignalR works just fine in this setup, just not SignalR as a service. At some point I need to try to modify the Azure SignalR team’s demo to be a separate SPA and see if the error reproduces, I just haven’t had time.

        • John Waters

          September 4, 2018 at 9:16 am

          I am happy to announce that as of the latest Azure SignalR nuget and Angular SignalR npm, it works!

  • mohebbo

    July 31, 2018 at 5:38 am

    Hope you are doing well. Do you have any sample code for ‘Azure signalR’ with angular


  • Jonas Hofer

    October 12, 2018 at 10:09 am

    Thank you very much for this short and simple explanation!
    I am very new to SignalR and I was trying to get my head around what the difference between the Azure service of it and just the “normal” use inside .Net Core. Now I know.

  • Jens Theisen

    January 16, 2019 at 11:09 am

    I don’t get it.

    If you deploy your hub to your own site, than how can that possibly scale beyond that deployed hub? How can a service that I don’t deploy anything to can serve hubs I write in C#?

    I thoroughly confused.

    • John Waters

      January 17, 2019 at 11:17 am

      When you use SignalR as a service, the SignalR client is redirected behind the scenes to communicate with the SignalR service in Azure, which in turn communicates back to your Hub. SignalR supports the concept of a backplane for scaling out Hubs, I am assuming that your local hubs (in a web farm) use the service as a backplane, conceptually, but haven’t dug into the details. Since you switch stacks on the back end from SignalR to AzureSignalR, there is definitely some change in that part. If you find out more let me know!


Leave a comment

Your email address will not be published. Required fields are marked *