Moving the blog to Azure Static Web Apps

In the last blog post, I wrote that I might be moving the blog from my custom server to Azure. A few weeks ago I spent a few hours doing just that, and now finally got around to writing a blog post about what I to setup the blog on Azure Static Web Apps.

What is Azure Static Web Apps?

That might be the question on your mind right now, so before diving into detail, let's go through same of the main features of Azure Static Web Apps.

Microsoft's own description for Static Web Apps is:

Accelerate your app development with managed global availability for static content hosting and dynamic scale for integrated serverless APIs. Experience high productivity with a tailored local development experience, CI/CD workflows to build and deploy your app, and unified hosting and management in the cloud.

The first statement refers to the fact that Azure Static Web Apps can be configured with enterprise grade edge, which adds Azure Front Door and Azure CDN in front of the web app. I did not find anything in the docs that would clearly state whether the free plan has anything related to global availability, but at least it does provide access to serverless APIs, i.e. Azure Functions, which is the feature referred to in the latter part of the first sentence. The second sentence refers to the fact that Azure Static Web Apps can be connected to a Git repository hosted in at least Github or Azure DevOps, and can build and deploy the app from source code with support for most if not all of the popular Web Frameworks developers use today, including Astro that this site is built on.

I'm not leveraging most of these features. What I like about Azure Static Web Apps is that it provides me with a basically free hosting platform that handles SSL certificates for me, so I can be confident that anyone using this site will be able to access it through a secure connection. Since the blog is not hosted on the apex domain, adding a custom domain can be done with simply adding a CNAME record pointing to the domain of the Azure Static Web App.

Azure Static Web Apps does seem to provide a really nice set of features for web app development, including preview environments, CI/CD pipelines etc., although it might be that you need to tie yourself pretty heavily into Azure to leverage those benefits. But if you're an organization running your cloud workloads on Azure, and need a powerful yet simple way to deliver static content, Azure Static Web Apps could be a great fit. If you want to read more about Azure Static Web Apps, the pricing page provides a nice list of features in the free and paid plans and the free quotas included, while the documentation page is the best way to dive into details of the service

Blog setup after the move

After moving the blog over, I have the following setup in place. Content for the blog lives in CMS (Storyblok), and the code is on Github. Pushing a specific tag to the Github repo triggers a workflow that builds the blog website and deploys it to Azure Static Web Apps using a Github Action from Microsoft.

The process of publishing the site is now a little bit simpler. Instead of having to ssh into my server, pulling potential code changes to the server, building the site there and replacing what's being hosted with Nginx to the new content, I just push a tag to Github and the workflow does the work for me. I think Storyblok provides a way to trigger workflows in Github via a webhook, which would eliminate the need to even push a tag, but I did not have time to explore this option further.

Setting up the blog on Azure Static Web Apps

All the code needed to make this setup happen are in the blog repository.

The terraform directory contains three terraform modules, state, gh-actions and blog. I wanted to do the infrastructure with Terraform and figured these three steps would need to be taken to be able to deploy to Azure with Terraform. In the end, The Azure Static Web Apps action did all the deployment work needed, so none of the terraform is necessary for the setup to work. If you would like to be able to deploy to Azure with terraform, the state module provides a way to store your tf state in Azure, and the gh-actions module provides a way to authenticate your GitHub Actions with Azure so that it can be used to access the state and deploy new resources. I used the Contributor role, which is very open, so you might want to narrow down the access of your GH Actions more tightly in a real project. Lastly, the blog module creates the actual Azure Static Web App, so that it's ready to receive deployments. For the custom domain, you will need to get a domain from e.g. namecheap.com, and setup a CNAME record pointing to the Azure Static Web App so the SSL certificates are validated. The setup for an apex domain is a bit more complicated, you can check the documentation for more info on that.

The workhorse for the deployment process is the publish workflow in the Github repo. It builds the site with data from CMS, authenticates with Azure, and deploys the site to Static Web Apps. I opted into building the site myself, but the static web apps action could handle that part as well. At less than 50 lines, this is a very straightforward CD pipeline. If I had any tests for the site, this would be the place to run them to prevent bugs getting to the deployed site.

Experience with Azure Static Web Apps

The service seems to work great, providing fast response times and a nice deployment experience. I have been running the blog side-by-side on Azure and on a Hetzner server with Nginx for about a month now, and the site is faster on Azure, scoring 100 on Lighthouse performance metrics (on Hetzner, the site scores 99). The setup is a bit more complicated compared to something like hosting a static site on S3 in AWS, but provides lots of extra features like Azure Functions etc. if those would be needed. Overall, I feel like Azure Static Web Apps ticks a lot of the boxes for hosting content focused websites. For hobbyists, the fact that it's such a low cost option (basically free) is nice. For organizations, if your cloud workloads are on Azure, you should consider putting at least some of your marketing pages on this service.

That's all for this time. Hope you enjoyed reading!