Moving my website from WordPress to Hugo

Original context

I originally set up a portfolio website back in 2016. At the time I was still chasing for Linux Sysadmin and as part of my studies/preparation I had been setting up LAMP/LEMP stacks, on bare metal, in VM’s, even on AWS (probably with LightSail, I can’t remember). I had some familiarity with Wordpress as a result and didn’t really look beyond it for a website solution. I wanted my own domain (so I didn’t look at WordPress.com) and I wasn’t specifically targeting cloud, so I asked around and went with an old school web hosting provider. It was actually quite a lot of work setting up the site once I got beyond the initial defaults but I liked the result well enough and I didn’t need to redo anything very often so it didn’t matter so much. As you can see by the posting dates, I don’t post that often but certainly there was always maintenance to do…

Pain Points with WordPress

Roll forward 4 or 5 years. Life and career have changed significantly. I am not a web dev, I am a cloud/platform engineer and a fan of infrastructure as code. This WordPress solution is really starting to grate:

Beyond the above I have got the point of embarrassment. What sort of calling card is a website running on Wordpress with a clickops virtual hosting company for a platform engineer?

Moving to AWS

Earlier this year I did a take-home challenge that involved ‘setting up a modern single-page example website on AWS’. I used a public terraform module, some of my own code and some handcrafted HTML to deploy a static website on S3/CloudFront. When I next had time, I thought, I would fix up the code and get ready to deploy with Hugo. I even found a tool to extract my pages from Wordpress to Hugo MarkDown- a lot more easily than Wordpress’ own backup feature. Of course this was at the time that Hashicorp decided to break up the aws_s3_bucket resource and the module I was using was too brittle to just ‘upgrade’. I also wanted to get the www subdomain aliased to the apex and have TLS certification integrated. Anyway, got all of that fixed to a single up-to-date terraform plan on a secondary domain. Still serving a single handcrafted HTML file with an image… Still, should be great for Hugo.

Enter Hugo

Well actually I had come across Hugo years ago for an internal website at DAZN and was impressed with it but it was one thing amongst many at the time and I wasn’t much involved in setting it up. I’d just done a few posts and then moved on to another employer. The attractions were/are the static website generation and (to a much lesser extent) that it’s written in Go. The negatives were that I simply didn’t really have the time to look into it.

I now have the Hugo site up and running with some kind assistance from Reddit friends to incorporate the theme customisations I wanted. The advantages are essentially all the opposites of what I didn’t like about WordPress:

Additionally it’s a good calling card for what I do in the day job.

Is This For Everyone?

Would this solution be for everyone? No. I can’t see this implementation selling to a naive user who ‘just wants a website’. Plenty enough businesses have weak websites that they don’t update the content for, or even no dedicated website, and wind up using Facebook instead. Wordpress of course have a first-party hosted offering. There are plenty of other website platforms and as I said earlier, I am not a web dev. I hadn’t come across ‘Jamstack’ before setting up Hugo here. It seems like a web-specific expression of good architectural domain boundaries but it’s perfectly adequate here. I initially thought that the Hugo part of this implementation would IMO be straightforward enough for someone who would consider a third-party hosted Wordpress solution but trying to move beyond the raw theme to integrate e.g. site search and custom icons certainly requires a great deal more understanding of templating and CSS than WordPress! It’s hard to argue with free and Hugo on GitHub pages would be adequate. There are other static hosting solutions recommended by the Hugo project also.

Hugo on AWS/S3/ACM solution is good for me because I:

Hugo would also be a good base for an internal/documentation/blog website in a technical org, just as when I first encountered it. The build and deploy model is an excellent match for organisations with automated code approval and deployment, e.g. CI/CD.

Subsequent Iteration (I)

Since I wanted something that people could look at I decided to move the heavy lifting for the infra into a terraform module that I could publish on the community module registry. Although I am including an example, of course the ‘proof’ for this would be to deploy my own website using it - which I have now done. Of course this would be exactly as AWS introduced Origin Access Control and deprecated Origin Access Identity, and at the time of writing this feature is not yet available in Terraform, although there is already a pull request to add this functionality. Expect an update to this module soon!

Subsequent Iteration (II, 2nd September 2022)

Early this morning (UK time) Hashicorp released version 4.29.0 of the Terraform AWS provider, including support for Cloudfront Origin Access Control. I’m very pleased to say that the latest version of my public terraform module now incorporates this and that this website is deployed using it