About KidRelyt

Same mindset. Different machines.

I spent twenty years maintaining military aircraft, which is a pretty solid preparation for spending your free time staring at a terminal, wondering why the thing that worked perfectly yesterday apparently decided it no longer believes in operating today.

The hardware changed. The troubleshooting process really didn't. Isolate the fault. Prove the failure. Fix what broke. Verify it actually works. Try not to introduce three new problems while fixing the first one. Something I'm getting worse and worse with the more I do this.

But, that mindset has led me here.

Somewhere Along the Way, This Got Out of Hand

It started with wanting a little privacy from big tech, then my own labs when I was studying for OSCP because we all know how stable Offsec labs are. Then I wanted a homelab. Nothing ridiculous. A few machines, some networking, a place to learn, test things, run some services, and generally fuck around with technology without creating an incident somewhere that matters.

That was the idea, anyway.

Then the lab needed better networking. The networking needed infrastructure. The infrastructure needed monitoring. Then came self-hosting, virtualization, security tooling, local AI, offensive-security experiments, defensive testing. What came next was the realization that I'd somehow built a datacenter in my house for absolutely no defensible reason, a fact my budget (and my wife) remind me of daily.

Once you have the environment, though, you start wondering what else you can make it do. Or what you can make it survive. Or how spectacularly you can break it.

That's usually where things got interesting.

Why KidRelyt Exists

Most technical write-ups start at the end. Here's the architecture. Here's the configuration. Here are the commands. Here's the pretty little diagram showing how everything talks to everything else.

Cool. But that's rarely how the thing actually got built.

There were bad assumptions, dead ends, hardware that should have worked and didn't, and configurations that absolutely worked until they absolutely fucking didn't. There were three-hour troubleshooting sessions caused by something embarrassingly simple and rabbit holes that started with one question and ended with me rebuilding cough half the environment.

That is the part that I think is useful. The final configuration tells you what worked. The mess tells you why.

That's what KidRelyt is for. It's where I document the builds, failures, troubleshooting, architecture decisions, offensive-security experiments, defensive testing, local AI projects, self-hosted infrastructure, unnecessary rebuilds, and whatever other bullshit I manage to get myself into.

Sometimes that'll be a clean technical walkthrough. Sometimes it'll be a surgical autopsy. Sometimes it'll be me documenting an experiment while I'm still figuring out whether the idea was clever or profoundly idiotic.

But, that's the point.

The Maintainer Brain Never Really Left

Maintaining aircraft teaches you pretty quickly that guessing is expensive (or deadly). You don't replace something because you have a feeling. You isolate the problem, test, gather evidence, prove the failure, fix it, and verify the system actually works before calling the job complete.

Computers demand the same treatment, even when they are significantly more willing to lie directly to your face. If we could stop AI from hallucinating that would be wonderful.

That process is probably the only throughline in everything you'll find here. I'm interested in why something failed, not just the command that made the error disappear. I want to understand the architecture underneath it, what assumption was wrong, what actually happened, and whether I can reproduce the failure intentionally.

I am a firm believer that once you understand how something works, breaking it becomes a hell of a lot more useful. Fixing it is infinitely easier. And rebuilding it becomes a hell of a lot more interesting.

KidRelyt is a technical lab scratchpad with questionable supervision. Homelab infrastructure, networking, self-hosting, offensive security, defensive security, local AI, architecture, troubleshooting, questionable documentation, and the increasingly doubtable decisions connecting all of those things together.

I'm not here to pretend every project goes according to plan. I'm documenting the shit that worked, the shit that didn't, and the shit in-between where I figure out why.

Although the polished diagram is useful for a pretty thumbnail, the troubleshooting is always the story.

Build. Break. Rebuild. Repeat.