Build. Break. Rebuild. Repeat.

At some point, a perfectly reasonable interest in technology turned into a rack full of hardware, too many services, an unreasonable amount of networking, and the realization that I had somehow ended up running my own little datacenter, power bill be damned.

This was not the original plan.

The original plan was a homelab. You know, normal nerd shit. A few machines, some virtualization, a place to test things, learn new tools, host some services, have a little data privacy, and build without worrying about breaking anything important.

Then the lab needed better networking. The networking made me want better infrastructure. Better infrastructure meant I needed monitoring. Then I started self-hosting more things, playing with local AI, building security tooling, and asking increasingly dangerous questions like, I wonder what happens if…

Turns out that’s an expensive fucking question.

Twenty Years of Troubleshooting Apparently Does Something to Your Brain

Before all of this, I spent twenty years maintaining military aircraft.

There are a lot of things that experience taught me, but one of the biggest was how to troubleshoot. When something breaks, you don’t start throwing parts at it and praying. You isolate the fault. You test. You gather evidence. You prove the failure. Then you fix it, document it and verify that the system actually works before you walk away.

After doing that long enough, it stops being a procedure and just becomes how your brain is wired.

So when I started building out my homelab, I approached it the same way. I wanted to understand how everything worked together, not just copy somebody else’s configuration until the error message went away, RIP StackOverflow. If something broke, I wanted to know why it broke. If a fix worked, I wanted to know why it worked.

Eventually, that curiosity shifted from how does this work? to how can I make this fail?

And that’s where things get fun.

Building infrastructure teaches you one side of a system. Trying to break it teaches you another. Suddenly I wasn’t just thinking about whether something worked. I was thinking about how it was exposed, what assumptions I’d made, what I’d misconfigured, what an attacker would see, what would happen if one component disappeared, and whether the rest of the environment would behave the way I thought it would.

Turns out, sometimes it does.

Sometimes it very fucking much does not.

The Part Most Write-Ups Leave Out

I’ve read and watched an obscene number of technical guides over the years, and they’re incredibly useful, sometimes. But there’s a weird thing that happens once a project becomes a guide: all the messy parts disappear.

You see the final architecture. The correct commands. The configuration that worked. Maybe a nice diagram with some arrows. Everything looks suspiciously intentional.

What you don’t see is the two hours spent banging your head into the keyboard, troubleshooting the wrong thing because the original assumption was bad. You don’t see the configuration change that fixed one problem and quietly created another. You don’t see the hardware that refused to cooperate, the command that absolutely should have worked, or the moment I finally realized the entire problem was caused by one stupid setting I looked at six fucking times.

The finished build tells me what you made. The troubleshooting teaches me how it works.

That’s the part I want to know about.

So I started documenting mine.

I haven’t discovered some revolutionary way to build a homelab; just like every experiment I run doesn’t end with some beautifully optimized production-ready system.

Some of this shit goes sideways. That’s a lie, most of it always does.

Thankfully, that’s useful too.

So I Made KidRelyt

KidRelyt is where all of that is going now: homelab infrastructure, networking, self-hosting, offensive security, defensive testing, local AI, architecture decisions, troubleshooting, failed experiments, rebuilds,  and documenting the rabbit holes that connect it all.

Some posts will be straightforward technical walkthroughs. Some will be build logs. Some will start with a problem and end with the fix. Others may start with what I thought was a good idea and end with a detailed explanation of why it was absolutely the worst idea, ever, maybe.

I’m keeping the messy middle because that’s where most of the learning happens for me. This is what helped me learn the most when studying for OSCP. Shoutout to the people who post long form walkthoguhs of boxes, you guys are the real MVP’s.

If I spend four hours discovering that one tiny configuration choice was responsible for everything going to shit, I want that documented. Partly because it might save someone else four hours.

Mostly because six months from now, the idiot Googling the exact same problem will probably be me.

There isn’t some grand content strategy behind this. I’m building things I want to understand, breaking things I want to understand better, and trying not to forget to document the things I learn along the way.

That’s KidRelyt.

Build. Break. Rebuild. Repeat.

Now let’s see what I can fuck up.