Self-Hosted SignalR vs Azure SignalR Service vs Azure Web PubSub in .NET: Which Real-Time Platform Should Your Team Use in 2026?

Self-hosted SignalR vs Azure SignalR Service vs Azure Web PubSub in .NET sits at the centre of a decision that quietly trips up a lot of teams building real-time features. The three options share DNA — WebSockets, hubs, connections — but they diverge sharply on the questions that matter most to enterprise teams: scale, operational burden, cost, and how well they fit an existing .NET architecture.

For teams who want to go beyond the conceptual overview and see exactly how this fits into a production API, the full implementation — including hub configuration, backplane setup, scaling patterns, and infrastructure-as-code scaffolding — is available on Patreon, alongside annotated, run-ready source code for every scenario covered here.

The real-time landscape in ASP.NET Core has also shifted with .NET 10. If you have not already seen what changed in ASP.NET Core 10 SignalR, the What's New in ASP.NET Core 10 SignalR post covers the upgrade impact in detail — it is worth reading alongside this comparison, because some of the .NET 10 changes affect which option is the right fit.

What You Are Actually Choosing Between

Before comparing these three options, it is worth being precise about what each one is.

Self-hosted ASP.NET Core SignalR is the open-source library integrated into the ASP.NET Core host. The application server holds and manages every WebSocket connection. Scaling beyond a single node requires a backplane — typically Redis — to broadcast messages across instances.

Azure SignalR Service is a fully managed, cloud-hosted version of SignalR. The application server no longer holds client connections; it offloads connection management to the service. Hubs still live in your application code, but the heavy lifting of connection routing, scaling, and failover is handled by Azure.

Azure Web PubSub is a different product. It is not a SignalR wrapper — it is a native WebSocket-based pub-sub service. Clients subscribe to groups and receive messages. There are no hubs, no strongly typed client invocations, and no automatic transport fallback. It is designed for broader scenarios where the SignalR protocol is not a requirement.

Microsoft is explicit that neither Azure service is a replacement for the other. They target different problem spaces, and the choice between all three turns on specifics that many comparison articles gloss over.

How Does Self-Hosted SignalR Scale in ASP.NET Core?

Self-hosted SignalR is the natural starting point. You add it to Program.cs, map a hub, and it works — no external dependencies, no cloud account, no per-connection pricing. For teams building internal tools, development environments, low-scale features, or applications that cannot use managed cloud services for compliance reasons, this is the correct default.

The ceiling arrives when you scale horizontally. Each application instance maintains its own connection table. Without a backplane, a message sent from one instance cannot reach clients connected to another. The standard solution is the Redis backplane, which turns the Redis channel into a broadcast bus between instances. It works reliably, but it introduces operational overhead: Redis must be highly available, latency-sensitive, and monitored. In high-throughput scenarios, Redis becomes a bottleneck that requires tuning.

Self-hosted SignalR also means your application processes are responsible for holding thousands of long-lived connections. Under load, this affects memory, thread scheduling, and graceful shutdown behaviour. Teams running ASP.NET Core on Kubernetes need to account for connection draining during pod termination — something that requires deliberate configuration of the IHostApplicationLifetime shutdown sequence and SignalR's own reconnect negotiation.

The operational ceiling is real, but so is the control. Self-hosted SignalR can be tuned precisely: custom hub filters, custom transport configuration, custom authentication middleware, and deep integration with the ASP.NET Core request pipeline.

What Does Azure SignalR Service Actually Change?

Azure SignalR Service removes the most operationally difficult part of self-hosted deployment: connection management at scale. When you configure an ASP.NET Core application to use Azure SignalR Service, clients negotiate a connection endpoint and then connect directly to the Azure service. Your application server maintains a small number of persistent server connections to the service — not one connection per client.

The practical effect is significant. A single Azure SignalR Service unit supports 1,000 client connections. Enterprise tiers scale to millions. Your application server's memory and connection-handling pressure drops dramatically. You lose the backplane requirement entirely — Azure handles distribution across its own infrastructure.

From a code change perspective, the migration from self-hosted to Azure SignalR Service is minimal. You add a NuGet package, call AddAzureSignalR(), and point it at a connection string. Hubs, strongly typed clients, groups, and user-based targeting all behave identically. The hub code does not change.

The trade-offs are cost, latency, and vendor dependency. Azure SignalR Service charges per unit and per message unit. For applications with predictable, modest traffic, self-hosted SignalR will often be cheaper. For applications with variable spikes — live events, trading dashboards, sports scores — the managed service absorbs load that would require significant over-provisioning in self-hosted deployments.

Latency is marginally higher than self-hosted because every message passes through the Azure service infrastructure. For most real-time features this is imperceptible. For applications with sub-50ms latency requirements, the difference deserves measurement.

Azure SignalR Service also supports serverless mode, where there is no persistent application server at all. Event handlers are Azure Functions triggered by client messages. This is useful for ephemeral workloads but adds cold start concerns and moves business logic into a different runtime model.

Where Does Azure Web PubSub Fit?

Azure Web PubSub is the outlier in this comparison. It is a pub-sub service built on native WebSockets — not on the SignalR protocol. Clients connect, join groups, and receive messages broadcast to those groups. The service also supports HTTP webhooks for event handling on the server side.

The key distinction: there is no hub, no strongly typed client invocation model, and no transport fallback. Azure Web PubSub is a raw messaging layer. SignalR adds an abstraction on top of WebSockets that makes it feel like calling methods on remote objects; Web PubSub does not have that abstraction.

This makes Azure Web PubSub a better fit for scenarios where the client is not a .NET application — mobile apps, browser JavaScript that does not use the SignalR client library, IoT devices, or polyglot microservice architectures where the server-side language changes across teams. The native WebSocket protocol makes integration straightforward in any language.

Azure Web PubSub also integrates directly with Azure Event Grid and Azure Functions, making it composable within serverless architectures where SignalR's hub model would be awkward.

The limitation is the programming model. Teams already invested in ASP.NET Core SignalR — with hubs, strongly typed interfaces, and the SignalR client JavaScript library — will find Azure Web PubSub requires a different integration approach. You are not dropping in a connection string; you are changing how your application structures real-time communication.

Side-by-Side Comparison: Where Each Option Wins

Dimension	Self-Hosted SignalR	Azure SignalR Service	Azure Web PubSub
Client connection management	Application server	Azure (offloaded)	Azure (offloaded)
ASP.NET Core hub model	✅ Full	✅ Full (same code)	❌ Not applicable
Backplane required for scale	✅ Yes (Redis)	❌ No	❌ No
Horizontal scale ceiling	Redis throughput	Millions of connections	Millions of connections
Migration from existing SignalR	N/A	Minimal changes	Significant rework
Polyglot client support	.NET-first	.NET-first	Any WebSocket client
Serverless integration	Complex	Azure Functions mode	Native
Cost model	Infrastructure cost	Per unit + message	Per message unit
Vendor lock-in	None	Azure	Azure
Connection protocol	SignalR (WS/SSE/LP)	SignalR (WS/SSE/LP)	Native WebSocket
Offline / air-gapped	✅ Yes	❌ No	❌ No
Custom transport tuning	✅ Full	Partial	Limited

When to Use Self-Hosted SignalR

Choose self-hosted SignalR when:

• Your application serves hundreds of concurrent users and does not expect sudden spikes beyond what Redis-backed scaling can absorb
• Compliance requirements prohibit external managed services for real-time data
• You need fine-grained control over transport configuration, hub authentication, or connection lifetime behaviour
• Your infrastructure is on-premise, private cloud, or in environments where Azure connectivity is restricted
• You are in early development and want zero external dependencies before production requirements are clear

Avoid self-hosted when you expect sustained or unpredictable connection counts in the tens of thousands, or when your team lacks the capacity to maintain Redis backplane infrastructure reliably.

When to Use Azure SignalR Service

Choose Azure SignalR Service when:

• Your application already uses SignalR hubs and you need to scale beyond a single instance without adding Redis infrastructure
• Connection volume is variable — the managed service absorbs spikes cleanly without pre-provisioning
• Your team is already deployed on Azure and the operational overhead of another service is acceptable
• You want serverless event handling for SignalR events via Azure Functions

Avoid it when latency requirements are extremely tight, when cost modelling shows self-hosted is significantly cheaper at your traffic level, or when vendor lock-in is a strategic concern.

When to Use Azure Web PubSub

Choose Azure Web PubSub when:

• Clients are not .NET applications and native WebSocket compatibility matters more than the SignalR abstraction layer
• You are building a pub-sub system where groups receive broadcast messages and do not require remote method invocation semantics
• The architecture is serverless-first and you want native Azure Event Grid integration
• You are building cross-platform real-time features that need to work identically across .NET, JavaScript, Python, and mobile SDKs without the SignalR client dependency

Avoid it when your existing codebase is built on SignalR hubs — the migration cost is high and the hub model's ergonomics are not replicated.

Real-World Decision Scenarios

Scenario 1: An internal dashboard for an enterprise ERP on Azure Self-hosted SignalR. Internal users, predictable connection count, no need for managed scaling, compliance keeps data within your Azure VNet. Redis backplane on AKS is manageable. The operational overhead is justified by the control.

Scenario 2: A SaaS platform with thousands of concurrent users, variable load Azure SignalR Service. The connection management burden is real, the traffic is unpredictable, and the code change is minimal. The cost per unit is acceptable against the engineering time saved on backplane operations.

Scenario 3: An IoT telemetry dashboard receiving data from devices on various platforms Azure Web PubSub. Devices publish via native WebSockets, the server ingests events via webhooks, and browser clients subscribe to groups. The polyglot nature makes the SignalR protocol a poor fit.

Scenario 4: A migration from self-hosted SignalR due to scale pressure Azure SignalR Service, not Azure Web PubSub. The hub code stays intact. The migration is a configuration change, not a rewrite.

What About the Existing Real-Time Comparison Posts?

If you are evaluating lower-level transport choices — WebSockets vs Server-Sent Events vs long polling, or the case for SignalR vs raw WebSockets — the ASP.NET Core WebSockets vs SignalR: Enterprise Real-Time Architecture Decision Guide covers that ground in detail. The transport-level decision is upstream of the hosting decision covered in this post.

The Recommendation

If your application already uses SignalR hubs and needs to scale: migrate to Azure SignalR Service. The migration is near-trivial, the operational benefit is real, and the hub programming model is preserved.

If you are starting a new real-time feature on Azure with polyglot clients or a serverless architecture: evaluate Azure Web PubSub first. It is the more composable option for pub-sub scenarios where SignalR semantics are not a requirement.

If you need full control, offline capability, or a managed cloud service is off the table: self-hosted SignalR with a Redis backplane remains the right call. Know the scaling ceiling and plan Redis capacity accordingly.

The most common mistake is treating Azure SignalR Service and Azure Web PubSub as interchangeable. They are not. Choosing Azure Web PubSub for an application built on ASP.NET Core SignalR hubs is a rewrite decision, not a configuration change. Be precise about which abstraction layer you are committed to before choosing the hosting tier.

☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!

Frequently Asked Questions

Can I switch from self-hosted SignalR to Azure SignalR Service without changing hub code? Yes. Azure SignalR Service is designed for exactly this migration path. You add the Microsoft.Azure.SignalR NuGet package, call AddAzureSignalR() in Program.cs, and provide a connection string. Hub classes, strongly typed interfaces, groups, and user targeting all work identically. The client-side SignalR JavaScript library also requires no changes.

What is the difference between Azure SignalR Service Default mode and Serverless mode? In Default mode, your ASP.NET Core application server is always running and maintains server connections to the Azure service. Hubs are hosted in your application, and the service routes client messages to the appropriate hub methods. In Serverless mode, there is no persistent application server. Client events trigger Azure Functions, and messages are sent back via the service REST API. Serverless mode is useful for event-driven architectures but introduces Azure Functions cold start latency and a different programming model for business logic.

Does Azure Web PubSub support the SignalR client JavaScript library? No. Azure Web PubSub uses native WebSocket connections and its own client SDK. The SignalR JavaScript client library does not work with Azure Web PubSub. If your frontend already uses the SignalR client, migrating to Azure Web PubSub requires replacing the client-side integration, not just the server-side configuration.

What happens to SignalR connections during a Kubernetes pod restart when using self-hosted SignalR? Clients lose their WebSocket connections when the pod terminates. The ASP.NET Core SignalR client library includes automatic reconnect logic, but the reconnect delay means clients will experience a brief interruption. To minimise this, configure IHostApplicationLifetime.ApplicationStopping to drain connections gracefully before termination, increase the ShutdownTimeout on the generic host, and ensure your Kubernetes termination grace period is longer than the drain window. Azure SignalR Service eliminates this concern because client connections are held by the service, not your application pods.

Is Azure Web PubSub significantly cheaper than Azure SignalR Service? Both services charge per message unit and per connection unit, with similar pricing tiers for comparable connection counts. The cost comparison depends heavily on message volume and connection patterns. Azure Web PubSub can be cheaper for high-fan-out scenarios (one server message reaching many clients) because its message unit accounting differs. For bidirectional hub-style communication with moderate client counts, Azure SignalR Service pricing is comparable. Always run a cost estimate against your specific traffic model using the Azure Pricing Calculator before committing.

Can Azure Web PubSub be used with ASP.NET Core dependency injection and middleware? Azure Web PubSub has a .NET server SDK that integrates with ASP.NET Core middleware and can be registered via dependency injection. However, it does not expose the hub-based programming model. Server-side event handling is done through webhook endpoints or Azure Functions event handlers, not through hub methods with typed client contracts. Teams comfortable with ASP.NET Core middleware patterns will find the integration straightforward, but it is architecturally different from SignalR.

What is the right choice for a microservices architecture where real-time is needed across multiple services? Azure SignalR Service works well here if your services are .NET-based and you want a centralised real-time delivery layer. Each microservice can publish messages to SignalR hubs via the Azure SignalR Management SDK without hosting its own hub. Azure Web PubSub is the better choice if services are polyglot and need to broadcast events via HTTP without the SignalR dependency. Both managed options are preferable to self-hosted in a microservices context because they eliminate the backplane coordination problem across service instances.