Part 1 of 2. Part 2 covers the three rounds of AI input and the contested decisions.
There’s a certain kind of homelab project that starts as a reasonable question and ends with you staring at a 60-page architecture document wondering how you got here.
That’s where I am.
A Working Mess
My homelab has been running on Unraid. It works. I have fourteen Docker containers running, a Synology Diskstation for backups, a Home Assistant Green for automation, my gaming PC doing AI inference, and enough Shelly devices to control the lighting in every room of my house. It’s not elegant, but it’s mine, and it mostly does what I want.
The problem isn’t that it’s broken. The problem is that the more I’ve learned, the more I can see the places where it’s more accreted than designed. More generative than purposeful. No reverse proxy. No infrastructure-as-code. Secrets half-managed. Backups partially verified. A git-watcher script that was never actually version-controlled. The kind of debt that doesn’t break you today but makes every future change a little harder than it needs to be.
I’d been thinking about a proper rearchitecture for a while. But thinking and doing are different things, and I needed a question sharp enough to actually move on.
The Question
What if I put everything on the table? No sacred cows. What would the setup look like if every decision were optimized based on using the hardware at its most powerful and efficient, and every software decision was driven by use cases and outcomes rather than favorites or familiarity?
I’d be deeply interested in the answer to this question, but the legwork to get there is daunting to my ADHD. Thankfully we’ve got AI to offload that kind of cognitive gruntwork to.
I also wanted to avoid problem-solving with my credit card. A hard constraint of ‘no new purchases’ was applied. Work with what you have.
So, here’s the full list:
- Selected configurations are always best practices aligned
- Infrastructure as code
- No new hardware. All architecture, method, process, software and OS are fair game.
- 3-2-1 backups
- Free and Open Source software
- Development vs Production environments, where possible
- End to end administrable by human or by agent
- Rigorous changelog
- Securely accessible inside and outside the home
- Tier 2 Availability (redundancy primarily in storage)
- RTO: 24hrs max
- RPO: No data loss is acceptable
- MTTR: 4 hrs
- Failover: Manual
- Migration downtime should be minimized, but is the least concern. Home Assistant is the largest concern for migration downtime.
What I Have to Work With
Three machines, a Synology, and a Home Assistant Green.
The primary server is a 2017 era repurposed HP workstation — i7-7700K, 32GB DDR4, a GTX 1070 I use for audio transcription, and a mix of spinning rust and SSDs. It’s been getting the job done.
The beast machine is my desktop — where I’m typing this. An i9-14900K with an RTX 4080 Super, 48GB of DDR5, and two 4TB NVMe drives. It currently runs Ollama for local LLM inference and games on the weekends. The “games” part of that may be in jeopardy.
The third machine is a Sandy Bridge i7-2600K from 2011. It runs Ubuntu and various things I’ve tried over the years. She’s old and no longer as mighty as when I specced her back in the day, but she has sentimental value and still shows up to work on time if the task is sized right.
The Synology is a DS418 with 4×8TB drives. It handles backups. The Home Assistant Green runs home automation and will be staying exactly where it is for as long as I can manage it.
Writing the Requirements Document
Before I could ask anyone — AI or otherwise — for a design, I had to know what I was asking for. So I wrote a requirements document.
It covered the hardware above in detail, including exact CPU/RAM/storage/GPU specifications per machine. It listed every service I run and why I run it. It articulated the constraints.
It also specified something I hadn’t entirely thought through until I wrote it down: I wanted the final architecture to be end-to-end administrable by an AI agent. Not because I’m looking to fully hand over the keys, but because if Claude can autonomously execute operations, that means the operations are well-documented, idempotent, and testable. The discipline of designing for AI operation will hopefully produce better infrastructure for human operation too.
Some of you may be screaming inside about the sustainability (along many axes) of letting the AI run the show. And rightly so. But at this point we were at the thought exercise stage of the game and there was plenty of time to navigate risk as we kicked off the opening ceremony.
What Came Next
With a requirements document in hand, I did something I hadn’t done much of since diving into LLM tools: a structured response comparison. Not just asking one system and running with the answer, but treating it as an input process.
Part 2 is where the tournament happens.
This is part of an ongoing series about running an obsessively documented homelab and learning something new every time I break it.