¶ Homelab Journey
This page captures how the lab evolved over time, both technically and practically. The path was not a straight line. It was a series of experiments in performance, heat, noise, power efficiency, storage design, orchestration, and what was actually worth running at home.
¶ The First Phase: Apartment unRAID + Basement R610
The first real phase of the lab was split across two very different systems.
One was an older Intel i5-3400 unRAID box in a Fractal Node case. That system ran nearly everything and made apartment living rough under heavy load, especially when GPU-heavy work entered the picture. Heat, noise, and overall comfort became real design constraints, not just annoyances.
At the same time, there was also a $75 Dell R610 in the parents’ basement running workloads like Minecraft and Lancache. That machine represented the cheap-enterprise-server phase: useful, fun, and easy to justify, but not ideal long term from a power and efficiency standpoint.
¶ Selling the R610
The R610 basement phase did not last forever. That server was eventually sold, marking the end of the “cheap old rack server in the basement” era.
¶ Free Rack, Real Rackmount Era, and the NAS Case
A major turning point came with getting a free 22U half-height rack. That changed the lab from “whatever hardware can fit somewhere” into something that could actually be structured and organized.
Around that same broader phase, the lab moved into multiple rackmount servers, including:
- Lenovo rack hardware
- Dell R630
- HP DL380 Gen9
At the same time, the parents bought the Supermicro case that is now used for the current NAS. That helped establish a more permanent storage foundation compared with the earlier Fractal Node setup.
After that transition, the Fractal Node case was sold.
¶ The Multi-Server Phase
This was the era where the lab felt the most like a traditional homelab rack build:
- several larger rackmount systems
- more distinct roles
- more room for separation of services
- more experimentation around storage and clustering
It also came with the classic downsides of older enterprise hardware: heat, power draw, and operational overhead.
¶ Consolidation into the Gigabyte System
At one point, the three larger rack servers were powered down and replaced with the Gigabyte system. This was part of the broader pattern of testing whether fewer, bigger systems were better than multiple separate boxes.
That phase represented another swing back toward consolidation after the earlier move toward multiple nodes.
¶ Free Small-Form-Factor Systems
Later, the lab gained a major boost from free or family-supplied hardware.
Important additions included:
- Lenovo M900 Tiny nodes and a QNAP NAS from a friend in the fire department
- Lenovo Neo systems from the parents
These systems helped push the lab toward a more modular, lower-power design compared with the older enterprise server approach.
¶ Selling During the Hardware Boom and Funding the MS-01s
As the lab evolved, the larger servers and extra RAM were sold during the hardware boom. That sale helped fund the shift into the current MS-01-based design.
That move was important because it was not just a hardware refresh. It was a philosophical shift:
- away from bigger, older, power-hungry enterprise boxes
- toward smaller, more efficient, but still powerful systems
- without giving up flexibility or clustering
¶ AI Rig and Re-Evaluating Local AI
There was also a dedicated local AI rig phase. It made sense for experimentation, but over time the balance of power cost versus local performance became harder to justify.
Eventually, the local AI rig was sold in favor of using a hosted Ollama subscription, because the operating cost and local model speeds did not justify keeping the rig around.
¶ Storage and Orchestration Evolution
The storage and orchestration side changed repeatedly over time too.
¶ Phase 1: All-in-One unRAID
The original model was a single unRAID box doing nearly everything.
¶ Phase 2: Multiple Servers with Ceph and Swarm
The lab then moved toward multiple servers running Ceph and Docker Swarm, splitting responsibilities across nodes instead of keeping everything in one place.
¶ Phase 3: Back Toward Consolidation
The Gigabyte system represented another move back toward a consolidated platform after the earlier multi-server phase.
¶ Phase 4: Back to Multiple Servers Again
The current direction returns to multiple smaller systems, now centered on the MS-01 cluster, along with Swarm, Ceph-backed storage, and more mature automation.
¶ Learning the Right Amount of Complexity
Another recurring pattern in the lab was testing orchestration models to find the right balance between capability and maintenance overhead.
¶ Stack-by-Stack Isolation
Running each stack in its own VM was part of the experimentation process. This helped with isolation, testing, and understanding blast radius.
¶ Kubernetes Experimentation
Kubernetes was also tested seriously. In practice, it ended up feeling like overkill for the actual size and needs of the environment.
¶ Back to Swarm
That led back to Docker Swarm as the preferred orchestration layer: simpler, easier to reason about, and better aligned with the real needs of the lab.
¶ The Current Direction
Today’s lab reflects the lessons from all of those stages:
- avoid unnecessary heat and power draw
- prefer practical efficiency over theoretical maximum scale
- use multiple smaller systems when they provide better flexibility
- automate aggressively where it saves time
- keep orchestration simple enough to maintain
- separate storage, compute, and backup roles in a way that makes sense at home
The result is a platform built around MS-01 nodes, Swarm, Ceph, Ansible, HiveMind, and Unraid-backed bulk storage, with the current design shaped as much by lived experience as by technical preference.
The current repos mirror that direction:
HomeLabcaptures host, VM, Proxmox, Unraid, and Ansible automation.Docker-Swarmcaptures the running application layer.HiveMindconnects Git changes to Swarm deployment.wiki-jskeeps the operating model documented.
¶ Lessons Carried Forward
- Hardware that is cheap to buy can still be expensive to power, cool, and listen to.
- A service is easier to keep when its config, storage, monitoring, and backup path are all obvious.
- Git-backed changes are slower than random shell edits, but they make recovery and review much easier.
- The best platform for this lab is the one that can be maintained consistently, not the one with the most impressive architecture diagram.
