There's one person behind this.
It started with a couple of laptops I never turned off, and an AWS bill I couldn't justify.
Almost everything since then I learned by breaking it first.
This started in a bedroom, not a server room. One laptop stayed on day and night, fan humming under a desk lamp. Some nights I'd reboot it into Windows for something unrelated, and whatever was running on it simply stopped; I'd notice the next day. No budget, no plan, just stubbornness and a long run of bad decisions that slowly got better.
How did Albgott start?
With whatever I had lying around: a couple of laptops and no plan. What made it serious was an AWS bill of about €300 for machines I'd left running, plus being tired of depending on Google Drive, a Jenkins someone else hosted, and every other SaaS I didn't control. So I started building my own. Badly at first, a bit better with every mistake. I've torn the whole thing down and rebuilt it more than once, each time on steadier ground.
Why not just use AWS, or any cloud provider?
I did, until that bill. Deploying a container on a managed platform is the easy part; anyone can do it in an afternoon. Designing the network segments, writing the firewall rules, being the one who gets the alert at 3 a.m.: a managed platform does all of that for you without you noticing, and that's exactly the part I wanted to learn.
Isn't this overkill for one person?
Probably, yes. Eight isolated network segments, three nodes, full observability and its own CI pipeline, all for one person's side projects and client work. I could run everything on a single VPS. I don't, because the point is to run it the way a real team would, and I can't learn that on a VPS.
What's the worst thing that's broken?
Mostly the early years. My ISP never gave me a static IP, so for a while I updated it by hand in half a dozen places every time it changed, until I finally set up DDNS. Worse: my DNS server went down once, and I found out because a client called to ask why their site was broken. None of my dashboards told me. That got me a second DNS server, kept in sync with authenticated zone transfers, and taught me not to trust a system I can't see inside of.
How do you know when something's wrong now?
For a long time, by looking. I'd check a handful of dashboards by hand and hope nothing had died quietly since the last time. When something did break, I often couldn't remember where to start, because none of it was written down. Both problems got fixed the same way, just slower than they should have: alerts go straight to Telegram now, and every service has internal documentation that I update the same day I change it.
What's a technical problem that taught you something?
WireGuard on the MikroTik. A peer would complete the handshake and look connected, and traffic still wouldn't route. RouterOS doesn't give the tunnel interface a gateway address just because a peer has one, so you have to add it explicitly with /ip address. It's a one-line fix, and now it's the first warning in my WireGuard docs. It also taught me a more general lesson: a working handshake only proves the tunnel exists. Whether traffic goes anywhere is a routing question, and whether it's allowed is a firewall question.
Why make any of this public?
Because a private homelab doesn't prove anything to anyone but me. Writing it down for strangers also forces me to be precise: a diagram I publish has to match the real thing, and a roadmap I publish has to keep moving.
What early decision would you make differently today?
Not segmenting the network from day one. At first everything lived on the same broadcast domain, because splitting it up felt like overkill for a project with no users. It wasn't overkill. Every later change had to start by undoing a decision I'd made in one afternoon without much thought.
So is Albgott finished?
Not even close. A NAS is next, for real off-node copies and shared storage between nodes, and plenty of setup still needs turning into code. After that, local AI: the GTX 1070 in pve01 is already shared with LXC containers through device bind-mounts instead of VFIO passthrough, so an inference server can use it without taking it away from the host. The full list lives on the roadmap →. I suspect the most interesting part is still ahead.
GOT SOMETHING THAT CAN'T GO DOWN?
If you're building infrastructure or a service that has to keep working after launch day, tell me about it. I like working through the hard parts.