Over the past few days, I’ve moved tech stack entirely for deliciousreverie.co.uk, from reseller hosting using PHP to cloud hosting on AWS by Netlify, and using continuous deployment. This post details some of the hazards and benefits I encountered.
Since I created this blog, I’ve always been a very proud user of Perch CMS and have recently upgraded to Perch 3, which brought loads of enhancements as well as an improved interface. So why the switch?
The truth of it is that I’ve been paying for reseller hosting with my previous provider, UK Web Solutions Direct, for 7 years. They’ve always been quick to respond to my support questions, and I’d highly recommend them.
However, since I gave up my freelance work, it came to the point where I only had this website hosted on it, which seemed a bit of a waste. I also wanted to try out Netlify’s continuous deployment service as an alternative to FTP.
Building a Hugo Site
I felt that Hugo was fairly easy to get a grasp of. Once you get around how strange Go templates look initially, I grabbed the theme called
base from the Hugo theme repo and began rolling my own.
I’ve since found that Base theme isn’t maintained and doesn’t contain some of the new shiny that’s present in Hugo 0.20. Just a caution if you were thinking of doing the same. Sadly, there isn’t yet another theme that can replace it to give you a quick leg-up without any CSS already present in the theme.
The hardest thing I found when using Hugo was … how to build my site. Hah, yes it’s hilarous, but having used commands like
hugo server and
hugo new site and
hugo new theme it totally passed me by that to actually build my static site, all I needed to do was run
There you are. Laugh all you want. I’m maybe being a little bit dense, but I think it’s counterintuitive. Why not
hugo build or something?
So, I had my theme and set up a Netlify repo. Next was deployment.
Deploying to Netlify
Netlify’s interface makes deployment pretty painless. Once I authorised GitHub on my account, it slurped the code, installed dependencies, ran the
hugo build process … and failed miserably.
It failed because currently, by default, Netlify seems to default to an older version of Hugo (v0.16 or something) which meant I was getting build failures.
I eventually found out that you need to add a
netlify.toml file in the root directory to specify the Hugo version you need:
[context.production.environment] HUGO_VERSION = "0.20"
That seemed to work! I switched my DNS over to Cloudflare and the site went live!
Using Pygments on Netlify
One thing I noticed post-launch was a that a Python dependency I had started to use wasn’t working on Netlify. My code blocks would render as plain text, making them unfathomable and messy.
I came across this post - entitled Hugo on Netlify - which helped me to see I could add that dependency to Netlify’s build process by adding another config file,
requirements.txt to the root, and adding
Pygments==2.1.1 as the content.
So I ran
I initially had trouble setting up by DNS with Cloudflare and applying Netlify’s HTTPs certificate. It turns out, after having talked to Netlify, that they don’t have IPv6 yet. Cloudflare adds an AAAA record to your DNS which messes up the HTTPS somehow.
Once I’d disabled Cloudflare’s CDN, I reapplied the certificate and everything worked fine, and I was able to secure my content.
Ahh, static sites aren’t so static after all, are they?
As the web becomes more bloated, I really believe static site generators are going to be the way to get ahead. Once you add the previously mentioned services, they can adequately compete with some of the lumbering, huge CMSes out there (of which Perch isn’t one, I hasten to add).
Continuous delivery can a bit cumbersome to manage for some projects in my view. I say this because my build and production environments were different and that caused me a few issues. I’m on the free Netlify plan, which means I get a lot less in terms of build previews. Looking through their documentation, it seems there’s a lot more available on their paid tiers.
That being said, it’s certainly a lot more safe than the somewhat shakier transfers of FTP/SFTP. One of the benefits became real to me when a friend of mine submitted a pull request, but I was able to see before I merged the code that the change would’ve broken my site, resulting in down time. That was a really useful feature. Now I know I can change my theme, and even if it succeeds locally, if it fails on production you won’t break your site, which I know I’ve done a few times.
This article was edited to remove the references to custom headers, which aren’t yet available on Netlify yet.