202412271311 Homelab Redesign 2025

In 2025, the goal for the homelab is to move it away from a monolithic structure into small, decoupled and highly available nodes.

For some context - here is the current infrastructure topology

1. A Node 804 8 Bay NAS chassis
2. 6 mixed groups of Seagate Ironwolf and Exos drives, of various storage capacities
3. Proxmox VE in bare-metal as the KVM Hypervisor
   1. Linux Containers (LXC) are deployed for single infrastructure purposes:
      1. A lxc for running Tailscale as a subnet router
      2. A lxc for running Adguard home
      3. A lxc for my monitoring stack, consisting of prometheus exporters for the PVE parent host, the VM’s and other applications.
   2. Ubuntu and Debian Virtual machines for production workloads. Here is the VM topology:
      1. An Ubuntu 22.04 VM for self-hosted applications that do not require graphic acceleration
      2. A Debian 11 Bookworm VM for JellyFin with iGPU passthrough
      3. A Debian 12 VM for haos
      4. A Debian 11 Bookworm VM as my Reverse Proxy Node
      5. A Ubuntu 22.04 VM for running my arr-stack for my linux ISO’s.
   3. A Truenas VM

All of this application currently lives in a single, black box, to which I call it my homelab. The plan for 2025 is to move the homelab towards a modular and scalable homelab solution that is space optimised, highly-available and cost effective. Making it modular, alongside some future plans to provision through automation, managing via Kubernetes and also GitOps – the whole homelab can be portable.

Hardware Goals

The general plan is to move the hardware solution into smaller compute units. One of the goal is to move away from the monolithic hardware solution of using a Fractal Design Node 804 as a NAS and move towards a space-optimised ITX Jonsbo N3 chassis.

General Goals

1. Treat storage solutions as expandable hardware modules. A Jonsbo N3 chassis is approximately less than half in terms of volume and foot space while accommodating the same amount of hard drives as the Node 804 Chassis. This means for the given same footprint, I could potentially have 16 drives instead of 8.
2. Moving to a bare-metal TrueNAS install adheres to the single responsibility rule where the infrastructure of the hardware itself is designed to just do one thing. This decouples itself from other production workloads. Currently, in instances where I do need to take down the TrueNAS VM to install new HDD’s – the production workloads are also affected.
3. Decoupling storage from production workloads helps to instil a possibility of high availability solutions. Nodes that runs the production workloads are not inherently tied to the size of the parent hardware (Node 804) nor its downtime.
4. As I am planning to move out of my current home in the next 4-5 years, the current homelab infrastructure takes up too much space. I would like to downsize my homelab into smaller compute units that are portable and modular.
5. I would like to play and learn deeper into Kubernetes beyond simple kubectl ands starting an amateur cluster with kubeadm. How can I create a production cluster than can be easily scaled with new nodes being added even if they are remote nodes?
6. I want to start automating deployment steps such as the whole installation process through Ansible for building base images without all the hard work

Here’s a few things I want to achieve next

1. Draw up a re-design on the hardware to be provisioned
2. Write up a cost breakdown
3. Write up a plan on how to migrate the hardware over