Blazor on Azure: where to host it, and the settings that save you a bad Monday

Deploying a Blazor application to Azure takes an afternoon. Making it behave in production takes a little more knowledge: which service fits which kind of Blazor app, and a handful of settings that decide whether users get disconnected, signed out or shown an error after every release.

The short answer: a standalone WebAssembly application goes to Azure Static Web Apps. A Blazor Web App with server rendering or Interactive Server goes to Azure App Service. Container Apps is a good choice for teams that already work with containers, and Kubernetes is more than most business applications need.

Which service for which Blazor application

Service	Fits	Good to know
Azure Static Web Apps	Standalone Blazor WebAssembly	Served from a global network, has a free plan, and an optional API through Azure Functions
Azure App Service	Blazor Web App: static rendering, Interactive Server, Auto	The simplest choice for most business apps, with deployment slots from the Standard tier up
Azure Container Apps	Blazor Web App in a container	For teams already using containers, session affinity only in single revision mode
Azure Kubernetes Service	Large platforms with many services	Rarely worth the operational effort for one business application

Which render mode each screen should use is covered in Blazor Server vs WebAssembly vs Auto. The hosting follows from that choice, not the other way round.

Three settings Blazor Server needs on App Service

Interactive Server keeps a constant connection between the browser and the server. On App Service, three things decide whether that connection works well:

1. WebSockets on. Blazor works best over WebSockets, with lower latency and better reliability. Without them, it falls back to a slower transport.
2. Session affinity on. When the application runs on more than one instance, every user has to keep talking to the same one, because their screen state lives there. App Service calls this ARR affinity.
3. Azure SignalR Service, when there are many users. It is not required, but it takes over the connections when the number of users at the same time grows into the thousands.

The setting almost everyone misses: shared keys

ASP.NET Core protects sign-in cookies and forms with keys. On App Service, those keys are automatically shared between all instances of one deployment slot. But separate slots, such as staging and production, do not share them. After a slot swap, users can be signed out, and forms they had open can fail.

The fix is to keep the keys outside the application, in Blob Storage, protected with Key Vault:

builder.Services.AddDataProtection()
    .PersistKeysToAzureBlobStorage(new Uri(BlobStorageUri), new DefaultAzureCredential())
    .ProtectKeysWithAzureKeyVault(new Uri(KeyVaultURI), new DefaultAzureCredential());

The same applies to containers: a container that restarts loses its keys unless they are stored in a shared volume or an external store.

Releasing without surprises

• Deployment slots. The new version is deployed to a staging slot, warmed up, checked, and then swapped into production. App Service handles the swap without dropping requests.
• Interactive Server users see a reconnect. A swap or restart ends the live connections. Blazor reconnects automatically, but whatever the user had typed and not saved on the screen can be lost. Release outside working hours, or keep long forms saving as the user goes.
• Automated pipeline. GitHub Actions or Azure DevOps builds, tests and deploys on every change to the main branch, so nobody publishes from their own laptop.

Monitoring from day one

Every Blazor application on Azure should send its errors, slow requests and dependency calls to Application Insights, with alerts that reach a person. How to set that up and keep the bill down is in the article on Application Insights for .NET applications. And before the first release, go through the Blazor security checklist.

Before you choose

1. Is the application standalone WebAssembly, or a Blazor Web App with server rendering?
2. How many users will work at the same time, at peak?
3. Does your team already build and run containers?
4. How often do you release, and can users tolerate a reconnect during working hours?
5. Who will watch the application after go-live, and where do the alerts go?

How we work

We move Blazor and .NET applications to Azure and set them up properly: the right service, WebSockets and session affinity, shared keys, deployment slots, an automated pipeline and monitoring. We start with your application as it is today and the simplest setup that will carry it. More about our Azure work, and the first step is a free 30-minute call.

Sources

• Host and deploy server-side Blazor apps, Microsoft Learn
• Host and deploy standalone Blazor WebAssembly with Azure Static Web Apps, Microsoft Learn
• Deploy a Blazor app on Azure Static Web Apps, Microsoft Learn
• Data Protection key management and lifetime, Microsoft Learn
• Session affinity in Azure Container Apps, Microsoft Learn
• Set up staging environments in Azure App Service, Microsoft Learn