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.

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:

1
2
3
4
5
6
7
8

#!/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.

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.

The pattern repeats whatever you self-host. The first time I ran Nextcloud as my own Google Drive, the exciting part — getting it installed — took an evening, and the unglamorous part — backups I’d actually tested, a reverse proxy I understood, a database I knew how to restore — took the next month and was where all the real learning happened. The install is the trailer; the maintenance is the film.

You learn to actually read the logs

Here is a lesson that sounds trivial and isn’t: when the thing is yours, you start reading logs instead of grepping them in a panic. A blog generates a steady, legible stream — request logs, the reverse proxy’s access and error logs, the occasional stack trace — and after a few months you develop an eye for what normal looks like. You notice the 3am spike of bot traffic probing for WordPress paths on a site that has never run WordPress. You notice a slow creep of 502s that means a backend is flapping. You notice your own deploy quietly throwing warnings nobody reads.

A tiny, dumb habit pays off here more than any fancy observability stack:

1
2
3

# tail the proxy error log and the access log together, highlight non-2xx
tail -f /var/log/caddy/access.log \
  | awk '{ if ($9 !~ /^2/) print "\033[31m" $0 "\033[0m"; else print }'

That is not clever. It is exactly the point. You learn that looking at your system regularly — not just when it’s on fire — is what separates people who run things from people who deploy things and hope. The professional version is dashboards and alerts; the cheap version is a terminal you glance at, and the cheap version teaches the same instinct.

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.

The concrete version on this site: hero images are served as responsive WebP at several widths so a phone never downloads a desktop-sized image, the CSS and JS are minified at build time, and there is no analytics script phoning home on every page load. None of that is exotic. All of it is invisible until you measure, and you only bother measuring when the slow page is your slow page and the bounce is your reader leaving.

You learn what goes wrong, in order

There is a depressingly predictable order in which a self-hosted blog breaks, and living through it is the education:

• Certificates first. The renewal that didn’t fire, the cron job that silently died, the ACME challenge that broke when you changed the proxy config. This is the most common outage by a mile, and it’s always self-inflicted.
• DNS second. A record you changed and forgot, a TTL longer than your patience, a registrar that logged you out at exactly the wrong moment. DNS problems are never DNS problems until they’re always DNS problems.
• Disk third. Logs you never rotated, a database that grew, a backup directory eating the volume it was meant to protect. The box doesn’t crash dramatically; it just quietly fills up and starts refusing writes.
• You, last. The deploy you ran tired, the config you “just tweaked,” the change you pushed straight to production because it was only your blog. Most of my outages have been me.

Knowing this order is genuinely useful, because when something breaks you check the likely causes first instead of suspecting the exotic ones. That triage instinct is most of what experienced operators are actually selling.

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.

You learn that infrastructure scope creep is real

The most seductive trap of building in public is that a blog is never just a blog for long. You add a comment system, then you need a database and spam filtering. You want a status page, so now there’s monitoring. You decide the photos should be self-hosted too, and suddenly you’re running a Jellyfin media server and wondering how a static site turned into a small data centre in your spare room.

This teaches you something the tutorials gloss over: every service you add is a service you maintain forever. The marginal cost of “just one more thing” is never the install — it’s the updates, the backups, the certificate, the log volume, and the 3am phone call it can now generate. Running your own infrastructure beats this into you faster than any architecture review, because you are the one who pays the cost, in your own evenings. You learn to ask “do I want to operate this for years?” before “can I set this up tonight?” — which is, not coincidentally, the question that separates good system design from a graveyard of half-maintained side projects.

The flip side is genuinely empowering. Because you control the whole stack, you can integrate things in ways a managed platform would never let you. You can put everything behind one VPN, share one backup strategy, run one reverse proxy. The coherence you can achieve when you own all the pieces is real — it’s just earned, not given.

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.

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.

Who should actually do this? Anyone who wants the felt understanding that only comes from owning the consequences — developers who keep handing operational concerns to “the platform team” and never quite learn what those concerns are, hobbyists who like building things and don’t mind occasionally breaking them in front of strangers, and anyone weighing a move into operations who wants a low-stakes proving ground. Who should skip it? Anyone who needs guaranteed uptime, anyone allergic to the maintenance tax, and anyone who would rather write than operate — for them a managed host is the honest, sensible choice, and there is no shame in it. The lesson of building in public is partly learning, for yourself, which of those two people you actually are.