← Back to Terminal & Ward

Home Lab

Home lab builds and self-hosting tutorials: what's actually worth running yourself, and what to skip.

The Starter Stack

Pick what you actually want out of a home lab, and get three things worth running first, not the sprawling forty-container stack you'll see in someone else's screenshot.

Pick a category above to see where to start.

A Home Lab Is a Hobby With Uptime Requirements

The difference between a home lab and just "some computers in a closet" is intent: you're running services other people, including past-you, actually depend on. That changes the calculus. A tinkering project can break at 2am and nobody notices. A home lab that's quietly become your DNS server, your photo backup, and your password manager cannot. The fun part and the responsible part end up being the same part.

Start With One Box, Not a Rack

The rack, the UPS, the color-coded cabling: that's all endgame, not a starting point. A single mini PC or even an old laptop running two or three services teaches you almost everything the eventual rack will, at a fraction of the cost and none of the noise. Buy the second box once the first one is actually full, not before.

Docker Compose Before Kubernetes

Kubernetes solves problems you don't have yet, like orchestrating dozens of services across multiple machines with automatic failover. A home lab has neither the scale nor the uptime requirements to justify that complexity. Docker Compose gets you 90% of the benefit (reproducible, version-controlled services) for a fraction of the learning curve. Graduate to Kubernetes if you ever actually hit its ceiling, not because a YouTube thumbnail said you should.

Backups Are the Actual Hard Part

Anyone can spin up a service. Far fewer people can restore one from a backup they've actually tested, under pressure, at the moment it matters. If a service holds anything you'd be upset to lose (photos, documents, passwords), it needs an automated backup running somewhere physically separate from the box itself, and a restore test on your calendar, not just your intentions.

Knowing When to Stop Adding Services

Every self-hosted service is a small, ongoing maintenance commitment: updates, security patches, the occasional broken container after an upgrade. The question isn't "can I self-host this," it's "do I actually want to be the one responsible for it working." A lab with five services you maintain well beats one with twenty-five you've quietly stopped updating.

Related Tool

Subnet / CIDR Calculator →

Segmenting your lab network from the rest of the house starts with knowing the ranges involved.

← Back to Terminal & Ward