September 10, 2026

Blazor hosting on a $6 VPS

A $6/mo DigitalOcean droplet (1 vCPU, 1 GB RAM) is enough to host a real Blazor app — WebAssembly or Server — if you know what you’re setting up.

Blazor WebAssembly

WASM ships as static files: HTML, JS, CSS, and your app’s compiled .wasm and .dll files. The server’s job is just to serve them efficiently, which nginx does well even on the smallest droplet. The main things to get right:

Brotli or gzip compression for the .wasm/.dll payload — it’s large uncompressed, and nginx can serve pre-compressed files instead of compressing on every request.
Cache headers. The build’s content-hashed files (everything under _framework/, mostly) can be cached forever; index.html and the boot manifest should not be, or a deploy won’t reach anyone with a warm cache.
SPA fallback. Any route that isn’t a real file needs to serve index.html with a 200, or reloading a client-side route 404s.

If you’re also serving an API from the same box, Blazor WASM’s static files add almost no load — they’re just files nginx hands out.

Blazor Server

Server keeps a live circuit (a WebSocket, by default) open per connected user, so it uses more memory and CPU per user than WASM does. A 1 GB droplet comfortably handles a small number of concurrent users; if you expect meaningful concurrent traffic, size up. The setup difference from a plain API is nginx’s WebSocket proxy headers (Upgrade, Connection) — without them the circuit can’t stay open and the app appears to hang.

Either way

Both need the ASP.NET Core runtime installed to match your project (Blazor Server always; WASM only if it’s served alongside an API), HTTPS (the WebSocket for Blazor Server needs wss://, so this isn’t optional), and a systemd unit if there’s a server-side process at all.

DotDeployer configures all of this automatically for whichever kind of Blazor app you deploy — see Supported runtimes.