Frontend hosting is a solved problem that teams keep unsolving with overbuilt infrastructure. For single page applications and static sites, Azure Static Web Apps packages hosting, global distribution, TLS, CI, preview environments, auth, and an API story into one resource with a generous free tier, and the right response is usually to just use it.

The Developer Loop Is the Product

Point SWA at your repo and it writes the GitHub Actions workflow: push to main builds and deploys production, and every pull request gets its own preview environment at a unique URL, torn down on merge. That per PR staging environment is the feature teams fall in love with, reviewers click a link and see the change running, and it costs zero setup. The configuration lives in one file, staticwebapp.config.json, which handles the concerns that otherwise scatter across a web server config and a CDN console:

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/assets/*", "/api/*"]
  },
  "routes": [
    {
      "route": "/admin/*",
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/api/orders/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": { "redirect": "/.auth/login/aad", "statusCode": 302 }
  },
  "globalHeaders": {
    "Content-Security-Policy": "default-src 'self'; script-src 'self'",
    "X-Content-Type-Options": "nosniff"
  }
}

SPA fallback routing, role gated routes, login redirects, and security headers in twenty lines. The built in auth wires Entra ID, GitHub, and custom OIDC providers with no SDK: the platform handles the flows, exposes the user principal at /.auth/me and in a header to your API, and the invitation system assigns roles for small internal apps. For enterprise apps you will connect your own Entra registration, but the mechanism is the same file.

APIs: Managed Functions or Bring Your Own

The /api route can bind to managed Azure Functions deployed from the same repo, ideal for the BFF pattern where the frontend needs a thin API for tokens, aggregation, and secrets it must not hold. Beyond the managed option, the Standard tier links existing backends, a full Function app, App Service, Container Apps, even APIM, behind the same /api path with auth flowing through, which keeps the frontend origin clean and CORS out of your life. That linking is how SWA composes with this series: the SPA on SWA, the real API on Container Apps behind private networking from the earlier posts, linked and authenticated platform side.

Honest Boundaries

Know when SWA is not the tool. Server side rendered frameworks at scale, heavy Next.js with ISR and middleware, fit App Service or Container Apps better than SWA’s hybrid support. Apps needing the full edge feature set, custom WAF tuning, rate limiting, Private Link origins, belong behind Front Door Premium with storage static website hosting or SWA’s enterprise grade edge option. And truly private internal apps conflict with SWA’s globally public edge model; private endpoints exist for it, but at that point App Service with Easy Auth from yesterday’s post is often the simpler shape. For everything else, the public marketing site, the SPA product frontend, the internal dashboard with a dozen users, SWA is the least infrastructure that fully solves the problem, and least infrastructure is a virtue this series keeps arriving at.

Cheers
Osama