---
title: "SignalR Scalability: Scaling Real-Time SignalR Applications on Heroku"
description: "Scaling a SignalR application beyond one server requires coordination because each server maintains its own connected-client list. The guide builds a .NET 9.0 chat application, adds the Microsoft.AspNetCore.SignalR.StackExchangeRedis package, and configures Redis as a backplane with a SignalRChat channel prefix and environment-specific connection settings. It deploys the application to Heroku, changes the dyno type to standard-1x, and runs three web dynos; without session affinity, WebSocket startup fails because the connection may be routed to a different dyno. Enabling Heroku’s http-session-affinity feature keeps requests on one dyno, after which both browsers establish stable WebSocket connections and exchange chat messages successfully across the scaled deployment."
---

# SignalR Scalability: Scaling Real-Time SignalR Applications on Heroku

[Heroku](https://yomu.fyi/company/heroku) · Andrew Fawcett · May 21, 2025

**Type:** Tutorial

## Summary

Scaling a SignalR application beyond one server requires coordination because each server maintains its own connected-client list. The guide builds a .NET 9.0 chat application, adds the Microsoft.AspNetCore.SignalR.StackExchangeRedis package, and configures Redis as a backplane with a SignalRChat channel prefix and environment-specific connection settings. It deploys the application to Heroku, changes the dyno type to standard-1x, and runs three web dynos; without session affinity, WebSocket startup fails because the connection may be routed to a different dyno. Enabling Heroku’s http-session-affinity feature keeps requests on one dyno, after which both browsers establish stable WebSocket connections and exchange chat messages successfully across the scaled deployment.

## Context

A single SignalR server can only support limited growth, and separate servers maintain separate connected-client lists. Without message synchronization and stable routing, clients connected to one server may not receive messages sent through another, while WebSocket connections can fail after scaling across Heroku dynos.

## Approach / What changed

The application uses Redis as a SignalR backplane to coordinate messages between instances and Heroku’s http-session-affinity feature to keep each client routed to the same dyno. The deployment changes to standard-1x dynos, scales the web process to three dynos, and verifies Redis pub/sub traffic, WebSocket stability, and cross-browser chat delivery.

## Takeaways

- A Redis backplane coordinates SignalR messages between servers so clients connected to different instances can receive the same chat updates.
- Scaling the Heroku web process to three dynos without session affinity caused WebSocket startup failures because connection requests could reach different dynos.
- After enabling http-session-affinity, both browsers maintained stable WebSocket connections and exchanged real-time messages successfully across the multi-dyno deployment.

**Tags:** [Heroku](https://yomu.fyi/topic/heroku), [.NET](https://yomu.fyi/topic/dotnet), [Redis](https://yomu.fyi/topic/redis), [SignalR](https://yomu.fyi/topic/signalr), [WebSockets](https://yomu.fyi/topic/websockets)

- Source: [Heroku](https://www.heroku.com/blog/scaling-real-time-signalr-applications-on-heroku)
- Source URL: https://www.heroku.com/blog/scaling-real-time-signalr-applications-on-heroku
- Ingested by Yomu: 2026-09-10T04:02:34.676Z

[Read original post](https://www.heroku.com/blog/scaling-real-time-signalr-applications-on-heroku)