Deploying a Blazor WebAssembly application to Azure Static Web Apps

Blazor WebAssembly lets .NET developers build rich interactive web experiences entirely in C#, running directly in the browser without server-side rendering. Pairing that framework with Azure Static Web Apps gives teams a managed hosting platform that handles HTTPS, global content delivery, and pull-request preview environments with very little operational overhead. For Australian developers this combination is particularly attractive because the Azure Sydney and Melbourne regions keep latency low for users between Perth and Brisbane, while a static front-end avoids the licensing and infrastructure costs that come with always-on App Service plans.

Before diving into the deployment pipeline, it helps to clarify what each piece of the stack contributes. Blazor WebAssembly delivers the application logic and user interface through a downloadable runtime and a set of DLLs, while Azure Static Web Apps adds the hosting layer, a reverse proxy, free managed certificates, and optional serverless API endpoints backed by Azure Functions. Together they form a development workflow that mirrors how many small teams across Melbourne and Sydney already publish Jamstack-style sites, only with C# in place of JavaScript.

Preparing the project and local tooling

The starting point is a Blazor WebAssembly project targeting .NET 8 or later, although the same flow works with .NET 6 and 7. Open a terminal on your development machine and scaffold the app with the standard template: dotnet new blazorwasm -n Contoso.TradePortal. Restoring packages on Australian home connections can occasionally stall behind certain NBN plans, so configuring the NuGet client with a closer feed, or pointing Visual Studio toward a local package cache, removes one common source of friction. Once the template compiles, run dotnet run and confirm that the counter page and the weather forecast sample both render correctly on localhost.

Next, think about the production build output. Publishing the project with dotnet publish -c Release -o publish produces an optimised bundle with trimmed, ready-to-serve assets. Blazor WebAssembly apps also benefit from compression, so add a wwwroot inspection step to confirm that the runtime DLLs and the blazor.boot.json file are present. Many Australian teams work in regulated industries such as healthcare, mining, or financial services, where the Privacy Act 1988 and the Australian Privacy Principles govern how personal data is handled. Even though a static front-end does not store user records on the server, configuration values baked into the wwwroot folder can leak secrets, so storing connection strings or API keys outside the client payload is essential. Use environment-specific appsettings.json files or Azure App Configuration to keep sensitive data on the server side.

Before pushing anything to a remote repository, create a .gitignore that excludes bin, obj, publish, and the .vs folder. Add a README.md that documents the build command, and commit everything to a new GitHub repository under your organisation. From this point forward Azure Static Web Apps will require a GitHub workflow file, so the clean structure set up here pays off once the pipeline starts generating preview environments.

Creating the Static Web App resource and linking it to GitHub

In the Azure portal, sign in and select Create a resource, then search for Static Web Apps. The wizard asks for a subscription, a resource group, and three deployment details: the source provider (GitHub), the repository, and the branch that should map to production. Australian organisations often prefer the Australia East (Sydney) or Australia Southeast (Melbourne) regions for data residency reasons, particularly when the Notifiable Data Breaches scheme is in scope, although the Static Web Apps service is regional and currently offers these zones for the managed Functions backend. The static content itself is served through the global edge, so end users in Adelaide, Hobart, or Perth still receive cached assets from the nearest point of presence.

Once the resource is created, Azure automatically generates a GitHub Actions workflow file in the repository under .github/workflows. The default file assumes an Angular or React layout, so the next step is to customise it for Blazor. Open the file and locate the build and deploy job step, then adjust the app_location, output_location, and api_location values. For a Blazor WebAssembly project the app_location is typically the project folder, the output_location is wwwroot, and api_location can be omitted unless a Functions backend is present. Save and commit the change; the workflow should trigger a fresh run within seconds.

During the first deployment the workflow installs the .NET SDK, restores packages, publishes the project, and uploads the contents of wwwroot to the Static Web Apps service. The URL of the deployed site appears in the Azure overview blade, in the format https://<random-name>-<hash>.azurestaticapps.net. Open it from a mobile device connected to a Telstra or Optus SIM to confirm that the assembly downloads quickly and the interactive pages work as expected on 4G and 5G networks.

Designing a CI/CD pipeline that suits Australian teams

A continuous integration pipeline is more than a single deployment job. Adding explicit steps for restore, build, and test catches regressions before they reach production, which is especially valuable when engineers contribute from different time zones across Australia, New Zealand, and parts of Asia. Splitting the workflow into separate jobs for build, test, and deploy keeps the YAML readable and lets failed tests block the deployment without affecting the static asset upload.

A typical workflow skeleton looks like this:

name: Azure Static Web Apps CI/CD

on:
  push:
    branches: [ main ]
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches: [ main ]

jobs:
  build_and_test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 8.0.x
      - run: dotnet restore
      - run: dotnet build --no-restore -c Release
      - run: dotnet test --no-build -c Release

  deploy:
    needs: build_and_test
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 8.0.x
      - run: dotnet publish src/Contoso.TradePortal -c Release -o output
      - uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          action: upload
          app_location: src/Contoso.TradePortal
          output_location: wwwroot
          skip_app_build: true

Pull request previews are one of the most underrated features of the service. Every PR automatically receives a temporary URL, allowing reviewers in Brisbane or Perth to interact with the change before merge. After the PR closes, the preview environment is removed, keeping costs predictable.

Adding a custom domain, routing, and authentication

Once the default URL is up, most teams want to attach a real domain. The Static Web Apps blade offers a Custom domain option that walks through CNAME or A record validation. For Australian businesses this is often a com.au or net.au address managed through local registrars such as Netregistry, VentraIP, or Crazy Domains. After pointing the DNS record, the portal provisions a free managed certificate, which removes the operational burden of renewing TLS certificates manually.

Application routing for Blazor WebAssembly relies on the fallback document setting in the staticwebapp.config.json file. Place the file inside wwwroot with contents similar to:

{
  "navigationFallback": {
    "rootPath": "/index.html"
  },
  "globalHeaders": {
    "X-Content-Type-Options": "nosniff",
    "X-Frame-Options": "DENY",
    "Referrer-Policy": "strict-origin-when-cross-origin"
  }
}

Authentication can be wired in without writing code through the built-in providers for Microsoft Entra ID, GitHub, and X. For enterprise customers using Microsoft 365 the Entra ID provider aligns neatly with existing identity infrastructure, and conditional access policies travel with the user. The auth config lives in the same staticwebapp.config.json, and role assignments can be enforced through route-level rules that restrict sensitive areas of the application to specific groups.

Observability, performance, and compliance

After launch, the work shifts to monitoring. Azure Static Web Apps exposes request counts, response codes, and bandwidth through Azure Monitor metrics. For deeper diagnostic data, connect Application Insights by adding a connection string in the staticwebapp.config.json or through a small JavaScript snippet that calls trackPageView from the Blazor component lifecycle. Australian teams bound by the Privacy Act should confirm that telemetry collection does not inadvertently capture personal information, and review the data flow statements required under the Australian Privacy Principles before enabling verbose logging.

Performance tuning focuses on two areas: bundle size and edge delivery. Enabling response compression, turning on Brotli at the edge, and trimming unused assemblies with the .NET trimming tool each contribute to a leaner first load. For Blazor WebAssembly specifically, lazy-loading additional Razor assemblies reduces the initial download, which matters for users on slower NBN satellite services in regional Queensland or Western Australia. Combining these optimisations with a sensible caching policy and a content security policy header produces a site that feels responsive across the continent, from a coworking space in Barangaroo to a home office in Geelong.