← Notes Ā·

The Lab Never Sleeps (But You Will)

On the particular madness of running your own infrastructure and building side projects with tech you don't fully understand yet.

There’s a particular kind of madness that sets in when you look at your electricity bill, cross-reference it against the cost of just using a VPS, and decide to buy another machine anyway.

This is homelabbing.

The pitch is rational: own your data, control your stack, learn by doing. And it’s true — there’s no better way to understand how something works than to be the one responsible when it breaks at 11pm on a Sunday. You will learn etcd. You will learn it under duress, in the dark, with your phone’s hotspot as your only internet because you somehow managed to misconfigure the very switch your router depends on.

But that’s also the point, isn’t it?

The unknown tech problem

Side projects compound this. They’re the one place where you get to pick the stack — which means they become a series of calculated bets on things you don’t fully understand yet.

I’ve written a P2P encrypted chat in Go when I barely knew Go. Built a single-process image gallery with Hono because I wanted to see if SQLite could carry the whole thing (it can). Rewrote parts of this site in Astro because the framework looked interesting and I had a weekend and a misplaced sense of confidence.

This is genuinely how I prefer to learn. Reading documentation for something you don’t need to build is abstract; reading it at 1am because the thing you’re trying to ship isn’t working yet is suddenly very concrete.

The failure mode is obvious: you spend 80% of your time fighting the unknown tech and 20% building the actual thing. The success mode looks identical from the outside but feels completely different from the inside — you built the actual thing and now you know the tech.

What the lab actually teaches you

Running your own infrastructure changes how you read someone else’s. You start noticing when a SaaS product has suspiciously good uptime. You appreciate boring architecture. You stop trusting single points of failure, including yourself.

You also learn to love the terminal in a specific, slightly unhinged way. Not because GUIs are bad, but because SSH is always there. The GUI might be down. The web panel might be unreachable. But if there’s a box and a port and a user, you can get in and fix things.

The homelab is a school with no timetable and a curriculum that expands to fill whatever hardware you have lying around.

The frustration is the feature

I’ve been doing this long enough to know that the frustrating parts — the misconfigured DNS, the container that works locally and refuses to work in production, the service that was working yesterday and has simply decided not to today — aren’t obstacles to learning. They are the learning.

Every ā€œwhy is this brokenā€ moment is a chance to understand something a layer deeper than you needed to yesterday.

The electricity bill remains unjustifiable. The machines stay on.

homelabside-projectsinfrastructure