Although the two have a lot in common, even including parts of the name, there are a few very clear differences between
Static website hosting in Azure Storage and Static Web Apps. We’ll have a look at what those differences are and
take a first look at the most recent of the two: Static Web Apps.
Static website hosting in Azure Storage
Static website hosting is a feature you can enable free of charge on a storage account. This feature is available on
general-purpose v2 Standard storage accounts and not in any other types. Enabling the feature creates a $web
container where you can host your static files. It’s even possible to setup a custom domain for the static website.
Static Website hosting also has some limitation which are listed below.
CORS is not supported
No support for HTTPS with custom domains
Unable to configure headers
The second and third are relatively easy to solve by adding Azure CDN.
The static website can, of course, connect to an external API like for example an ASP.NET Web API or HTTP triggered
Azure Functions. It doesn’t do anything for that, it just enables you to call them. If you’re the one developing
this API, you’re responsible for deploying and hosting that API. That’s where Static Web Apps come in …
Static Web Apps
A modern web app service that offers streamlined full-stack development from source code to global high availability.
Static Web Apps seems more like a combination of several services bound together in an Azure-branded offering. It combines
the power of source code control from GitHub, CI/CD with GitHub actions, something that acts a lot like static website
hosting and the awesomeness of Azure Functions. Together, they automatically build and deploy full stack web apps,
consisting from to Azure from a GitHub repository.
So… what does it do?
The workflow of Azure Static Web Apps is tailored to a developer’s daily workflow. Apps are built and deployed based
off GitHub interactions.
When creating an Azure Static Web Apps resource, there’s a GitHub Actions workflow created in the repo you specify upon
creation. This workflow automatically builds and deploys your app, and its API if you specified it, to Azure on each push
to (or PR that is accepted into) the branch you specified.
Static assets are hosted in Azure and will be served from points physically close to the users. The accompanying API
endpoints are hosted using Azure Functions which eliminates the need for a back-end server completely.
Creating an Azure Static Web App
When creating a Static Web App, the Azure portal asks you to specify a couple of things. Most importantly, you need to
sign in with GitHub and pick the repo and branch you would like it to keep an eye on. This is the repo the GitHub
Actions workflow is created in, and the branch that triggers it.
Next up: specifying where to find what to build and where the output goes. As you can see in the screenshot below, the
first input needed is ‘App location’. This is the folder where the frontend you want to build can be found in the repo.
It defaults to the root (/).
The second input, ‘API location’, is optional. It holds the location of the API that goes with your frontend. If you don’t want to specify
it now, that’s not an issue. However, you do need some GotHub Action / YAML knowledge if you want to add it later.
The final input asks for the artifact location. This is the location of the build output relevant to the App location.
So if youset App location to be ‘/src’ and Artifact location to be ‘public’, the content at ‘/src/public’ will be pushed
to the static web app.
After you’ve created the static web app, you would expect the app to be available at something like staticwebappname.azurestaticapps.net.
Or at least I expected this. This is not the case, however. A globally unique name is generated for you and used in the URL.
The static web app I created when I took the screenshots got the name mango-smoke-022564a03.
Management from the Azure portal
The Azure portal doesn’t provide a lot of options to manage the static web apps. Most of what you configured when creating
it ended up in the GitHub Actions workflow. They do, however, link to connected resources in GitHub. Like for instance
recent runs, the workflow file and the repo the static web app is connected to.
The portal does enable you to add some environment specific (more info on this later) configuration settings, add custom
domains and look at the Functions that are connected to the static web app. You do not have any say in how those Functions
And then there’s the ‘Environments’ menu item. This is maybe one of the most powerfull features of Static Web Apps,
Staging environments are automatically created when a pull request is generated, and are promoted into production
once the pull request is merged.
That’s kind of a BIG DEAL. I tested it out by creating a separate branch on my GitHub repo, completely changing the
design of the website and creating a PR. And it worked. It created a separate environment that showed me the
result of what the website would look like if the Pull Request were to be merged.
There’s Access control (IAM) like on other Azure resources. Role management, Locks and the possibility to export a
template complete the Blades for static web apps. For now.
If you got all the input correct on the first attempt, you’re probably good to go. When I created my first static web
app a while back I started with an Angular frontend and later on added the API. I had to change some stuff in the
workflow file and search around a bit to make sure I had everything in place.
If you’re interested in the entire workflow file, have a look at the aswa-example repository,
but I’ll add the most important part here:
###### 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: 'aswa-frontend'# App source code pathapi_location: 'aswa-api'# Api source code path - optionalapp_artifact_location: 'dist/aswa-frontend'# Built app content directory - optionalapp_build_command: 'npm run build-prod'###### End of Repository/Build Configurations ######
The app_build_command defines a custom command to build your frontend. By default, it tries to run the npm run build
or npm run build:Azure commands. Because my frontend was an Angular app, and the documentation on Custom build
has an example that you can run ng build --prod to build an Angular app, I thought I was good to go. Unfortunately
(and of course) the Angular CLI is not installed globally, which is needed to call it to build an Angular app. That’s
why I now have a Pull Request open to change the example in
the documentation. 😁
Static Web Apps are a first (?) but very powerful step into bringing Azure and GitHub closer together. Or better yet: to
having seamless integration between the two. But as an Azure service, it feels a bit like the odd man out.
The most important reason for me to feel that way is the fact you (currently) have no control over what’s happening in your
Azure environment once you’ve created the static web apps resource. All the settings you did while creating the resource
landed in the GitHub action and are not editable from the Azure portal anymore. Currently, static web apps are in preview.
So this may change. But since that would mean parsing a YAML file that might have been changed entirely from the GitHub
side, I think this is unlikely. But I’d love to be proven wrong there. 🤓