From Beelink to Rack: What Building a Homelab Actually Taught Me

It started with a Beelink and a dream.

A tiny SER9 Pro, running Proxmox, hosting a few containers. Redis. Postgres. A reverse proxy. Pi-hole. Everything hummed along quietly on my desk, and I felt like I understood infrastructure.

Then I bought a 16-core Ryzen 9 beast, two 16TB enterprise drives, and a server rack.

Suddenly nothing worked.

The New Machine

HYDRA09 arrived in a Silverstone RM51 case that weighed more than my expectations.

The specs were ridiculous for a homelab:

• AMD Ryzen 9 7950X — 16 cores, 4.5GHz
• 64GB DDR5
• 3TB of NVMe across three drives
• 32TB of enterprise HDDs
• RTX 4090 — because eventually, local inference won

The plan was simple: add it to my existing Proxmox cluster, share storage across nodes, and run workloads that my little Beelink couldn't handle.

The reality: I spent three days debugging why a Pi-hole container couldn't reach the internet.

The Storage Question

Before I even got to networking, I had to figure out what to do with those two 16TB drives.

Everyone online has opinions about storage. ZFS evangelists. Unraid fans. TrueNAS purists. I just wanted something that wouldn't lose my data.

Here's what I learned:

RAID 5 requires at least three drives. I didn't know this. With only two drives, my options were RAID 1 (mirror) or RAID 0 (don't).

ZFS mirror gives you:

• 16TB usable from 32TB raw
• Checksums that detect bit rot
• Snapshots for free
• One drive can die and you keep everything

Unraid gives you:

• Flexible expansion — add drives of any size later
• Parity protection without striping
• Easier web UI
• But slower performance

I went with ZFS. Not because it's objectively better, but because I knew what I was optimizing for: reliability over flexibility. I wasn't planning to expand incrementally — I wanted a stable foundation.

zpool create tank mirror /dev/sda /dev/sdb

Two lines. 16TB of bulletproof storage. Done.

Lesson learned: Know what you're optimizing for before choosing tools. The "best" solution depends entirely on what you're willing to trade.

The Network Nightmare

With storage sorted, I moved my Pi-hole container from the Beelink to HYDRA09.

The old IP was 192.168.88.250 — directly on my LAN. The new IP would be 10.10.10.250 — on my internal homelab subnet, routed through MikroTik.

I updated the container config. Changed the IP. Started it up.

Nothing.

No internet. No DNS resolution. Couldn't even ping 8.8.8.8.

I ran the standard debugging checklist:

ip a                    # Interface up? ✓
ip route                # Gateway set? ✓
ping 10.10.10.1         # Can reach gateway? ...

The gateway ping failed.

So began three hours of staring at configs, questioning reality, and learning more about Linux networking than I ever wanted to know.

The First Culprit: Wrong Bridge

In Proxmox, containers connect to the network through bridges. My Beelink had vmbr0 configured for the 10.10.10.0/24 subnet. HYDRA09 was new — I hadn't set up the bridge correctly.

The container was assigned to a bridge that didn't exist. Or existed but wasn't connected to anything. Or was connected to the wrong interface.

I still don't fully remember which one it was. The point is: the container had a valid IP and gateway, but no actual path to the network.

Fix: Match the bridge config between nodes. Make sure vmbr0 on HYDRA09 actually routes to the same subnet as vmbr0 on Beelink.

# /etc/network/interfaces on HYDRA09
auto vmbr0
iface vmbr0 inet static
    address 10.10.10.9/24
    gateway 10.10.10.1
    bridge_ports enp3s0
    bridge_stp off
    bridge_fd 0

Container could now ping the gateway. Progress.

But still no internet.

The Second Culprit: Missing NAT

The 10.10.10.0/24 subnet is internal. It's not directly on my LAN — it's routed through MikroTik. For packets from that subnet to reach the internet, MikroTik needs to masquerade them.

I had set this up months ago for the Beelink. I assumed it would just work for HYDRA09.

It didn't.

Somewhere along the way, my NAT rule had gotten too specific, or FastTrack was eating packets before they hit the NAT chain.

The fix:

/ip firewall nat add chain=srcnat src-address=10.10.10.0/24 \
    out-interface-list=WAN action=masquerade

And disable FastTrack temporarily to confirm:

/ip firewall filter disable [find where action=fasttrack-connection]

Packets started flowing. Pi-hole could resolve DNS. I could breathe again.

Lesson learned: Networking breaks silently. Packets disappear without error messages. When nothing works, go back to basics: Can this host reach its gateway? Can the gateway reach the internet? Is something eating packets before they get where they need to go?

The Bridge Confusion

During all this debugging, I kept making the same conceptual mistake: thinking that creating a bridge meant connecting it.

In Proxmox, you can create vmbr1 with a few lines of config. You can assign an IP to it. You can point containers at it.

But none of that means the bridge actually goes anywhere.

A bridge is just a virtual switch. For it to be useful, you need:

• A physical interface attached (or a route configured)
• Proper IP addressing on the same subnet as your router expects
• NAT or routing rules if the subnet is isolated
• Firewall rules that allow traffic through

I had been treating bridges like magic tunnels. They're not. They're just switches. Switches need to be plugged into something.

The irony: my original setup on Beelink worked without a proper bridge. I had assigned the IP directly to eth0, and containers connected through that. It was "wrong" by Proxmox standards, but it worked.

Sometimes the "proper" way isn't the right way. At least not until you understand why it's proper.

What I Actually Learned

I didn't set out to learn networking. I set out to run containers.

But homelabs don't teach you infrastructure. They teach you debugging.

Every hour I spent tracing packets through MikroTik, every config file I rewrote, every moment of "why won't this just work" — that's the education. Not the YouTube tutorials. Not the documentation. The breaking.

Here's what stuck:

Device names are cosmetic. nvme0n1 vs nvme1n1 depends on kernel enumeration order, not physical slots. Use UUIDs in your configs.

FastTrack is a silent killer. MikroTik's FastTrack accelerates traffic by bypassing firewall rules. Great for performance. Terrible when you're debugging why packets vanish.

Bridges aren't magic. They're virtual switches. They need to be connected to something real.

NAT rules need to match your topology. If you add a new subnet, you need to tell your router about it. Explicitly.

Error messages lie. Or rather, they tell you what failed, not why. The only source of truth is the packet itself. tcpdump is your friend.

The Takeaway

My homelab now has two Proxmox nodes, a ZFS storage pool, proper network segmentation, and a Pi-hole that actually resolves DNS.

But the real value isn't the infrastructure. It's the intuition.

When something breaks at work now, I don't panic. I check the basics. I trace the path. I assume nothing is connected until I prove it is.

That's what homelabs actually teach you:

Start small. Break things intentionally. Fix them until you understand.

That's the only way infrastructure knowledge sticks.