Running your personal website on Azure Static Web Apps with Hugo


for the last 10 years, I have been writing on and of about my experiences on a personal site (like this one) and in that time, I have moved from platform to platform in search of the one that really fitted my needs. I must admit, the research involved and the work to getting it all up and running has been most of the fun (again and again!)...

To give an idea, my site has seen the following platforms/solutions:

  1. Hosted WordPress (the .org one)
  2. Self hosted WordPress
  3. Umbraco
  4. Ghost
  5. Ghost (in a container)(in Azure Kubernetes Service, just for the fun of it really...)
  6. A few weeks in Jekyll (static site generator)
  7. And now in Hugo, hosted on the new service azure static web apps

As you can see for yourself, I have had my share of migrations where I tried to preserve my data over and over again. It was only in the period of 2014-2016 that I didn't really write (at all) and that I had even forgotten about my site. And of course, it was at that moment that the lightning (must have) struck...

My site was hosted in Azure and I used a (free) MySQL database service to power the data backing. Unfortunately, Microsoft decided at some point to decommission the service and I must have missed al the mails reminding me to do the work in order to migrate my data away from this MySQL instance and when the day came, all the data was gone and my site went down. It took me quite while to realize the consequences but the reality was that I lost quite some content. When I noticed, I didn't have the energy to start all over and it took me quite some time to get started again (from a white canvas)

That moment came in 2017/8 when I discovered Ghost . I was looking for a CMS where I could write my blog posts in Markdown as it seemed that all the cool kids were using it. I loved the simplicity of the platform and was sold immediately.

For the hosting, I decided to work with Azure Kubernetes Service (AKS) which was rather new at the time. I started playing with it with the purpose of learning and ended up running my personal site on it. (I knew very well that it was overkill, but pushed through anyway). The setup became quite complex rather fast and when I got it finally working, I just had to push through and put the site online. The design was similar compared to a basic AKS design that is shown below:

AKS basic setup

Having this new setup I started writing again, although on a very slow pace. Ideas would come a lot, but the actual sitting down and investing the time towards completion, always seemed to be a problem. I have a very busy life with quite some time in travel back and forth to work and could not muster the energy. Today, I have been reorganizing a bit and it is my intention (again) to share back what I learn.

So here we are, after yet another migration to yet another platform/site/solution. The difference is now that I decided to take another approach and to make sure that my data would be safe, that it would be easy to create new content and most of all, that it would be cheap! 😄

In the past I have always worked with Database powered CMS 'es that allowed me to login and to write my content in the context of that application. The idea is that I was able to work from any device, without needing to install software on my own machine. The beauty of this approach is that it is easy to use. The downside is that you have to work with a hosting solution that is in fact an machine that needs CPU, memory and other resources so that the CMS can do its work. This allows this solution to create content, but also to serve that content to the interested reader. The act of serving the content to the reader the way that you want (the rendering), this is something that also falls under the responsability of the CMS. When working on a regularly visited site, it might make sense as those allocated resources will be ready to be used all the time. But when you have a site that isn't visited regularly (as this site most likely is), then those allocated resources are, in fact, wasted and that is a shame. It is not only a waste of resources and thus money, it goes a lot further than this...

A statically generated website takes a different approach on this: It starts form the idea that the content that needs to be served to the visitors, has been generated up-front. To do this, we use a static site generator. (Examples are: Jekyll , Hugo , Nanoc ,etc. ). Those "generators" take your content, which is typically written in Markdown and convert it to a complete website, with html, css, scripts, images, etc. The beauty of this way of working is that the output is very light and that it can run (almost) anywhere! The big difference with CMS'es is there is no abundance of resources needed. And this is super interesting if you are concious about your bill at the end of the month and to go even further it makes you greener as you (typically) consume less resources.

So, after this (very long) Introduction, you now understand why I moved to a static site generator. Initially, I chose for Jekyll as it is used by GitHub pages and as it has a long history. I had to reevaluate this decision though as I wanted to host my (new) site on a new (still in preview) Microsoft Azure Service called "Azure Static Apps ". In that service, your site will be deployed as a set of files based on a GitHub repo and the build process will be done based on GitHub actions. This can be seen in the image below:

Azure Static Web App - workflow

The issue that I had with Jekyll in this context, was that the integration was not out of the box and that it was a custom integration. When creating a new Azure static web app, it asks you which kind of Static site generator/framework/platform that you use, but Jekyll wasn't in the list ((2) in the image below) at the time of writing. The consequence is a custom build in GitHub Actions that takes almost 7 minutes (in my case) to build and even though te result is the same, I again want to refer to my point of "your personal resource consumption" and "footprint". So in that context, I decided to switch over to Hugo, which already has the required integration in azure static web apps ((1) in the image below) and a very fast build and deployment process.

setting up deployment

Additionally, the Hugo community really is spoiled with the amount of templates that can be used out of the box.They can be found here . (There is also a list in GitHub if you are interested) To give an example, I currently use the template hugo-clarity , which is created by Chip Zoller and based on the VMWare Clarity framework.

I'm pretty happy with this setup as it gives me the freedom to work in Visual studio code, which is IDE that I know and love and that allows me then to push my changes to my repo and consequently push a new version of my site! It also saves me quite some money and that is always a good driver to change something! Now that I have learned about this way of working, I'm sure that I'm going to be using this for a long time.

Finally, something about the tooling: on top of visual studio code, I also work with the Front Matter Plugin which is created by Elio Struyf . It allows you/me to work with page templates/categories/tags and all sorts of cool stuff! Thx Elio!

Well, this took longer than expected. I hope that you get something out of this and if you have questions, please let me know! (Twitter is a good place to give an example). I have a follow up post planned and if all goes well, this one should be published pretty soon!



Posts in this Series

comments powered by Disqus