Building in Public: What Running a Blog on Your Own Infrastructure Teaches You

It is one thing to read about infrastructure. It is another to be woken by an email — or worse, a stranger on the internet politely telling you your site is down — and realise that the thing that’s broken is yours, the page is yours, and the only person who’s going to fix it is also, regrettably, yours. Running a blog on your own infrastructure is the cheapest, most effective infrastructure course I know, because every lesson arrives attached to genuine embarrassment.

I run this place largely myself, on hardware and services I chose, and I’ve made most of the mistakes available to make. Here’s what the experience actually teaches you, as opposed to what the “I host my own blog btw” crowd likes to imply it teaches.

1 You learn what “uptime” really means

When the site is a hobby, you think uptime is a number on someone else’s status page. When it’s yours, you learn that uptime is a practice. You learn it the first time a TLS certificate silently fails to renew and every visitor gets a frightening browser warning for six hours because you weren’t watching.

The lesson isn’t “set up renewals” — everyone does that. It’s “verify the thing you automated actually ran.” So you end up doing what every grown-up operation does, and you build the smallest possible watchman:

#!/usr/bin/env bash
# warn if the cert expires within 14 days
domain="vo.rs"
end=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
      | openssl x509 -noout -enddate | cut -d= -f2)
secs_left=$(( $(date -d "$end" +%s) - $(date +%s) ))
days_left=$(( secs_left / 86400 ))
[ "$days_left" -lt 14 ] && echo "CERT for $domain expires in $days_left days" >&2

Hang that off cron, pipe a non-empty output to an email, and you have learned the real lesson: automation without verification is just a delayed surprise.

2 You learn to respect the boring parts

Anyone can deploy a blog. Keeping one healthy teaches you to love the unglamorous machinery: DNS that you understand rather than fear, a reverse proxy config you can read at a glance, backups you’ve actually restored, and a deploy that’s the same every single time.

The boring parts are where reliability lives. A flashy setup that you can’t reason about at 1am is worse than a dull one you can. I have replaced clever things with boring things many times and never once regretted it. Building in public quietly beats the love of cleverness out of you, which is one of its kinder gifts.

3 You learn that performance is a feature you have to defend

When you control the whole stack, the page weight is your fault and nobody else’s. There’s no platform team to blame for a slow render. You discover that performance isn’t a thing you achieve once; it’s a thing that constantly erodes — a heavy image here, an extra script there — and has to be actively defended.

Owning the infrastructure means you can fix it properly: cache aggressively, ship images at the right size, drop the third-party junk you don’t need. But it also means you notice, because the numbers are yours. You start treating a slow page as a bug, not a fact of life.

4 You learn the difference between a hobby and a service

The most uncomfortable lesson is about responsibility. The moment other people read your site — or rely on it, or link to it — it quietly stops being a toy and becomes a small service with users. You can still treat it casually, but the consequences of doing so stop being purely yours.

That shift teaches a kind of humility that no tutorial conveys. You start asking the questions real operators ask:

• If this box died right now, how long until I’m back, and from what?
• What’s the worst thing a bug here could leak or break?
• Am I one forgotten renewal away from looking foolish in public?

These are exactly the questions professional infrastructure work demands, and answering them for your own little site is the cheapest possible place to practise.

5 What it doesn’t teach you

In fairness, building in public has limits as a teacher. You won’t learn how things behave at real scale — a personal blog never sees the traffic that breaks systems in interesting ways. You won’t learn to work within a team’s constraints, or to navigate the politics of a platform with thirty stakeholders. And you can absolutely over-invest, polishing infrastructure for an audience of dozens while telling yourself it’s professional development.

So hold it honestly: it’s a brilliant sandbox, not a substitute for the real thing.

6 The honest verdict

If you want to actually understand the boring, load-bearing parts of running software for other people — certificates, DNS, backups, deploys, performance, the weight of responsibility — there’s no cheaper or more memorable classroom than a blog you host yourself and let people read. The stakes are low enough to survive your mistakes and high enough that you feel them.

It won’t make you a distributed-systems wizard, and it shouldn’t be your whole CV. But for turning abstract infrastructure knowledge into the kind you carry in your bones, building in public earns its reputation. Just don’t let the cupboard full of servers convince you the lessons are bigger than they are.