Mar 14
Hugo: Two years with a flat-file serverless website.
In May 2021, I was fed up with my website. It was nothing more than a business card with contact information, and it cost me $20 a month to host it.
Worse yet, I had to keep the EC2 container up to date, which required an install and upgrade script that almost always failed. The only thing I had gotten working well was the SSL renew script, and this was now failing due to version changes in the software I was using.
I needed something new — and simpler — so I went with Hugo, a flat-file framework for building websites. The technology stack was YAML, Markdown, and a simple template language on top of HTML/CSS/Javascript built into a Go application. Very simple.
Hosting it could be done with any cloud provider, so I went with AWS because that’s what I knew. GCP and Azure seem to be just as simple. I wrote an article about it back then if you want to see how it was set up.
The immediate effect of this change was a 99.75% drop in hosting costs. Almost two years later, I can confidently say that it was a 100% drop in cost because I have received no bills from Amazon since the change.
I’ve been thinking about why for a while. It could be that it would cost them more to bill me than just to let it go. It could also be that I’ve been wrapped up in some cost program I’m unaware of. Sometimes AWS doesn’t charge you if you have very little traffic, and the site only gets about 20,000 hits monthly.
Regardless of what caused it, the outcome is the same. No hosting cost for almost two years now.
The current status is that AWS costs sit around one American cent per month, and they don’t bill me that one cent.
I was very focused on performance, features, and SEO when building the website. I wanted the site to have more of my CV information and include a blog. I moved the blog here this year, but I still crosspost with canonical URLs.
Working with the templates is easy, especially since Hugo supports overriding templates and files. I still keep the Toha theme around, but I made a lot of modifications to make it work for me and include SEO options such as canonical URLs and image captions. This has been done by simply overriding template files from the theme.
The theme is stored in a themes folder and is a git submodule — a little-known and used feature of git. I don’t recommend anyone use it without expert knowledge of how Git works. Using a package management system is much preferable in this day and age, and I will probably convert to this method myself at some point.
Performance is always an issue, but from the beginning, my website performed like a champ. 40ms to first data (even when testing over VPN from Asia), and the theme had acceptable metrics on pagespeed and google search console.
Regardless I spent a few hours fixing SEO, image, and CSS issues and making the theme a little more my own. All told, I probably spent an initial eight hours working on technical issues. The content took longer, but one workday of technical work to get it into a great state and ready to deploy is very short.
The biggest surprise has been how little time I’ve spent on technical issues once the site was up and running. Less than one hour to date. This includes upgrading the NodeJS version on my redirect function — which runs from AWS Lambda—updating CSS and JS versions and updating Hugo and Toha versions.
The biggest realization I’ve had from working with Hugo and flat-file frameworks is there are little to no attack vectors. All editing work is done locally and can’t be done through the hosted content. In a world where cybersecurity is becoming a priority, thinking about how your website can be attacked should be at the top of your to-do list. With flat-file, it can be very hard to spot any vulnerabilities, but here are a few things to consider:
- Secure your Github and AWS accounts with two-factor authentication.
- Ensure your S3 bucket is secure, and clear out all files before deploying an update to the site.
- Keep javascript libraries up to date. This includes any Lambda functions.
- Update your flat-file application — Hugo, in my case.
I really can’t think of anything else. DDOS protection is enabled with standard AWS Shield for Cloudfront, and since I have no forms, logins, or otherwise on my website, everything else is irrelevant.
Flat-file frameworks can replace 90% of all websites I’ve ever worked on. Most of the features these websites need — such as newsletter signup or e-commerce — can be replaced by a third-party integration, which can be done using pure javascript. So if you haven’t tried out flat-file frameworks yet, I encourage you to do so.
Have you tried a flat-file framework? Let me know what you think in the comments.
