Azure Static Web Apps vs Github Pages

Table of Contents

I want to start by giving credit where credit is due, it seems a little overcritical to pick fault with a service that is provided completely free of charge! I think both platforms do a fantastic job and whichever you choose I’m sure you won’t be disappointed.

There are however subtle differences in the two offerings, which might mean that one is more suitable for your individual requirements and working practices. I will attempt to summarise these differences for you in case you are unfamiliar with both platforms.

I’m glad I tried both, as I’m now comfortable that if something changes in the future with the offerings available, I can swiftly re-host my site and I’m not locked into a particular platform. Also, it was a great learning opportunity and gave me some good content for the blog!

The Similarities

Aside the obvious, what both vendors offer and is worth calling out is a free SSL certificate, which is generated automatically when you set up your site. If you have ever had to do this manually you will know what a great benefit this is, both in terms of time and effort and potentially also cost.

The differences

For me, there are a couple of key differentiators for me, which are as follows:

1. Azure Static Web App Staging Slot

Having a staging slot is very cool as a built-in feature for basic SKU, it feels like more of an enhanced offering.

The staging slot has also been integrated into the Microsoft published GitHub action for Azure static web apps, the way it works is when you submit an update via a branch other than main, (which is after all, a good working practice), when you create a pull request to merge to main, it will spin up a stage site on a temporary URL, you can then test this externally on multiple devices and browsers etc. When you are happy, you can commit the branch to ‘main’ which triggers the action again, the test URL is removed, and the latest code promoted to production and the staging slot cleared for next time.

This is quite neat to watch in GitHub, as the temporary URL is returned as a message on the pr when the action completes:

Note: don’t do what I did when trying to grab the screenshot for this post and only have new content that was marked as draft! This won’t show on the stage site, which is essentially a preview of the proposed new production site.

2. GitHub pages require the repo associated with your site hosting to be public

This difference doesn’t really need much explanation but may or may not be a deal breaker for you, depending on how you feel about your compiled site being available for someone to download in its entirety.

This restriction is removed if you have a GitHub Enterprise licence.

In Conclusion

If you’ve never used Azure and have no particular interest in signing up for a subscription, then GitHub pages might be a simpler solution.

If you already use Azure and have a subscription available, as I did, this might push you towards Azure static web apps.

I like to reduce the number of moving parts and multi-vendor dependencies, and since both solutions hinge upon GitHub repos and GitHub actions, GitHub pages would seem like a better choice for most people.

Since I’m already using Azure, and use Azure DNS for my domain, I already have a dependency on Azure, so may stick with Azure static web apps for now. Ultimately, what would influence my decision to move in the future will be the on-going reliability of the hosting platform.

Personally, while the Azure Static Web App staging slot is a cool feature, I must be honest and say I don’t generally use it, preferring to run my site up in development mode locally to preview my new content, then when I’m happy just push it on the main branch (there I said it! - I know, so not DevOps best practice! but this is my personal blog, not a mission critical line-of-business application). If I were going for a new theme or major overhaul of the site it’s a nice to have, but certainly not a necessity.

So really, if you can live with the differences that I’ve called out the decision is largely based on personal preference. Sorry my conclusion isn’t more controversial, but there it is!