A while back, I wrote about migrating a static site to Microsoft Azure. Since then, Azure has matured their Static Web Apps offering, which is intended to be a more or less turnkey way to get a simple JAM stack web application up and running. The potential benefits are many: it’s free tier is more than sufficient for hosting the required traffic for my blog, it offers out-of-the-box (public) staging environments, and it integrates seamlessly with Github actions without any need to muck with Docker images or CLI commands. The service also provides you with free SSL certificates.

Before I go further, let me run down what’s needed to host a static site “by hand”:

• A Storage Account configured to host a static website;
• Front Door and/or a CDN to enable TLS and to prevent DDoS from running up your serving costs;
• A Key Vault to manage your SSL certificate;
• Custom domains configured in the CDN endpoint;
• A Log Analytics workspace;
• An externally-purchased SSL certificate;
• A DNS Zone (optionally);
• CI/CD configured to build and deploy using the Azure CLI.

Azure Static Web Apps gives you all of this out of the box, including automatic detection of your static site generator based on your repository structure. This is really convenient and extremely simple to get set up. Azure Static Web Apps gives you:

• Simple routing and reverse-proxy capabilities;
• Zero-configuration CDN;
• Free SSL certificates with zero management overhead;
• Free custom domains (you have to purchase the domain name itself but you can hook them up with no added charge);
• Basic logging and monitoring;
• Automatic Github actions CI/CD integration;
• Free staging environment;
• Authentication.

After poking around with it, I found it quite easy indeed to get my static site up and running on Azure’s Static Web Apps service. However, there was a huge missing feature that meant I need to keep hosting the site the hard way. Namely, the Static Web Apps service doesn’t expose a storage layer, so if you want to directly host any files, there’s no clear way to upload them. Even the Github actions obscures this process. This means that only items built in CI will be deployed, which means you have to somehow version control large files, such as photos.

Moreover, the routing isn’t advanced enough to do stateful matching, meaning that even if I wanted to create my own storage solution for hosting my images, I couldn’t perform an automatic redirect to, for instance, a photos.emilygorcenski.com subdomain. It just wasn’t possible using the routing rules as they were documented.

These are two huge weaknesses, in my opinion. The Static Web Apps solution gets you up and running quickly, but there are a bunch of use cases I can think of where being able to host large files like photos, videos, or PDFs would get quickly out-of-hand if you tried integrating them with version control. Even git LFS has a fairly low limit. Another disadvantage is that the staging environment is public, unless you opt for the paid version, in which case you can implement password protection.

Configuring all the services by hand, or with Terraform, is a lot of work. Especially if you want to set up multiple environments, which is a huge pain in the ass. But many of the services you’ll end up configuring, like Key Vault, will be useful if you want to extend your application to include other services. This makes it easier to change the architecture of your setup later on. Static Web Apps does so much for you and hides so much machinery under the hood that it makes it much more difficult to transition off later.

Considering that it only takes a couple extra days to configure the services by hand, I’d say that unless you only expect very simple use-cases, your best bet is still to configure the site by hand. Altogether, my setup only costs me about $4 monthly and I have a lot more control for that cost. For very simple sites, Static Web Apps is the clear winner. But with even a little added complexity, setting up your own infrastructure is worth it in the end.