Kev QuirkModify

2025-11-21 18:11:00

I've been working on adding support for comments over the last few months. On a static site, that's hard, but it's finally done.

A few months ago Maurice Renck and I were having a conversation on the Fedi (I think) and he mentioned that he would prefer to leave a comment than send me an email. Since then I’ve also seen a few other people talk about how they like to see a comments section on blogs. So while I’ve been pissing about with Jekyll recently, I decided to build a commenting system for this site.

Why not use something that already exists?

That’s a fantastic question, dear reader, and the answer is that all the solutions I’ve found are either too expensive, not privacy focused, or don’t appear to be getting regular updates.

<RANT>
Why are commenting systems so bloody expensive? Like, they’re pretty simple, so why on earth does it cost more than the VPS that hosts the entire site to have what basically equates to an embedded form and a teeny-weeny DB that stores maybe a few hundred KB of plaintext?

Especially when a very small percentage of people are likely to bother leaving a comment.
</RANT>

Annnnyyyyywwwwwwaaaaaayyyyyy…….

For the last month or so, I’ve been working away on creating my own commenting system that has the features that I’d want to see, which are:

1. Independent of the site they work with so they can be easily removed if I want to (embedded by loading a JS script).
2. Be privacy focussed - no tracking or requirements to login/create an account.
3. Send email notifications via Amazon SES when someone submits a new comment, or when someone replies to your comment (if you provided an email).
4. Have a simple admin UI where I can approve/delete comments before they’re published, and reply.

My little commenting system is now live available at the bottom of this and every other post on this site. I’m fully expecting there to be the odd bug - if you find any, please do let me know.

Here’s a peek at what the admin UI looks like when someone comments (right-click > open in new tab to enlarge):

What’s next?

I’m thinking about releasing the source code for this so other folk can have a commenting system on their own site.

I’m also considering developing this to a point where I can offer it as a hosted solution for others to use, but I’m not sure I want that in my life. If I do, it won’t be expensive.

In the meantime, if you want to leave a comment, the form is below.

2025-11-20 19:41:00

I enjoyed this post as it approaches the problem I wrote about yesterday from a completely different perspective. While I spoke about rolling my own infrastructure and building locally to maintain control, Loren talks about the simplicity and cost (free!) of hosting with services like Netlify.

Loren closes his post by saying:

If you’re running a complex site or you’re philosophically opposed to big platforms, a VPS + rsync pipeline might be worth it. […] For my tiny, low-traffic static site, the convenience, zero cost, and redirect handling of GitHub + Netlify are hard to beat.

I think this is the crux of the whole discussion. For me, it’s more about control than being opposed to big platform. I think they have their place, but for my use case, my personal blog isn’t it. For Loren, it’s all about simplicity and just getting shit done.

It’s fantastic that we have different options that allow for more control, or for ease of use. As a result, we have a diverse pool of people and opinions on the Indie Web, and I don’t think anyone can argue against that being a good thing.

2025-11-19 17:57:00

A look at why small, personal websites don’t need big-tech static hosting, and how a simple local build and rsync workflow gives you faster deploys, more control, and far fewer dependencies.

OK, so Cloudflare shit the bed yesterday and the Internet went into meltdown. A config file grew too big and half the bloody web fell over.

How fragile.

It got me thinking about my fellow small-web compatriots, their SSG workflows, and why on earth so many rely on services like Cloudflare Pages and Netlify. For personal sites it feels incredibly wasteful: you’re spinning up a VM, building your site, pushing the result to their platform, then tearing the VM down again.

Why not just build the site on your local machine? You’re not beholden to anyone, and you can host your site anywhere you like.

• ✅ No CI/CD pipeline.
• ✅ No big tech — just you and your server.
• ✅ No VMs spinning up and down at the speed of a thousand gazelles.

How to build and deploy automatically

All you need is a hosting package that supports SSH (or FTP if you must) and a small script to build your site and rsync any changes. Here’s the core of my deployment script:

#!/bin/bash
set -e

LOCAL_DIR="/path/to/your/site/source"
REMOTE="[email protected]"
REMOTE_DIR="/path/to/your/website/files/yoursite.com/public_html"

cd "$LOCAL_DIR" || exit 1

# --- Build Jekyll site ---
echo "🏗️  Building Jekyll site..."
bundle exec jekyll build --quiet
echo "✅ Build complete"

# --- Sync _site to remote server ---
echo "🚀 Deploying to server..."
rsync -az --checksum --delete --omit-dir-times --quiet \
  "$LOCAL_DIR/_site/" \
  "$REMOTE:$REMOTE_DIR/"

# --- Fin ---
echo "✅ Deployment complete"

Here’s what it does:

1. Jumps into the directory where my source website files live.
2. Builds the Jekyll site locally.
3. Syncs the built files to my server over SSH, deleting anything I’ve removed locally.

That’s it. And that’s all it needs to do. With these few lines of Bash, I can deploy anywhere, without waiting for someone else’s infrastructure to spin up a build container.

My full script also checks the git status, commits changes, and clears the Bunny CDN cache, but none of that’s required. The snippet above does everything Cloudflare Pages and similar services do — and does it much quicker. My entire deploy, including the extras, takes about eight seconds.

Final thoughts

If you’re hosting with one of the big static hosting platforms, why not consider moving away and actually owning your little corner of the web? They’re great for complex projects, but unnecessary for most personal sites.

Then, the next time big tech has a brain fart, your patch of the web will probably sail right through it.

2025-11-16 00:22:00

I read this post this morning while I was perusing my RSS feeds with a coffee. Firstly, I’m not sharing this because Andre called out my blog (although being bundled with people like Rach and Manu is extremely flattering). I’m sharing it because I agree with everything he says in the post.

Having a place on the web that I’m 100% in control of, where I can share my own thoughts, feelings, and opinions is very powerful for me. Over time this blog has evolved from me sharing technical posts most of the time, to a legit personal blog with a technical twist.

Despite what sites like ProBlogger say, I don’t have a niche, and I don’t try to grow my audience (I don’t even know how big my audience is). I just write whatever is on my mind at any given time, and people usually get in touch with me to discuss the topic. It’s fantastic.

If you’re on the fence about starting a blog, I implore you to do so. It’s probably the best thing I’ve ever done with a computer. If you, please drop me an email with the link - I love discovering new blogs!

2025-11-14 20:55:00

I've managed to get my Jekyll based site working behind Bunny CDN, while maintaining my .htaccess redirects. Here's how I did it...

Since switching back to Jekyll recently, I’ve been running this site on a Ionos-hosted VPS, then using a little deploy script to build the site and rsync it up.

This all worked fine, but I really wanted to use Bunny CDN for more than just hosting a few images and my custom font. Being a static site, I could have dumped everything onto their storage platform, but I have a metric tonne of redirects in a .htaccess file from various platform migrations over the years.

Bunny’s Edge Platform could have handled these, but with the number of redirects I have, it would have been a slog to maintain. So I assumed I’d never be able to put Bunny in front of my Jekyll site easily and went about my business.

💡 Then I had an epiphany.

What if I created a Bunny pull zone that uses kevquirk.com as the public domain, then set up a separate domain on my VPS, host the site there, and use that as the pull zone origin?

My theory was that Bunny would still be requesting content from the VPS, so my .htaccess redirects might still work.

…turns out, they did.

Some small bugs

I duplicated my live site so I could experiment safely. The setup looked like this:

• test.kevquirk.com - the domain configured in the Bunny pull zone
• src.qrk.one - the origin domain on my VPS, where the site actually lives

The first thing I had to do was update the url field in my Jekyll _config.yml from kevquirk.com to test.kevquirk.com, rebuild the site, and upload it to src.qrk.one.

Now, you might be thinking, “Kev, why build the site with the wrong domain?”

But I haven’t. By building the site with the test domain, all links point to test.kevquirk.com/.... If I built it with the origin domain, all internal links would lead to the wrong place. They would still work, but the site would be served from src.qrk.one, which is not what I want.

Next up was redirect testing. I visited /feed, which should hit .htaccess and redirect to /feed.xml. The redirect worked fine, but the resulting URL was being served from the origin domain.

So instead of seeing test.kevquirk.com/feed.xml I saw src.qrk.one/feed.xml.

This happened because Bunny requested the file from the origin using its own hostname, not the hostname I typed. In simple terms:

• I visited test.kevquirk.com/feed.
• Bunny checked its cache. It wasn’t there, so it asked my origin for the file.
• But Bunny made that request using its own hostname (src.qrk.one), not the one I typed.
• Apache saw the request coming from src.qrk.one/feed and applied the .htaccess redirect to /feed.xml.
• Apache then rebuilt the redirect URL using the hostname it was given, which was src.qrk.one.

So Apache went:

“Oh, you want /feed? Sure. That’s at src.qrk.one/feed.xml. Here ya go…”

Fixing the problem

This would not break anything for visitors, but I didn’t want src.qrk.one appearing anywhere. It looked messy.

Two changes fixed it:

1. Enable Forward Host Headers in my Bunny pull zone.
2. Add test.kevquirk.com as a domain alias of src.qrk.one on my VPS.

Forward Host Headers makes Bunny tell the VPS the hostname the visitor used. So instead of:

“I’m asking for this on behalf of src.qrk.one.”

Bunny says:

“I’m asking for this on behalf of test.kevquirk.com, not src.qrk.one.”

The domain alias ensures Apache accepts that hostname and serves it correctly.

Magic. 🪄🐇

The other thing to double-check is that every page sets a proper canonical URL. The origin domain is publicly accessible, so crawlers need to know which domain is the real one. That should always be the Bunny pull zone domain.

In Jekyll this is simple. Add the following to the head section of your layout:

<link rel="canonical" href="{{ page.url | absolute_url }}">

The final straight

With the redirect behaviour sorted, the last step was to add a purge step to my deploy script so Bunny knows to fetch the latest version whenever I publish a new post or update something.

Here’s the snippet I added:

# --- Clear Bunny Cache ---
echo "🗑 Clearing Bunny Cache..."
PURGE_RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X POST \
  -H "AccessKey: $BUNNY_ACCESS_KEY" \
  "https://api.bunny.net/pullzone/$PULL-ZONE-ID/purgeCache")

if [ "$PURGE_RESPONSE" -ne 200 ] && [ "$PURGE_RESPONSE" -ne 204 ]; then
  echo "⚠️  Bunny purge failed (HTTP $PURGE_RESPONSE)"
  exit 1
fi

I set my Bunny API key and Pull Zone ID as variables at the top of the script. The if statement simply says, “If the response isn’t 200 or 204, tell Kev what went wrong.”

And that is it. Last night I flipped the switch. Bunny CDN now sits in front of the live site. I also moved the VPS from Ionos to Hetzner because Ionos now charge extra for a Plesk licence. I went with Hestia as the control panel on the new server.

If you spot any bugs, please do let me know, but everything should be hopping along nicely now. (See what I did there? God I’m funny!)

2025-11-13 18:59:00

Alex’s blog is a one that I only discovered a couple days ago when he emailed me about my previous post. We ended up having a good old natter about all kinds of things.

As is par for the course, I checked out his blog, quickly found we have a lot in common, and our love of email is one of them.

As I’ve mentioned before, I’m very anal with my email and like Alex, I also look forward to checking my email every morning as there’s usually at least 1 interesting email from a reader. Today I have 5 of them to reply to (including a response from Alex) - it’s one of my favourite times of the day.

Anyway, I digress. Like Alex, I love email - it’s a fantastic way to communicate with the rest of the world. It’s a tried and tested, robust tool. It’s not email that’s the problem, it’s the people who use it.

Alex is also building his own CMS for HTML, which is another thing we have in common.

Anyway, go read his blog. It’s great.