What is a static web app?

An Azure Static Web App is a way to host a static website that consists of web pages, images and other resources that are static/fixed, they have been created before the website is deployed to the hosting location.This is the type of hosting that is free for personal/hobby projects. Azure Static Web App also allows the website to have an API that is implemented in code that runs on a web server. That part is free for a low volume website (up to 1 million calls per month in 2025). The API part is essentially a deployment to Azure Functions that is combined with the website so that the API lives in the same (sub)domain as the website. My notes on the Static Web App are written for a static website without API.

The first time working with an Azure Static Web App is a bit confusing. There are a lot of websites and videos that offer a click-through for the various tools and interfaces. But I couldn't find a more conceptual description how it works, which components must be involved and where design decisions can be made. So let's write it down for a future me.For a more hands-on description, see how to create and how to publish to a Static Web App.

An Azure static web app can be viewed as a component that is provided as part of the Azure infrastructure to host a bunch of files. On the output side, an end user (or tester/developer) can access the files only via HTTP by specifying an URL. On the input side, the files to host plus some configuration files have to be published to Azure and then replace the existing content. The app is identified by a deployment token. Azure provides tools that should be used for the publication of the files; the interaction between the tools and the Azure cloud is a black box.

When a static web app is created in the Azure portal, the deployment token and a non-guessable subdomain for HTTP output is generated. The subdomain name can be replaced by a custom domain for the production website. The Azure portal is also used for the administrative tasks for the app, e.g., the users wha have access to the app (the user roles are part of the configuration). There is (in 2025) no way to pause to park the app if you don't need it for some time. If it is created, the Azure infrastructure control its execution. Apparently Azure is smart enough to stop paying attention to the app if it is not used.

A lot of websites and videos describe how to publish the files with Visual Studio or Visual Studio Code (from a development environment) or from Github, Azure DevOps or similar. That is confusing: the Azure publication tools do not care where the input files come from. You can have any deployment process you want, as long as the last step is the use of the Azure publication tool.