Blazor Server vs WebAssembly cost comparisons usually ignore half the bill. Articles compare a small server for Blazor Server against a free static host for WebAssembly, as if the WebAssembly app had no backend at all. In reality, a line-of-business WebAssembly app needs an API server, a database, authentication, and CDN or storage costs, while a Blazor Server app needs enough RAM for its circuits and a reverse proxy that speaks WebSockets.
This article compares the hosting models on the costs that actually appear in production: compute, RAM per user session, bandwidth, infrastructure complexity, and the developer time they absorb. With realistic numbers you can estimate your own bill before you commit.
What Actually Drives Cost in Blazor Server vs WebAssembly
Two numbers define Blazor Server cost: RAM per circuit and peak concurrent connections. Every logged-in user holds an open SignalR circuit, and each circuit carries a dependency injection scope with a DbContext, caches, and component state. That working set is the floor of your server bill, and it grows linearly with your user count.
Blazor WebAssembly pushes compute to the browser, so the per-user RAM cost disappears. What remains is the API. If you already operate an API for other clients, WebAssembly rides it almost for free. If not, you are paying for a new application server, rate limiting, CORS handling, and possibly a second deployment pipeline, all costs that are easy to overlook in the initial comparison.
Blazor Server vs WebAssembly: RAM per Circuit and Connections
A realistic Blazor Server circuit consumes between 10 and 40 MB. A CRM screen with a large MudBlazor data grid, dropdown caches, and an open DbContext sits near the top of that range. At 25 MB average, 200 concurrent users need roughly 5 GB of working set before you add the operating system, the web server, and headroom. Round up to a 2 CPU, 8 GB VM and you have a comfortable ceiling for that load.
Connections matter as much as RAM. Load balancers must forward the WebSocket upgrade for /_blazor, and either sticky sessions keep a circuit on one server or you introduce a SignalR backplane with Redis. Both are solved, documented problems, but they are part of the Blazor Server bill that a static host does not have.
services:
blazor-server:
image: indotalent-crm:10
restart: always
deploy:
resources:
limits:
cpus: "2"
memory: 4gThe snippet above is a realistic starting point for a production Blazor Server service: two CPUs, four gigabytes, restart on failure. Move the numbers up as your concurrent user count grows, and remember that circuit memory is reclaimed when sessions end, so overnight idle traffic costs almost nothing.
Blazor Server vs WebAssembly: Static Hosting and the API Backend
The WebAssembly line item that wins the comparison is delivery. WASM apps are static files, so CDN and static web hosting are cheap and globally distributed by design. The catch is that your data still needs a home. Every screen that reads or writes business data calls an API, and that API needs compute, a database, authentication, and hardening, the same components a Blazor Server deployment needs, just reached through HTTP instead of SignalR.
If your product is a public catalog with a small read-only API, WebAssembly is genuinely cheaper to host. If your product is an internal system where every page is behind a login and touches the database, the API server replaces the Blazor Server VM rather than removing it, and you have added serialization and CORS complexity without removing a single machine.
Blazor Server vs WebAssembly: A Side-by-Side Budget
- Compute: Blazor Server pays per circuit; WebAssembly pays per API call
- RAM: Blazor Server needs working set per session; WASM needs only API and database memory
- Delivery: WASM wins on static hosting and CDN; Blazor Server wins on single-process simplicity
- Operations: Blazor Server needs WebSocket-friendly load balancing; WASM needs CORS, rate limiting, and API versioning
- Developer cost: one deployable for Blazor Server versus a client, an API, and contract upkeep for WASM
For a small internal team the difference in monthly infrastructure is often smaller than the difference in operational complexity. A single Blazor Server container behind one reverse proxy is one thing to deploy, monitor, and scale. A WebAssembly app is a static site, an API, and the synchronization between them.
Why Indotalent Ships Blazor Server for Enterprise Apps
Every Indotalent product — CRM, HRM, CMS, OMS, SCM, WMS, SWM, and the SaaS multi-tenant editions — is a Blazor Server application. The reason is cost shaped by data access: enterprise screens keep data on the server, so the circuit model avoids duplicating every query over a REST API. Security also reduces cost, because connection strings and business logic never ship to the browser, so there is less to leak, audit, and defend.
For a SaaS multi-tenant product, the per-circuit model is predictable: tenants map to circuits, and the bill scales with active usage rather than with assembly downloads. That predictability is worth more than the pennies saved by static hosting, and it is why the MudBlazor-heavy admin screens in every product feel snappy on a modest VM.
FAQ
Is Blazor WebAssembly cheaper to host than Blazor Server?
Only when the API already exists. Static hosting is near-free, but the moment your WebAssembly app needs real data, you pay for an API, a database, and the integration work, the components Blazor Server already bundles.
How many users can a 4 GB VM serve with Blazor Server?
For a typical line-of-business app with an average circuit around 25 MB, a 4 GB VM comfortably handles a few hundred concurrent users. The scaling is predictable: double the users, add another VM or raise the memory limit.
Do I need a SignalR backplane to scale Blazor Server?
For a single instance, no. For multiple instances behind a load balancer, sticky sessions work, and a Redis backplane lets any instance resume any circuit when you scale beyond one machine.
What is the cheapest way to start with Blazor Server?
A single VM with Docker Compose: the app in one container and PostgreSQL or SQL Server in another. It deploys with one command and serves hundreds of internal users before you need to think about scaling.
Key Takeaways
- Blazor Server cost scales with RAM per circuit and peak connections; WASM cost hides in the API backend
- A typical circuit uses 10 to 40 MB, which lets you size a VM from your concurrent user target
- WebAssembly only wins on cost when the backend already exists or the app is read-mostly and public
- Indotalent ships Blazor Server because server-side data access makes the bill predictable for enterprise apps