tldr; This is a static website, managed using CI/CD, and running on serverless infrastructure. This is my journey of how I got there but not a how-to.
Background Link to heading
I’ve had some form of personal website since the mid-nineties. There have been gaps, sometimes ranging in years, but there’s been some presence more than there hasn’t.
For the past number of years the website was hosted on a paid plan with about.me. A returning urge to write (blog) meant changes needed to be made because that service is beautifully narrow in its offering - one single page, done well.
Having experienced Wordpress and similar platforms I knew what I didn’t want - clunky web UX and editors that often stretch the definition of WYSIWYG to breaking point. The least friction between writing and publishing is what I was searching for. And I found it in an unusual place. Meet Hugo,
Hugo Link to heading
Hugo is a static website framework and generator. Static websites are pure html/css and maybe javascript. They don’t directly support anything that requires server-side processing like web forms however those elements can be embedded from remote sites. Nor do they require a database. This makes them very fast at serving websites of any size.
Hugo doesn’t have a web management interface and is not installed on a web server. It’s installed on the computer you plan to develop the website on where it provides the file structure you create your content in. It supports themes, this site uses the Coder theme. The themes are just html and css and Hugo provides a mechanism to override them. If you’re handy with web design you can also create your own theme or port one from your existing website.
Hugo supports writing content in several markup languages including html and markdown, which I use.
When you’re ready to publish to the internet you compile the site and upload it to your web server. Every time you make any change to the site you need to recompile and upload the site files again.
Compiling? for as website? I’m probably not selling Hugo here but wait, there’s more.
Continuous Integration and Deployment Link to heading
Hugo is build for an automated CI/CD pipeline. Though possible you’re not really meant to be messing around with FTP or uploading files manually. To take advantage of this you have two options.
The first is Hugo’s native support for multiple cloud hosting providers. In this scenario you can deploy straight from same computer that Hugo lives on. The second and the one I chose was to store the site in a GitHub repository then use GitHub Actions to compile and deploy the site every time a commit is detected.
Can you see the beauty of Hugo now? You write in your favourite editor then a few commands later it’s published on the web.
I should say here that when you are designing a site Hugo has a built-in local web server so you can easily check how it will render without publishing on the internet. The CI/CD pipeline comes after the site is built. For example, since I use markdown to write the blog posts here so I don’t need to check what that will render like. Maybe if I was including graphs (which Hugo supports) or images I would check locally first.
Hugo met my use case perfectly. But in my exuberance I went one step further. I got rid of the web server too.
Going serverless Link to heading
Only needing to serve a static website means you don’t need complex web server software like Apache running on a dedicated or shared server. You can use pure cloud compute for edge and storage to serve the site in a more resilient and cost-effective arrangement.
I chose Amazon’s AWS because that’s the cloud compute provider I’m the most familiar with. But there are lots of other providers out there that can do this, for example, Google Cloud, Cloudflare, or Netlify.
This site is mainly Cloudfront and S3. A Cloudfront distribution acts as the CDN and SSL terminator, the web site files are stored in an S3 bucket. IAM handles the least-privilege model for account access from Github where the site source lives. AWS also handles the certificate renewal.
My Github Action is triggered on a commit and recompiles the site, uploads it the S3 bucket, and invalidates the CDN cache so latest version of the site is instantly served.
Benefits Link to heading
Meets my use case For me it’s being able to write or continue a post in Obsidian anywhere I sync it, push the post to the website’s repo in seconds, and know it will be live maybe ninety seconds later. That’s the frictionless experience I was looking for.
Security I wasn’t coming from Wordpress or something similar with a large attack surface so I didn’t really benefit here. But there are considerable security benefits to static websites, particularly if you also take away the dedicated web server and operating system.
Speed The new site renders faster than the last provider, who was no slouch with load time. The advantage of static websites is that you could add thousands of pages and the load time would stay the same since there are no backend database queries etc.
Cost There was a considerable proportional cost saving considering that About.me were only charging $70 a year and the current setup is less than $1/month, but that wasn’t my motivation. Now, when I move the book’s website over I will save real money because I’m currently paying for managed Wordpress, site backups, and still (in 2026) getting shaken down to pay for SSL certs.
Conclusion Link to heading
If this post resonated with you and you only need a static site then it’s a no-brainer. You’re probably already reading the Hugo docs. And Hugo is just one of many such tools, Jekyll is another popular one.
There is a learning curve here. How steep depends on you. While Hugo itself isn’t too hard to master, I may have made the CI/CD part look easy because working with GitHub and AWS are within my comfort zone. But you don’t even have to go down the cloud compute route, hosting it on GitHub Pages is likely a lot simpler to setup for mostly the same benefits.
It’s fun to learn new things.
This blog does not currently support comments. Please email me if you would like to discuss this post or just connect. If I get too many emails I may revisit the comments decision.