There's one person behind this.
It started with a few laptops I never turned off, and an AWS bill I couldn't justify.
Everything since then has basically been learning the hard way.
This started in a bedroom, not a server room: one laptop that stayed on all the time, fan running under a desk lamp. Some nights I'd reboot it into Windows for something unrelated, and whatever had been running on it just stopped — no warning, I'd only notice later. There was no budget and no real plan, just stubbornness and a long run of bad decisions that slowly got better. The questions below are the honest version of how that turned into what you're looking at now.
What were you thinking when you started building Albgott?
Whatever I already had lying around, mostly. The first version was a couple of laptops I never turned off — one of them dual-booted into Windows, so whenever I needed it for something else, whatever was running on it went down with it. What actually pushed me to fix that was an AWS bill of about €300 for machines I'd left running and forgotten about, plus being tired of depending on Google Drive, someone else's hosted Jenkins, and every other SaaS I didn't control. So I started building my own — badly at first, a bit better each time I learned something. There was never a master plan. 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 that in an afternoon. Drawing the network segments, writing the firewall rules, being the one who gets paged at 3am when something breaks — that's the part a managed platform quietly does for you, and it's also the part I actually wanted to learn.
Isn't this overkill for one person?
Yes, probably. Eight isolated network segments, three nodes, full observability, 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 proving I can operate this the way a real team would, not that I need to.
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 and stopped doing that manually. Worse: my DNS server went down once, and I found out because a client called to ask why their site was broken — not from any dashboard of mine. That got me a second DNS server for redundancy, and taught me not to trust a system I can't see inside of.
How do you actually 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 quietly died since the last time, and if something did break I often couldn't remember where to even 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 gets updated the day I touch it, not eventually.
Why make any of this public?
Because a private homelab doesn't prove anything to anyone but me. Once the network diagrams, the roadmap, and the actual gaps were out in the open, I couldn't quietly ignore the things I hadn't finished anymore. It's mostly self-imposed pressure — I'd rather be embarrassed about an unfinished backup strategy in public than pretend it doesn't exist.
What early decision would you make completely differently today?
Not segmenting the network from day one. Everything lived on the same broadcast domain at first, because splitting it up felt like overkill for a project with no users. It wasn't overkill — it just meant every later change had to start by undoing a decision I'd made in an afternoon without thinking much about it.
So that's it? Is Albgott finished evolving?
Not close. Backups are thinner than I'd like, plenty of setup is still manual instead of automated, and a NAS is next — not for extra storage, but for real backup copies of the server and shared storage between nodes, the kind of redundancy that actually makes things more reliable, not just bigger. I've also been wanting to run AI locally — nothing fancy, just something private enough that I don't have to send my data through someone else's API to try it. The boring, specific version of this list lives on the roadmap →. Realistically, most of what's interesting about this is probably still ahead of me.
GOT SOMETHING THAT NEEDS TO RUN?
If you're working on infrastructure, platforms, or services where reliability matters beyond day one, we'd like to hear what you're building.