Chicago Maybe © 2022 James Leonardo
Chicago Maybe © 2022 James Leonardo

After less than a month, I just cut the site back over to Azure. I am using a new approach that wasn’t available way back in 2017 when I first set up the site: Azure Static Web Apps. GitHub Pages was a nice experiment, but Azure Static Web Apps are more flexible. It’s still really simple to set up and publish. Read on for a little more info.

Azure Static Web Apps is an Azure service that is designed to automatically build and release a web app that doesn’t have server side code. That suits Jekyll perfectly. Jekyll is a blogging framework that generates HTML from easy to write and read Markdown files. That generation happens when you publish the site, not on the fly, so it doesn’t need anything to run on a server. I wouldn’t try to do anything big and complicated with Jekyll, but it’s pretty slick for a lone, part-time author.

Microsoft docs has a tutorial on how to publish a static site using Jekyll. I pretty much just needed to start at the Deploy Your App section because I already had the code and content for the Jekyll site in GitHub.

It took just a few minutes to get set up, then a few more to reconfigure https://www.jimsrules.com and https://www.jimsrulesregardingeverything.com to go to the new Azure service instead of GitHub Pages.

Why did I make this move?

  1. GitHub Pages does not support multiple domains. Azure Static Web Apps does support up to 2 custom domains for a single site in the free tier. On GitHub, I was actually publishing the site twice. Once to a website for jimsrules, once for the alternate (old) domain, jimsrulesregardingeverything. Because GitHub Pages also needs a file that contains the root url in the code repository and there can only be one root url in that file, I had to do some code repository gymnastics to publish. I could have messed around with the GitHub action to fix the issue with the file, but I would always need two sites to have 2 root urls. Simpler is better, Azure was simpler on this count.
  2. GitHub Pages does not allow you to set custom HTTP headers. Good security practice requires setting some headers to protect against a variety of attacks. I have very little attack surface, but I do serve a couple of things from Creative Commons. That leads me to want to set up the Content-Security-Policy, Permissions-Policy, and X-Frame-Options headers. Once on Azure, it took me just a few minutes to get back to the A+ rating from SecurityHeaders.com that I had before switching to GitHub Pages. Once in Azure, it took maybe 5 minutes to set those headers up. Most of that was just figuring out what options I wanted to use for Permissions-Policy.

So far, I’m getting the benefits of quick deploy and blogging bliss that I was hoping for when I moved to GitHub Pages. I’m also getting the benefits of easy configuration and preserving a few options to go beyond a basic website without having to redo all the existing content. And it’s Azure. I’ve lived so much of my life working on Azure products that it feels like I’m back home.

At least until I find the next thing I don’t like.