Creating an Azure Static Web app (moving from WordPress, part 2)

Back in 2022, I decided it was time to move on from WordPress to a platform where I had more control. When I say “more control,” I don’t mean I wanted to manage servers and operating systems, only that I wanted to step outside of the confines of WordPress and the constant nagging to upgrade when I wanted to do something new.

In Part 1, I gave an overview of my decision to move from WordPress to a static site generator. In this installment, I want to talk about hosting, why I chose Azure, and how I made it all work.

One of the benefits with WordPress is that someone else hosted it, and all I was responsible for was WordPress itself. Unfortunately, everything else was a pain in the ass. Want to make SEO easier? It’s an upgrade and an additional expense. Blah. No thanks!

Hosting on Microsoft Azure

I had some options for hosting since the site was being statically generated. Many people use GitHub pages for this, and in fact the friend that turned me on to SSGs was hosting his blog on GitHub pages. I wanted to be different though, AND I was trying to get more experience with Azure, I decided to see what kind of effort it would take. I didn’t have any Azure credits to use, but I figured if I could do it for less than I was spending on WordPress, it was worth a try.

A quick search turned up Azure Static Web apps, so I logged into my Pay-As-You-Go Azure account and looked up Azure Static Web apps and clicked the ‘Create’ link.

Clicking the link brings up the familiar Azure resource creation page. I created a dedicated resource group for the web app, and all it contains is the Static Web App, but I could certainly add other resources if needed.

The key pieces after picking the subscription, resource group, and Web App name begin with the Hosting Plan. You have the three to choose from: Free, Standard, and Dedicated (which is in preview as of June 12, 2024).

I selected the ‘Free’ plan because it met my needs. This is a screen shot of what’s offered in the Free plan as of July 12, 2024:

After selecting the plan, the next step is picking a Deployment and configuring. The options are GitHub, Azure DevOps, or other. If you select Other, you’re on your own from here on out.

All of my personal work is on GitHub, so I selected that option and made sure my GitHub account was linked. After that, it’s as simple as picking the organization, repository, and the branch you want to deploy from. Azure DevOps is almost identical.

The repository I use is private, but public repos work just as well. The only reason mine is private is that I didn’t see any reason to have all of the underlying cruft of my blog be public. I also deploy out of my ‘main’ branch to simplify things.

Once those items are filled out, one more area opens up that let’s you configure more details about the deployment. You can also pick your SSG so GitHub knows how to build it, because in the end, a workflow/pipeline file will be created and added to the repository. As you can see, several SSGs are supported, as well as other common development frameworks. It was also smart enough to look at the repo and auto-select Jekyll for me.

The app location is where the app will be deployed to and the output location is the name of the folder where the static files reside.

Based on the selections I made, a workflow file is created and committed to my repository. I ended up tweaking mine at some point to make sure committing certain files didn’t generate a new build.

Once the web app was generated, the only change I needed to make was configuring custom domain names.

Final Thoughts

I remember thinking “This was WAY too easy!”

Now that a couple years has passed, I am grateful for how easy it was, and how easy it continues to be. I almost never log into Azure to do anything, instead focusing on the content of my blog and not the infrastructure.

In the next installment, I’ll discuss how I moved my content from WordPress to Jekyll.

Thanks for reading!

---