Azure Static Web Apps in depth

Azure Static Web Apps (SWA) is a feature-rich, convenient, low-cost hosting alternative to Azure Storage Static Websites or higher-priced ‘full-feature’ compute services like Azure App Service, AKS, Container Apps, etc. SWA has limited configurability and observability compared to other Azure compute services, but should pose no problem if you use SWA solely for a static site. There are many other limitations that I’ll cover further down, but SWA includes quite a few appealing features, most of which you can use for free:

Free Global CDN for static content
Free 3rd-party custom domain integration
Free SSL certs
Deployment slots (called environments)
Authentication
Server-side API endpoints hosted via Azure Functions
Client code access to some dbs via auto-gen REST/GraphQL API from Azure Data API builder
Simple Github/Azure DevOps integration (turnkey via Azure portal)
100GB/month free traffic
Fast setup and deployment with Static Web Apps CLI
Support and documentation for lots of front-end frameworks

You can find my low-cost hosting comparison of SWA, App Service, and Storage Static Websites in a previous post. For this post, I’ll go deeper into SWA’s pricing, benefits, drawbacks, and use cases/apps I believe it is best suited for to help you make the right choice. Also included are examples of setting up a new project, deploying with the Static Web Apps CLI (SWA CLI) or GitHub Actions, and monitoring.

Plans

Free – 2 custom domains, 3 staging envs, 250MB storage/environment (500Mb max total), authentication via EntraID / GitHub, az functions api, global CDN for static content. No SLA. 10 SWA resources per subscription
Standard – $USD9/app/month – 5 custom domains, 10 staging envs, 500MB storage/environment (2Gb max total), Custom authentication, BYO api functions, SLA, data overage, private endpoints for VNet integration, enterprise-grade edge CDN option. 100 SWA resources per subscription
Dedicated – $99/month – This is being retired Oct 2025, so I’m leaving this one out

More details are in Microsoft’s pricing and features pages, as well as the quotas.

Benefits

Ultra-fast deployment using the SWA CLI (makes it great to get simple sites/prototypes up potentially quicker than with app services az webapp up command in Azure CLI)
Support/samples for many front-end frameworks, including static apps React, Angular, Vue, Gatsby, Jekyll, and Blazor. Also support for node web applications like NextJS Hybrid and NuxtJS
SSL is already set up for the default <newapp>.azurestaticapps.net domain
Very simple custom domain setup (with free SSL)
Includes deployment slots (called staging envs, you can control creation via SWA CLI or your CICD)
Serverless backend API (via Azure function apps written in .Net, Python, NodeJS; not available for NextJS hybrid)
Password protection for site or just staging environments (on standard plan)
Integrated authentication (supporting turnkey GitHub/Entra ID auth, and custom auth to Apple Google etc on standard plan)
Database connectivity (in preview) via autogened Rest/GraphAPI with role-based access
Private endpoint for private-only webapp access via VNet (on Standard plan)

Drawbacks

No platform logging on the Azure side, making it hard to troubleshoot environment-specific issues (eg, app startup for Node served apps) compared to KUDU in App Services or running Dockerised applications
Limited updates to SWA’s GitHub repositories in 2025, features not coming out of preview for years, and pricing tiers being phased out ring alarm bells that this service could be left idle/phased out
Using features such as serverless APIs, database connections come at the cost of vendor lock-in / reduced app portability. You may also hit unexpected platform limitations, eg, API functions are limited to 45sec max execution time.
There are quite a few quota limits for the different plans that may catch your app out
Hosting configuration is mainly in staticwebapp.config.json and is quite limited; server (node) apps startup/preload scripts have to be set in your package.json
On the free plan, there’s no data overage fee; the site will no longer respond when it hits 100GB of traffic in a month. You can change the plan to standard without any disruption.
The traffic overage on the Standard plan is $USD0.20/GB, which is quite high compared to CDN competitors
While a Global CDN is included, it doesn’t mention a WAF (web application firewall) and has limited configurability (in staticwebapp.config.json) compared to what is available in Azure Front Door+WAF or other CDNs. Integration with Front Door is possible, but the plan for adding a WAF is very costly.
Alternatively, for a CDN+WAF, the turnkey Enterprise-grade CDN Edge option is an extra USD$17.52/app/month. It offers faster content delivery and DDoS prevention, but without any configurability (and perhaps less protection?) of Front Door’s CDN+WAF

Finding this article helpful? Please help out the blog:

Needs analysis and comparison

The following compares SWA to other Azure services’ prices and features. Before choosing which service to use (or Azure at all), it’s best to know your web app’s needs. Consider server features required, such as SLAs (SWA free has none), Network restrictions, CDN, WAF, SSL on Custom domains, and disk space requirements. Also factor in whether the app has code-based dependencies like APIs, authentication, databases etc. If it has any of these code dependencies or needs to run on Node (like NextJS hybrid), I’d recommend skipping SWA and considering these alternatives for reasons mentioned in the drawbacks and later sections.

The very affordable Azure CDN Standard from Microsoft is now unavailable and will be retired in September 2027. The lowest cost Azure CDN plan is now Front Door Standard and introduces a base monthly fee of USD$35 before numerous traffic fees. Adding a WAF to Azure Front door (premium plan) bumps the base price up to a staggering USD$330/mo. I’d recommend using a 3rd party CDN like for your low-cost/low-traffic Webapp+CDN+WAF needs. This is possible with SWA (at least for CNAME subdomains to my knowledge). I will mention which below services its possible to use an external CDN with.

Azure storage static websites

Even though SWA’s costs are so low, if your webapp is purely static (e.g., Node isn’t needed to serve) and you dont need a custom domain, WAF, CDN, URL rewrites, Custom HTTP headers etc; you could use Azure storage static web site and potentially incur no costs if the storage use is low enough. The site is only available on https://<yourstorage>.web.core.windows.net. If you need a custom domain with SSL or CDN, it’s best to go with SWA. It is possible to use custom domains, but only via Azure Front Door with the costs mentioned above.

Azure App Services

The F1 tier (free) App Service offers more observability and environment control to run Node apps and also opens up flexibility for your code dependencies, eg a Node-hosted API in Nest or Express. On this tier, CDN and custom domain with SSL isn’t possible via a 3rd party CDN and requires Azure Front Door. The B1 tier on Linux (lowest cpu / mem spec) for $13/month (at 720 hours use, this may be lower due to the 20-minute idle shutdown) allows custom domains with an Azure-managed SSL certificate but no CDN/WAF. On the B1 plan, you can integrate with Azure Front Door or additionally with 3rd party CDNs. Check here for App services plan features and limits. While App service’s setup and deployment complexity is slightly higher than SWA, it is quite low compared to the next two options.

Containerised services

Another ‘potentially’ low-cost option is Azure Container Apps (ACA) or Azure Kubernetes Services (AKS) scaling to zero; the latter is quite complex to set up and more costly to run. You would also need to cover the costs of a Docker container registry for both options and containerise your web app. To limit costs, you will also need to add a CDN (so pages are cached and the server isn’t called). ACA supports adding external custom domains with an Azure-managed SSL cert for free. To do with AKS is quite complex and would need extra Azure services. You can integrate Azure Front Door or 3rd party CDNs with both of these for your CDN needs, but the complexity is again much higher for AKS.

If SWA doesn’t meet your requirements, try adding the services and combinations above with the pricing calculator. If SWA meets your requirements, it could be a good fit, but before you decide, it’s best to read about some limitations below.

Migrating a NextJS Hybrid app into SWA

SWA includes support for node-served web apps (hybrid) like NextJS and NuxtJS rather than just serving static pre-built web apps. To test SWA’s capabilities for a web app using ISR and SSR, I attempted to migrate a very complex NextJS app from App Services. Support for non-static (hybrid) NextJS is currently in preview with a lot of limitations. Migrating hit several barriers; the Next.JS build needs to be set to ‘standalone mode’ due to the 250Mb storage limit on the free plan (but can be solved with the standard plan of course).

NextJS cannot be deployed via the SWA CLI, so a GitHub action was required to deploy to Azure. There were no platform logs to pinpoint start-up errors that were due to missing custom files expected by the customised “npm start” and missing environment variables I had not set in SWA. It was possible to get NextJS logging to Application Insights with a bit of witchcraft via a hacky custom code file using the NodeJS appinsights SDK called as a preload script inside the package.json “start” script before the nextjs server.js file.

After these hurdles, the app was running correctly. However, with these problems, the platform constraints on hybrid NextJS, very limited platform observability and configurability, and being in preview but never looking to go into GA (General Availability), I abandoned the idea of hosting the app in SWA. Running an app under Node like NextJS with GraphQL, you’d likely want to know the memory / CPU / storage available and be able to see metrics and platform logs to ensure it’s within resource limits and to check for any errors, but none of this is available, I have no idea what would happen if it exceeded whatever limits there are on the platform.

Monitoring your App

As mentioned, Observability with SWA is much more limited than with other compute services. Application Insights is only available out of the box for the API (function apps) feature. There are no platform logs available; many other compute services offer sending them to log analytics. Metrics are also limited compared to other compute services. I imagine this is in part due to the platform being far more abstracted than something like App Service and aimed at client-side code that isn’t executing on a server. This is fine until you want to use some of the advanced platform features, such as authentication or database connections. Not having any platform logs/diagnostics for this gives me the impression that if you have anything misconfigured, it would take trial and error to resolve.

The troubleshooting guide here mentions deployment and runtime troubleshooting, where deployment logs can only be checked via your CI/CD service logs, and runtime troubleshooting is only the API logs sent to App Insights. It is possible to send application logs for ‘non-static’ Node web apps like I did in the migration, but it is only useful once the app starts up correctly; if it doesn’t, the only observability you get is a ‘failed’ state shown on the portal overview page.

App development support

Using the SWA CLI, you can launch your app and its APIs (Azure function app) locally to emulate the hosted environment. There are also tutorials on using many top front-end frameworks with SWA. There is also the SWA VSCode extension to handle many actions available in the SWA CLI.

While the documentation is fairly thorough, including plenty of tutorials and samples, documentation on what’s going on behind the covers is sparse. In most cases, this isn’t a big problem, unless working with a non-static Node app or the server-side features.

What apps are suited for SWA?

Based on the above, SWA seems best suited for (unsurprisingly) static web apps, not node-served ones like Next/NuxtJS. A service without deep server metrics, such as CPU / mem, and no platform logging hints that this wasn’t originally intended for Node-served apps.

Scenarios that I think are best for SWA would be hosting a simple to moderately complex app, and only the static app. It’d be best not to lock code into other server features, like APIs or database connectors, unless it is quite small/simple, and you don’t expect more enhancements. There’s plenty of development time and hosting costs that can be saved, but in the case of APIs, building them as Azure Functions needs to be weighed up.

The reasons I’d avoid using the APIs or database connectors for more complex apps are control, portability, and flexibility. These features have constraints, which you may come up against during initial development or when adding a new feature. For database connectors, you dont have control over the generated API’s code. An example of one limitation that could catch people by surprise is that API Function app request handlers can only run for 45 seconds max. From what I see on GitHub, this SWA’s maintenance seems to have gone quite ‘radio-silent’ in 2025, which makes for another good reason to avoid vendor lock-in.

If you find the SWA features compelling, but have a complex app, it would be best to host the API or any other server-side dependencies elsewhere. It’s also worthwhile to compare whether hosting the whole app (front and backend) on a different single service is more beneficial.

It’s not all doom and gloom; SWA is perfectly fine (even great) for the right type of app and needs. Read on to test it out.

Tutorial: Create and deploy a Vue app with SWA CLI

Prereqs: Azure CLI (logged into your account), Node 20+

1. Create an Azure Static Web App (options you can choose for -l: westus2,centralus,eastus2,westeurope,eastasia)

az group create -n mytestswa -l eastus2 
az staticwebapp create -n mytestswa -g mytestswa -l eastus2

2. Create a Vue app

npm create vue@latest (call the projectname: mytestswa and accept all defaults)
cd mytestswa
npm i
npm run dev (use default prompts)

You can now view the website on the localhost URL as shown below:

3. Deploy the app using SWA CLI

Now add SWA to your app, log it into your Azure resource, build and deploy

npm i -D @azure/static-web-apps-cli (to install the swa cli into the current project)
npx swa init --yes (this accepts all defaults)
npx swa build 
npx swa login -g mytestswa -n mytestswa
npx swa deploy --env production

You can view the deployed Vue app from the link in the output look like the below in a browser.

Congratulations, you now have a Static Web App up and running!

You can remove your static web app if you like (it is free) using:

az group create -n mytestswa

Troubleshooting

If you have errors on the deploy (like ✖ Resource provider ‘Microsoft.Web’ failed to return collection response for type ‘staticSites’.) try using the deployment token on the final step (npx swa deploy) rather than the default integrated auth:

az staticwebapp secrets list --name mytestswa --query "properties.apiKey"
npx swa deploy --env production -d <apiKey>

If there is an SSL-related build issue, you may need to set this env var in your cmd prompt:

NODE_OPTIONS="--openssl-legacy-provider"

If the deployment succeeded, but the website is showing the Azure placeholder page. Add a file ‘staticwebapp.config.json’ to the mytestswa folder you are in with the content below and redeploy.

{
    "navigationFallback": {
        "rewrite": "/index.html"
    }
}

Integrate SWA with CI/CD

There are alternative ways to deploy to a Static Web App. The most common being via CI/CD in GitHub actions or Azure DevOps Pipelines but there is support for GitLab and Bitbucket. You can specify a GitHub/Azure DevOps repo you wish to deploy from when creating a new SWA in the portal, OR you can add a GitHub action like below in a file such as .github/workflows/build-and-deploy-yaml.

The example workflow file below can be used with the above project and is what the Azure portal auto-generates if you specify a GitHub repo during creation. With this CI/CD, if you create a pull request, a new Static Web App environment (non-production url) will be created with the branch name, and main will deploy to production. Before pushing this file into your GitHub repo, you’ll need to set the deployment token mentioned in the tutorial as a GitHub action secret called AZURE_STATIC_WEB_APPS_DEPLOY_TOKEN. More documentation on this GitHub action is here.

name: Azure Static Web Apps CI/CD
on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: true
          lfs: false
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_DEPLOY_TOKEN }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "dist" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_DEPLOY_TOKEN }}
          action: "close"

Wrapping up

Given that some SWA features have been in preview (NextJS hybrid, DB connectors) for multiple years, and the highest plan has been removed, it gives the impression SWA has just been left idle. From this, I’m wary it may even be shelved in the future. I would advise caution in committing a large/complex app’s code to use the server-side features. Another indicator of SWA being ignored is the unanswered questions on the Azure/static-web-apps-cli and Azure/static-web-apps GitHub repos. Users are asking if SWA is still being maintained. There hasn’t been a SWA CLI npm package update since April 2025 at the time of writing, with a trickle of PRs since then.

If your web app is not truly static (eg, it has Node server-side elements like NextJS hybrid), I recommend using another service for the reasons covered earlier. If you need an API, database access, auth, or other server-side features, and the app is complex or constantly growing, it’s best to put those server-side components elsewhere or consider putting the whole app (front and backend) on a different service. Doing this provides much more control, observability, portability, and flexibility for complex applications.

If you have any feedback or thoughts, please leave a comment. I hope this post has given you a good insight into deciding to use Azure Static Web Apps!