DEV Community

Mark Saward
Mark Saward

Posted on • Originally published at manse.cloud

Hosting my new blog with Hugo

In the last few days I've decided it's time to start my own blog, so here we are! This blog is intended to contain a mix of topics such as programming/technology, philosophy, and other random thoughts, with an emphasis in that order (primarily technology). In making this decision, I found myself asking the question, "Do I really want to use Wordpress?". For my work, I run a small but growing software development company, where we focus mostly on integrating systems and creating internal tools (usually in the form of web-apps). I have a good understanding of the lifecycle of not just running CMS's like Wordpress, but also how to create them. And so the question is: do I go for the simple solution of setting up WordPress, or do I give in to temptation and minimise my chances of success by over-engineer a solution for this brand new project?

In the end, I've decided on a compromise: a static site generator. I won't be taking the easy path of using WordPress, but I also won't be doing something enormously difficult. A static site generator lets you create your content and then build the raw html files based on templates and content you provide it. If you then edit a page, or add new content, you rebuild the site and upload a new version. There's no fancy JavaScript behind the scenes (though you could add that if you wanted), just the plain old html files.

There's a few reasons why a static site generator appeals to me over a full CMS platform like WordPress:

  • Fast! Since we're just serving raw html files, once the site is deployed there's no processing for the server to do beyond reading the file off the filesystem and sending it back to the client. Furthermore, if we keep our templates clean, these files can be very small. With some generators, no JavaScript is required for rendering the site. Unlike a React site, we aren't providing the equivalent of an application for download, just the final rendered HTML. Furthermore, given that the content is all static, such sites are very friendly for hiding behind a CDN like Cloudflare, and can be served very fast around the world with ease.
  • Ease of deploy. To run this system, all we need is a server capable of serving up static files. That means I could throw this site onto a Raspberry Pi behind a Caddy server instance (caddy), throw them into a Google Cloud Bucket, or any other simple hosting mechanism I like. There's no database required. A static site opens up hosting opportunities unavailable to sites like WordPress.
  • Low system resources. I plan to run this on my own Raspberry Pi 4, a relatively beastly machine. With plain HTML files, no server side rendering, this thing is super easy to host on a low cost machine like the RPi.
  • Security. Since there are no moving parts, your security risks are much more limited to things like the server you're running it on, and the service that serves the files (Caddy, Apache, etc). It significantly reduces the surface area for possible attacks.
  • Control. There's a great simplicity to running a site like this, and with that simplicity comes control. While I can modify the internals of WordPress, there's a great deal to learn to do so in a competent way in line with the way WordPress has been designed. With straight HTML templates, it's much simpler for me to make changes and understand the consequences. Of course, with WordPress comes the significant advantage that there are a ton of plugins pre-made to do what you want, so I don't want to oversell the case here -- but there is an appeal to the control that comes from simplicity.
  • Markdown. Out of the box, many static site generators let me write content in a simple way using Markdown, which I'm keen on.

There's no question that a static site generator involves more fiddling than paying a nominal hosting fee, choosing a template, and starting your blogging WordPress. However, the reasons above on balance have weighed in favour of me going the static file path.

And for that task, I'll be beginning this journey with Hugo. I did look into fancier JavaScript generators like Gatsby, but as someone who is not a fan of JavaScript (and excited about the prospects of WebAssembly enabling challenges to its hegemony), and being keen to retain control and simplicity, it's my preference to go with something like Hugo. Also, while I'm not a boomer myself, I'm old enough to have started learning about web technology when PHP was young, and so this boomer's sentiments resonated with me (and while I note he has since managed to win his fight with Gatsby, as someone who uses React I lack the same motivation to use something like Gatsby for the purposes of improving my JS/React skills).

Next steps

With the site up and running, some things I'll be looking at next include:

  • Personalise the layout and details (word counts, name, image(s), social media accounts, etc)
  • Supporting RSS feeds (which I still use!)
  • Cloudflare for caching, particularly of images
  • Something for monitoring that avoids Google Analytics, perhaps GoAccess
  • Possibly my own dummy JS file so that even if a file is cached by CDN, there's still a hit to my server that I can log
  • Newsletter or similar signup option
  • Commenting system that respects privacy (no tracking)
  • Tags/categories

Top comments (7)

Collapse
 
sidpalas profile image
sidpalas • Edited

Nice post! Do you have a static IP to use with your Raspberry PI or do you plan to use DDNS?

I use Hugo + Caddy hosted on GCP for this site (devopsdirective.com/posts/2020/02/...) on a free f1-micro vm and it has been great so far!

Collapse
 
mark_saward profile image
Mark Saward

Hi, thanks for the positive feedback on my inaugural post :) Although I don't officially have a static IP, practically I have one, as I can't recall the last time that my ISP changed it on me. I'm using pingdom to alert me whenever my sites go down, so I've added my blog there and can update DNS when that next happens.

free f1-micro does sound like a good idea!

Collapse
 
sidpalas profile image
sidpalas • Edited

I use uptimerobot.com/ for my monitoring (Pingdom is nicer but I didn't see a completely free tier...). DDNS isn't too hard to configure if you wanted to automate the process of updating your DNS record if your home IP were to ever change.

I published a workshop on setting up the Hugo site on GCP with Caddy to my YouTube channel if you are interested: youtube.com/watch?v=xo_4n2Reh58

I also made the setup code available here: github.com/sidpalas/hugo-gcp-deploy

Thread Thread
 
mark_saward profile image
Mark Saward

I didn't know about uptimerobot, that's a good tip, thanks. I saw in your post you linked that you're using Docker. I've just posted how I'm using docker, you may be interested in the Caddy 1 http.git directive: dev.to/mark_saward/easy-updates-fo....

Collapse
 
phlash profile image
Phil Ashby

I have been on a similar journey, choosing to host my static content directly in Azure cloud storage / CDN to get away from my Wordpress/Moinmoin/other CMS hosted on a relatively expensive VM. So far so good! The VM is still there ATM as there are a number of other folks sites to staticify, and I'm hosting a video server for family with Jitsi while in lockdown!

Thread Thread
 
sidpalas profile image
sidpalas

Are you porting the sites to something like Hugo/Gatsby or generating the static sites directly from the CMS (w/ a plugin or similar)?

Thread Thread
 
phlash profile image
Phil Ashby

So far I've ported content from MoinMoin to Hugo with a little help from a markdown converter intended for Wordpress. The Wordpress sites I'll probably try a similar route.

I'm using NetlifyCMS as a client-side page editor with github for versioned storage and webhooks back to my personal server to redeploy changes to Azure. NetlifyCMS is good enough to replace Wordpress for CMS duties for al the sites I host I think...