There’s a few more moving parts to my website than there were when I first made it years ago, so I’ve put this page together to cover all the pieces!
These are all the main parts that I can think of off the top of my head. If you’ve got questions, feel free to contact me!
Writing and publishing content
Almost all content and code sits in a single Github repo.
I use the static site generator Hugo (with my own theme) to build my website. It’s fast, meets my needs for templating/content management, and handles extra features like RSS feeds out of the box.
I like being able to write my posts locally in markdown. Being plain text makes it easy to write and edit, and if I ever need something more complex I can drop in custom HTML with shortcode snippets using Hugo.
As I write and push changes to Github, Buildkite schedules builds to be run. Good thing they have a free tier for community/open source projects!
Serving incoming traffic
I run everything off an aging Raspberry Pi (model 1B, plain Raspbian for now) on my home network. It’s not the fastest arrangement, but it meets my needs and saves me paying for cloud compute/storage/bandwidth.
A Buildkite agent continuously checks for new jobs and rebuilds my site as needed. It performs other scripted work as well, like scheduling delivery of my newsletter.
Web traffic is handled by Nginx. It makes serving static content a breeze, while still giving me a great deal of fliexibility. For example, my RSS feed is aliased to common paths (like
/feed for Wordpress sites) to make it easier to find.
I originally called
nchlswhttkr.com my home, but later moved over to
nicholas.cloud. While “Nicholas Whittaker with no vowels” sounded good in my head, it became problematic when someone else had to type it out.
nicholas.cloud registered with Porkbun. Not all registrars support the
.cloud TLD, but thankfully Porkbun do! I’ve been happy so far with their pricing and customer support.
nchlswhttkr.com registered with Cloudflare (no markup!) for legacy reasons, because I don’t like link rot and it only takes a few rules in Nginx to redirect to my newer domain.
The nameservers for both domains are with Cloudflare, because it’s easier to manage DNS records when my traffic is proxied through their network. The added benefit of caching is nice too, though I get a negligible amount of traffic.
My main reason for using Cloudflare is Cloudflare Workers, which are great when I need little more than what a purely static website offers. Hooray for serverless!
- I can drop in more complex functionality on routes that need it, like the subscribe form for my newsletter.
- I can respond to requests from Cloudflare’s edge if I want something to be fast, rather than waiting on an origin call.
If you’d like to see a few more things that are possible with Cloudflare Workers, I’ve written a couple of blog posts about uses I’ve found for them.