My Homelab Journey: From Old PC to Personal Playground

A
Son Le

14 min read • 24 day ago

Views:Unavailable

Table of Contents

My Homelab Journey: From Old PC to Personal Playground

My homelab desk setup "A simple but mighty homelab"

home
Click to zoom

Introduction

I’ve always been fascinated by how systems work behind the scenes. As an engineer in my daily work, I wanted a space to experiment, break things, and learn without fear of production outages. That’s when I decided to build my own homelab.

This blog is my story of why I built it, what gear I used, the mistakes I made, and how others can start small and grow their own setups.

Definition

A homelab is simply a personal IT environment you set up at home for experimentation, learning, and self-hosting services. Unlike the big racks in data centers, your homelab doesn’t need to be complicated. You don’t need expensive equipment or a server rack.

In fact, I learned that a homelab could be as small as an unused laptop, a dusty desktop, or even a tiny Raspberry Pi. The real value wasn’t in the hardware - it was in the experiments, mistakes, and lessons learned along the way.

Old Dell SFF that started it all

Old Dell SFF that started it all
Click to zoom

For beginners, the best way to start is with whatever unused device you have lying around. Over time, as you learn what you need, you can upgrade your hardware and expand your setup.

Why You Should Have One

Building a homelab is one of the best ways to grow as an IT professional.

Here’s why:

  • Fun, Experience, Knowledge: It’s exciting to experiment, break things, and fix them again.
  • Hands-on Skills: If you work in IT, a homelab helps you understand not just what your software does, but also how it runs under the hood.
  • Explore Multiple Fields: Networking, virtualization, containers, firewalls, storage, and automation - all in one place.
  • Freedom: You can try any software or hardware setup, without company restrictions or cloud bills.

From my perspective, if you work in IT, having a homelab or home server is one of the best investments in your skills. For me, it was like a personal gym for technical knowledge. I wasn’t just reading about how software works; I was running it, configuring it, and sometimes crashing it. That freedom to experiment made all the difference.

Hardware You Might Use

When you’re ready to expand, here are the common hardware components for a homelab:

  • CPU: Multi-core for virtualization
  • RAM: The more, the better (16 GB+ recommended for VMs/containers)
  • Motherboard: With support for extra storage and NICs
  • PSU (Power Supply): Reliable enough for 24/7 running
  • Switch: Unmanaged (plug-and-play) or managed (supports VLANs and advanced features)
  • Router/Firewall: Commercial or DIY with pfSense/OpenWrt
  • Storage: SSDs for speed, HDDs for large capacity
  • Case & Size: From mini-towers to rack-mounted servers
  • Cables & NICs: Don’t underestimate good cabling and network cards
  • Rack (optional): For a neat, data center-like setup

You don’t need all of these at once. Start with the basics and upgrade step by step.

Storage: HDD, SSD, NVMe & RAID

Storage choices depend on your workload and budget. Here’s the quick map:

Drive Types

  • HDD (SATA): Cheapest per TB (2–16 TB), great for backups/media/archives. Slower I/O, but fine for cold data.

  • SSD (SATA): Big upgrade over HDDs for boot and VMs. Affordable, reliable, easy to add.

  • NVMe SSD (PCIe): Highest IOPS/lowest latency. Ideal for Kubernetes nodes, databases, CI runners, and logs.

RAID Basics (RAID ≠ Backup)

  • RAID 0 – Striping: fast, no redundancy. Use only for disposable/lab workloads.

  • RAID 1 – Mirroring: simple redundancy (50% capacity). Great for boot/critical services.

  • RAID 5/6 – Parity: balance of capacity + safety (3+/4+ disks). Good for NAS. Practical Picks

Always keep snapshots + off-box backups (another NAS or cloud/cold storage).

My First Step

In the beginning, the main reason I wanted to build a homelab was Kubernetes. I already had some experience with it at work, but I never had the chance to really dive deep or test things freely. In a team environment, it’s not a good idea to experiment, and in real production operations, you don’t just spin up a cluster and deploy apps for fun.

The real challenges happen when you operate it in real life:

  • How do you back up and restore?
  • What strategies do you use when a node crashes?
  • What happens when a service goes down?

This kind of experience can’t be gained just by reading tutorials - it requires real, hands-on practice to understand how everything works. That’s why I picked up the project “Kubernetes the Hard Way” and decided to try it out in my homelab.

Like many beginners, I started simple: with virtualization. The easiest option was to use a Type-2 hypervisor like VirtualBox or VMware to create virtual machines (master and worker nodes). It worked fine, but it depended on the host operating system and wasn’t stable for long-term use.

So I moved on to a Type-1 hypervisor: Proxmox. It’s popular, has great community support, plenty of guides, and includes all the features I needed.

Hypervisor-types

type
Click to zoom

For hardware, I used my old PC: a Dell Optiplex 9020 SFF (i3-8300, 8 GB RAM, 250 GB SSD, and 500 GB HDD). I installed Proxmox, practiced setting up Kubernetes, and deployed a few things. Then, for a while, I left it aside.

Image
Click to zoom
Later, another need appeared. My cloud storage subscriptions (MEGA and Google Drive) were expiring, and I realized my data wasn’t truly safe or under my control. That’s when I became interested in building my own NAS.

I created a VM and installed Xpenology as a NAS solution. It worked, but another issue quickly appeared: I hit the limits of my server.

  • My PC only had 2 RAM slots, which were already full.
  • Storage was limited: the small SFF case only had room for 1 HDD and 1 SSD.
  • To properly protect my data, I needed RAID, more storage, and more resources.

This was the moment I realized: it was time to upgrade my setup.

Choosing New Hardware

Of course, the choice wasn’t easy. There are many possible solutions, and it’s hard to pick the right one. My biggest advice is: know your real purpose before buying hardware. Trust me - I bought many devices that I didn’t actually use.

It’s like the CAP theorem in distributed systems: you can’t have a perfect solution; every choice has trade-offs. Here are some of the options I considered:

Image
Click to zoom

Old Enterprise Servers

  • Pros: Powerful specs with Xeon CPUs, lots of cores, ECC memory (e.g., dual 48-core CPUs, 128 GB RAM, etc.). Perfect for heavy workloads.
  • Cons: Power consumption. Running them 24/7 could increase my electricity bill by 300–500k VND/month.
  • Best use case: If you don’t need it on all the time and only power it up when you lab, this can still be a good choice.
    Image
    Click to zoom

Normal Tower PC

  • Pros: Flexible consumer-grade hardware. You can choose Intel or AMD, DDR4/DDR5 RAM, and even add a GPU for AI/ML workloads.
  • Cons: Takes up a lot of space (mATX/ATX cases). Limited disk slots (usually 4–6). Cooling isn’t always ideal for 24/7 workloads.

Mini PC

  • Pros: Small, efficient, and nowadays powerful enough to handle labs. Low power usage and very quiet.
  • Cons: Limited upgrade options. You can’t add a GPU, expansion cards, or many disks. Thermal management can also be a challenge.
    Image
    Click to zoom

Brand-Name Small Form Factor (HP/Dell/Lenovo)

  • Pros: Reliable, well-tested hardware with good quality components. Cheap and easy to buy secondhand. Community experience shows they can run 24/7 with low power usage. For me, this was the best option - I run mine 24/7 and it costs about 50k VND/month and has been rock-solid. If I want more nodes, I can simply buy another one.
  • Cons: Limited expandability (storage, slots). Proprietary parts sometimes make upgrades harder.

Mini Servers (Aoostar, MinisForum, etc.)

  • Pros: Purpose-built, compact servers with modern features.
  • Cons: Too expensive for my budget.
    Image
    Click to zoom
    In the end, the right choice depends on your use case. Do you want raw power, low electricity costs, or quiet always-on performance? Each option has strengths and weaknesses.

Other Devices

Along with servers, a homelab also needs supporting equipment:

  • Switches: Unmanaged (plug-and-play) or managed (VLANs, LACP, QoS). Speeds include 1 Gbps, 2.5 Gbps, and 10 Gbps.
    Image
    Click to zoom
  • Routers: ISP-provided routers are limited. Consider pfSense, OpenWrt, or RouterOS for advanced features like network-wide ad-blocking.
  • Firewalls: Essential for network security, either built into your router or run as a dedicated device.
  • Cables: Quality Ethernet (Cat6/Cat6a) prevents flaky performance.
  • Network Cards (NICs): Most SFF PCs come with a single LAN port. Add low-profile NICs for VLANs or multi-homing - but always check bracket size and form factor.

Goals of Your Homelab

Before building a homelab, it’s important to ask yourself: What do I want to achieve?

For me, the main goals were:

  • Learning & Practice: Experiment with Kubernetes, virtualization, and cloud-like infrastructure at home.
  • Self-Hosting: Run personal services such as a NAS, VPN, or even my own blog.
  • Experimentation: Try out tools before applying them in production at work.
  • Resilience: Learn how to deal with failures, backups, and recoveries.

Your goals might be different. Some people focus on networking, others on storage, or even running a smart home. The great thing about a homelab is that it can grow in the direction you want.

Network Design

Networking is one of the trickiest and most valuable parts of a homelab. It’s where you learn how everything talks to each other.
Here’s what I set up in my lab:

  • Router/Firewall: pfSense for firewall rules, VPN, and monitoring traffic.
  • Subnets: One network for management, one for services, and one for guests.
  • VLANs: To isolate workloads and practice segmentation.
  • VPN: So I can connect securely to my lab from anywhere.

My homelab network has two layers: the home LAN and the Kubernetes pod network.

  • ISP Router → Mesh Node 1 (DHCP 192.168.x.x)

    • Provides internet and Wi-Fi to family devices (via Mesh Node 2).
    • Also connects my Gaming PC and homelab servers.

  • Gaming PC

    • Fixed IP: 192.168.2.x
    • Connected to Mesh Node 1
    • Also directly linked via NIC to Server1 for lab testing

  • Server1 (Proxmox)

    • Fixed IP: 192.168.2.x
    • Runs VMs (IP range 192.168.2.100 – 192.168.2.150)
    • Hosts K8s master node, RouterOS, NAS, and core services

  • Server2 + Server3

    • Fixed IPs in 192.168.2.x
    • Kubernetes worker nodes

  • Kubernetes Pod Network

    • Pod IPs use the range 10.0.x.x (separate from LAN) This separation means my home devices stay on the normal 192.168.x.x LAN, while my Kubernetes pods run in their own 10.0.x.x network.

Software & Services

Once the hardware and network were in place, I started layering software on top. These were some of the key services I deployed in my homelab:

  • Kubernetes (K8s): The core of my experiments. Deployments, scaling, backups, and recovery taught me more than any tutorial.

  • Vault: Secret management for API keys, DB passwords, and certificates.

  • API Gateway: To control and route requests between services, including authentication and rate limiting.

  • GitLab: Self-hosted Git + CI/CD to mirror a real engineering workflow.

  • Cloudflare Zero Trust: Secure remote access without exposing ports to the internet.

  • Ansible & Terraform: Automating provisioning and configuration, reducing manual toil.

  • n8n: Workflow automation for event-driven tasks and integrations.

  • Kafka (test cluster): Exploring messaging, streaming, and decoupled services.

  • Database HA: Practicing clustering/failover patterns.

  • Load Balancing: HAProxy/NGINX experiments for L4/L7 traffic.

  • Monitoring Dashboard: Prometheus + Grafana to track system health, VM performance, and Kubernetes workloads.

  • Storage (NAS): Xpenology/TrueNAS for file sharing, backups, and image storage.

  • Custom Apps: A personal blog and cloned “production-like” architectures to practice.

  • Every new service I added made my homelab feel closer to production - but without the stress of real outages.

Challenges & Lessons Learned

Running a homelab wasn’t always smooth. The challenges became my best teachers.

Networking & DHCP

At first, I used my ISP router, which handed out IPs via DHCP. That meant every node or VM was on the same 192.168.x.x range.

It worked at first, but soon I faced NAT issues and IP conflicts. Cluster nodes, NAS, and servers would break connectivity - and, worse, it occasionally affected my family’s devices.

Lesson learned: I needed to plan a proper IP scheme. I designed fixed IP ranges for each zone:

  • Cluster Zone: Kubernetes nodes and services
  • Server Zone: Proxmox and supporting servers
  • NAS Zone: Storage devices and backups
  • Family Zone: Everyday household devices

This separation stopped conflicts and made the whole network easier to manage.

Device Compatibility

Not every piece of hardware worked as expected:

  • A Wi-Fi/Bluetooth card I bought turned out to be incompatible.
  • A NIC didn’t fit my Dell SFF case - a painful reminder that form factor matters.

Lesson learned: Always check compatibility (low-profile brackets, slot length/height) before buying, especially with SFF gear.

General Lessons

From these challenges, I picked up some important principles:

  • Plan your network design early.
  • Don’t skip backups.
  • Check compatibility before ordering hardware.
  • Buy gear for your actual goals, not just because it looks cool.
  • Remember: mistakes are part of the learning process.

Future Plans

A homelab is never finished. My next goals include:

  • Automation: Terraform + Ansible to manage infrastructure.
  • Multi-Node Kubernetes: Move from single-node experiments to a proper cluster.
  • Advanced Networking: Try Istio/Linkerd and hybrid designs.
  • Monitoring & Alerts: Add Alertmanager and SLO-style dashboards.
  • GPU Node for ML: Join my desktop to the cluster to run ML jobs.
  • Scaling Up: Add nodes or a rack for tidier, more efficient operation.

Suggested First Server: HP EliteDesk 800 G4/G5 SFF

If you’re looking for a reliable, accessible, and upgradeable starting point, consider the HP EliteDesk 800 G4 or G5 SFF.

Key Benefits:

  • Intel 8th/9th Gen CPUs: Efficient, multi-core processors widely available secondhand.
  • 4 RAM slots: Expand to 32–64 GB easily.
  • Multiple storage options:
    • 2 × NVMe slots for fast SSD boot and VM storage
    • 2 × 3.5" bays and 1 × 2.5" bay for HDDs/SSDs
  • PCIe expansion:
    • 2 × PCIe x1
    • 1 × PCIe x8
    • 1 × PCIe x16
      Plenty of room for NICs, GPUs, or add-ons.
  • Efficient and quiet: Great for 24/7 use without inflating your power bill.

Why It’s a Great First Pick:

  1. Balanced performance for virtualization and containers.
  2. Compact but expandable for future growth.
  3. Budget-friendly on the secondhand market.
  4. Popular with homelab builders = plenty of community guides.

Example Setup with HP 800 G4/G5 SFF

ComponentPurpose
ProcessorIntel Core i5/i7 (8th/9th Gen)
RAM32–64 GB DDR4 across 4 slots
Boot StorageNVMe SSD for OS and VM host
Bulk StorageHDDs in 3.5" bays or SSD in 2.5" bay
NICsExtra PCIe NIC for VLANs and servers
UpgradesGPU or add-on cards via x16 slot

Conclusion

  • My homelab started as a single SFF PC and grew into a personal playground where I could test without fear. It gave me practical skills and the confidence to tackle new technologies.

  • If you’ve got an old PC lying around, turn it on. Your homelab journey can start today. Start small, break things, fix them, and keep learning.

Useful Links

Comments

Loading comments...