I’ve wanted to write a technical blog for some time — a place to record things I’ve learned and tools I’ve used, both for my own reference and (hopefully) as a friendly and useful resource for others.

I could have gone down the traditional route: choose a blog hosting site (Content Hub, WordPress, Squarespace etc.), sign up, and start writing.

But I’m an engineer — and if there’s one thing I love, it’s an opportunity to flex my engineering muscles.

So I decided to self-host my blog.

Okay, but what does that involve?

As it turns out, quite a bit of research. So, like any good engineer, I broke the project down into smaller steps.

This post gives an overview of the initial design decisions I made. In later posts I’ll go into the nitty-gritty.

Table of Contents

What’s in a Name?#

The first step was choosing a name for my blog.

This was an important first step — the name sets the tone, and I wanted something that reflects the blog’s personality and content.

Initially, I wanted to call the blog The Computer Mash, partly as a nod to my love of whisky (“mashing” is the process of mixing ground barley with hot water to extract fermentable sugars), and partly as a metaphor for the variety of topics I’d be covering.

Later, I switched direction a bit and decided to include an animal in the name.

After a few rounds of brainstorming (The Tech Salamander, The Computer Camel, The Code Cat…), I landed on The Code Chameleon.

I loved the alliteration — it’s catchy and easy to remember. Like The Computer Mash, it suggests variety. But more than that, a chameleon symbolises adaptability — perfect for a blog that I expect to evolve with my skills and interests.

With the name chosen, it was time to secure some digital real estate.

Getting a Domain#

This seemed straightforward — or so I thought.

I headed to a domain registrar to grab thecodechameleon.com… and hit a wall. It was taken, and the owner wanted an ungodly amount of money for it.

So instead, I chose thecodechameleon.io, which may have been a blessing in disguise, since the .io top-level domain has a nice tech-focussed feel to it, and honestly I much prefer it.

Building the Site#

I’m not a web developer, nor have I done really any web development in my spare time.

So I didn’t want to build the site from scratch. I didn’t want to go down the rabbit hole of CSS, HTML, and JavaScript, or get lost in the jungle of frameworks out there.

I wanted something lightweight, simple, and functional — something that just works.

That’s when I came across Hugo, a static site generator written in Go.

Hugo was exactly what I needed: fast builds, no client-side scripting, no fluff, and enough flexibility to support text, images, and embedded videos. It let me focus on writing without reinventing the wheel.

Hosting#

Since I was self-hosting, I wanted something cost-effective. I wasn’t interested in paying a monthly fee for an AWS instance, nor did I want to invest in a full-on server.

Enter: the Raspberry Pi.

I’d been looking for an excuse to get one anyway, and this seemed like the perfect opportunity. But novelty aside, the Pi comes with some important benefits.

  • Versatility: The Pi is a tiny computer, so it can be repurposed for other projects later.

  • Affordability: Raspberry Pis are inexpensive, and accessories are cheap and plentiful too.

  • Low running costs: Power usage is minimal — ideal for a site I want running 24/7 (especially during a cost of living crisis).

  • Community support: It’s a favourite among hobbyists, so there’s no shortage of tutorials, forums, and advice.

In the end, it felt like the obvious choice.

Automation#

I work with CI/CD quite a bit in my day job, so I wanted to apply the same principles to managing my blog.

Here’s the high-level workflow I had in mind:

Write a new post → push to test → check test website → merge to live.

For each push to the blog repo, I wanted the following:

On the test branch

  1. Build the blog site.
  2. Mark it clearly as a test version.
  3. Deploy to a test webserver, accessible on my local network.

This would let me preview changes from any device before pushing to live.

On the live branch

  1. Build the site.
  2. Deploy to the live webserver.

And that’s it! That was my plan.

With a name in place and a domain secured, I was ready to start building…