The Platform Mindset

I started this homelab in 2024 as a modest experiment: replace a few subscriptions and see what I could learn. What it became was far more personal. It turned into a segmented, self‑healing platform that taught me more about real infrastructure than any classroom module. The point wasn’t to prove I could self‑host. The point was to rebuild my relationship with systems that stay calm under pressure.

As an ops leader, I spend most days in the space between strategy and delivery. The lab gave me a direct, tactile way to close that gap. It pulled me into the details, forced me to design for failure, and sharpened how I think about risk, governance, and operational discipline. I’m writing this as a retrospective, not to list what I built, but to reflect on what the work changed in me as a leader.

Why fight the cloud? Autonomy and the systems mindset

SaaS scales quickly and removes upfront friction. For enterprises, that trade‑off often makes sense. But as a personal experiment, it came with a different cost: autonomy. When everything lives behind someone else’s UI and billing model, you lose the ability to truly understand or own the system.

My key takeaway is simple: self‑hosting isn’t for everyone, but for a systems‑thinker, the real value is the learning loop. Building the stack end‑to‑end gave me a working fluency in cloud concepts before I sat a single Azure training course. It also made me far more empathetic to the teams I lead, because I now recognise the difference between a good plan on paper and a resilient system in the real world.

This project helped me transition into IT management. It was a non‑traditional path, but it gave me the practical foundation I needed.

The foundation: Proxmox and RAID

At the core is a single node running Proxmox Virtual Environment (PVE). I chose Proxmox for its KVM virtualisation and Linux Container (LXC) support, which let me build a clean hypervisor layer and keep my services modular.

The node is a Dell PowerEdge R730, used enterprise hardware that I cleaned, upgraded, and adapted for home use. It runs the Proxmox OS on SSD and a 40TB bulk storage pool on 3.5” drives. It’s loud, over‑specced, and far from elegant, but working with real datacentre‑class kit grounded my understanding of what “reliability” actually demands.

Storage is configured with RAID 1 at the hardware controller level. That decision came from hard lessons; early data loss forced me to confront how quickly “good enough” storage choices collapse under real workloads.

Skipping a backup strategy early on cost me time and data. It was a painful but essential lesson in redundancy and recovery.

Once the platform stabilised, the next phase was containerisation. I currently run around 20 services orchestrated via Docker Compose across dedicated VMs, from this site on NGINX to monitoring, uptime checks, and internal tools. The goal wasn’t to host everything; it was to learn how services behave under change, failure, and scale.

Trust by necessity: segmenting the network

The network is the nervous system of the lab. This was where I applied governance principles most directly: isolate risk, control access, and enforce least privilege by default.

I built several VLANs and implemented inter‑VLAN routing to be deny‑by‑default. This segmentation is the practical expression of zero‑trust: assume compromise, limit blast radius, and validate every path.

Getting NAT rules and TLS certificates right took longer than expected. It forced me to live with the consequences of sloppy assumptions, and to document everything I touched. That practice translated directly into how I now design and run programmes: fewer “invisible” decisions, more explicit reasoning.

Failure is commitment: the continuous learning loop

I won’t sugar‑coat it. This was messy.

I locked myself out of the router and hypervisor more times than I care to admit. I lost SSH keys. I rebuilt VMs I didn’t back up. I spent two hours debugging a “network issue” that was actually a loose Ethernet cable. These moments weren’t embarrassing; they were instructive. They forced me to slow down, map dependencies, and respect the operational reality of the systems I build.

This is the kind of failure that changes how you lead. It makes you more precise in your risk registers, more honest in your delivery plans, and more patient in your architecture reviews.

I’m now writing this from a stack I built, secured, and actively maintain. That feedback loop is the point.

The ops leader who can build

The lab is more than a side project. It’s my engineering sandbox, and it has reshaped how I operate professionally.

I’ve learned there’s a gap between strategic programme delivery and technical execution. Many leaders can manage budgets and roadmaps, but they haven’t wrestled with inter‑VLAN routing or built their own infrastructure from the ground up. This project helped me become the bridge between technical risk and governance decisions.

It also gave me a personal reference point. When I talk about reliability, resilience, or recovery, I’m not quoting a framework. I’m drawing on a system I’ve broken and rebuilt since 2024. That makes my judgement sharper, and my delivery style calmer.

What’s next? More hard‑won lessons, better documentation, and a deeper commitment to building systems that can take a hit and keep going.