How to Scale SignalR Applications Across Multiple Servers
This guide explains how to scale ASP.NET Core SignalR across several servers using either a Redis backplane or Azure SignalR Service. It covers why messages fail to reach clients on other servers, how each option distributes them, and when sticky sessions are still needed. It is a practical starting point for teams moving real-time apps into production.
Key points
- For a Redis backplane, install Microsoft.AspNetCore.SignalR.StackExchangeRedis and register it with AddSignalR().AddStackExchangeRedis(...).
- For Azure SignalR Service, use the Microsoft.Azure.SignalR package and AddAzureSignalR(), with the connection string under Azure:SignalR:ConnectionString.
- A Redis backplane generally still needs sticky sessions; only documented exceptions avoid them.
- Every server must share the same backplane or Azure SignalR configuration.
- A backplane does not store messages, so add durable storage if history or replay is required.
- Protect hubs with authentication and authorization, and derive user identity from claims rather than client input.
When an ASP.NET Core SignalR app runs on several servers behind a load balancer, each server only knows about its own connections, so a message published on one node may never reach clients attached to another. The article compares two scale-out routes: a Redis backplane that relays messages between servers, and Azure SignalR Service, a managed layer that takes over client connection handling. It walks through the packages and the registration calls needed for each option.
The key caveat is that a Redis backplane does not remove the need for sticky sessions, while Azure SignalR Service does for connections going through the service. The author also covers hub authorization, client reconnect logic, load testing and the fact that a backplane is not a durable message history. Read the original for the full configuration walkthrough and troubleshooting table.
Real-world use
- A live chat app that now runs on several servers behind a load balancer.
- A notification service hosted on Azure that wants to offload connection handling to a managed service.
- A self-hosted real-time dashboard whose team already operates Redis.
Why it matters
Running SignalR on more than one server silently breaks message delivery without a scale-out layer. Your choice between Redis and Azure SignalR Service determines session affinity needs and operational burden.