Search for a command to run...
Compare self-hosted SignalR, Azure SignalR Service, and Azure Web PubSub in .NET. Trade-offs, scale limits, migration paths, and a clear recommendation.
No comments yet. Be the first to comment.
Most of the .NET conversation about the Model Context Protocol is about building servers: expose your API as MCP tools, point Claude or VS Code at it, done. That is the half that gets written about. T
The first RAG system I shipped answered beautifully about concepts and failed completely on part numbers. Ask it "how do I reset a stuck deployment" and it nailed the answer. Ask it "what does error P
AutoMapper has been the default object mapper in .NET for over a decade, and for most of that time nobody thought about it. Version 15.0.0 changed that. It ships under a dual license now, with a free
You built the pipeline. Documents are chunked, embedded, and sitting in a vector store. Retrieval returns results. And your RAG answers still hallucinate in .NET, confidently telling users about a stu
You upgraded a working API to .NET 10, hit build, and Swashbuckle fell apart. Missing namespaces, OpenApiSchema refusing to compile, AddSecurityRequirement complaining about a delegate it never wanted
Coding Droplets
304 posts
Coding Droplets is your go-to resource for .NET and ASP.NET Core development. Whether you're just starting out or building production systems, you'll find practical guides, real-world patterns, and clear explanations that actually make sense.
From beginner-friendly tutorials to advanced architecture decisions. We publish fresh .NET content every day to help you grow at every stage of your career.
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.
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.
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.
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.
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.
| 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 |
Choose self-hosted SignalR when:
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.
Choose Azure SignalR Service when:
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.
Choose Azure Web PubSub when:
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.
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.
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.
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.
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.
Celin Daniel is Co-founder of Coding Droplets with 13+ years of hands-on experience building, shipping, and operating .NET and ASP.NET Core systems in production. The guidance here comes from real projects and production incidents, not theory.
