Homelabs, self-hosting, and doing whatever the fsck you want.

February 12, 2026

“Homelab” is one of those worlds that mean everything and nothing at the same time.

Depending on who you ask, it’s one of these:

• A rack of retired enterprise gear in a basement
• A single mini-PC running Docker
• A media server with ambition - and probably a storage array
• A philosophical commitment to independence

The same drift has taken place with “self-hosting.” For some, it only counts if the hardware is physically located in your home. For others, a VPS you manage yourself qualifies just as well.

Over time, the conversation has shifted from outcomes to optics, and maybe even a bit of virtue signaling thrown in - hardware size, power consumption, or where the bits physically live - and that seems to contradict the general idea of the technology itself: to solve problems (while re-introducing just enough to warrant upgrades.)

Geography and the Unnecessary Purity Test

“If it’s not running on hardware you own, in your home, it’s not self-hosted.” This framing focuses entirely on geography - which has absolutely nothing to do with responsibility. It also unfairly gatekeeps interest for those who may not have the abilities to run equipment where they live, and for a gamut of reasons that have no impact on the outcomes their setup delivers. Stop.

If you rent a VM from a provider and they guarantee uptime at the hypervisor layer, but you’re responsible for:

• OS patching
• Firewall configurations
• Backups
• Application updates
• Monitoring
• Incident response

…then functionally, you are operating that system. The power supply might not connect to a breaker you can get your hands on, but the blast radius is still yours - and that matters much more than your gear and home sharing a zip code.

My Start: Slackware and an NEC PowerMate

My Homelab journey began in the late 1990s with a secondhand NEC PowerMate running Slackware on a 233MHZ Pentium II with 32MB of RAM. It ran DNS and other network services I wanted to learn about, gave me my first taste of Nano and Midnight Commander, and mostly failed because I spent more time breaking things than running them.

By the time I got an HP NetServer to run Windows NT4 Server, my focus shifted from tinkering to understanding operational responsibility - patching, backups, and recovery became lessons in accountability rather than just “making things run.” A Better Threshold: Operational Responsibility

Instead of asking, “where is it running?” ask:

• Who is responsible when it breaks?
• Who is responsible when it’s compromised?

Self-hosting begins when you assume operational responsibility for availability, security, updates, data protection, recovery, and monitoring. If someone else owns those layers, you’re consuming a service. If you own them, you’re operating one. That’s the threshold.

The Responsibility Matrix

Matrices are often used to illustrate areas of responsibility in IT, so let’s make one:

Level	Environment	Hardware Owner	OS & Services	Backups & Recovery	Notes
0	Saas	Vendor	You	Vendor	You configure settings. Everything else is handled exernally
1	Hosted Platform	Vendor	You (apps)	Vendor	You control the apps
2	VPS/Cloud VM	Provider	You	You	You Manage OS, firewall, updates, backup, monitoring. Provider guarantees compute availability.
3a	Full Stack Homelab	You	You	You	Experimental learning environment. Operational responsibility is assumed intentionally for learning.
3b	Full Stack Production/Critical	You	You	You	Systems that directly affect daily workflow or personal business. Not a Homelab-production infrastructure.

• Levels 2 and 3 both count as self-hosting, but level 3a is a lab environment whereas 3b is production.
• The distinction isn’t hardware ownership – it’s intentional responsibility and purpose
• Media servers or automation systems can exist at any level, but unless you’re learning from operational responsibility, they don’t constitute a lab

Defining Homelab

A Homelab is not defined by rack depth, power consumption, or resale value on eBay. A Homelab is an intentional environment where you assume operational responsibility to develop skill. It may live:

• On a small server in your office
• On a clustered hypervisor stack
• On a handful of VPS instances
• In some hybrid combination

The location is secondary – intent and discipline are really what matter. A real Homelab mirrors production patterns in some form and forces you to think about:

• Network segmentation
• Access control
• Backup strategy
• Failure scenarios
• Documentation
• Secure remote access

It breaks, gets rebuilt, and evolves - in the process - as you learn. If it doesn’t push you to understand how and why something works, or doesn’t work, it’s not a lab - it’s just infrastructure.

Examples from My Network

My 3-node Proxmox cluster, backup server, and Raspberry Pi lab nodes (Microlab 2) are all Level 3a - they’re meant for learning, experimentation, and safely breaking things.

My inference system, Synology storage, and 45 Drives Pro 4 backup server are Level 3b - production responsibility where downtime or misconfiguration would directly affect my personal and professional work.

Veering from Homelab Territory

A Homelab is not:

• A justification for overspending on hardware
• A contest to see who can idle the most cores
• A rack at 8% utilization
• A collection of services you never patch

Self-hosting media servers or automation is great- but the primary purpose matters. If your goal is convenience or entertainment, that’s valid, but it’s not a Homelab unless you’re also learning operational responsibility. A lab implies experimentation, iteration, and measurable growth, not planned trips to buy more RAM.

The Distinction Matters Well Beyond a Label

Loose definitions create poor habits. People overbuild because they assume scale equals legitimacy. They expose services to the Internet because “it’s just a Homelab.” And skip backups because “it’s not production.”

The moment you rely on what you’ve brought online – for authentication, storage, identity, or communication – it becomes production for you… and production has consequences. Having clear definitions shift focus from ego to engineering, hardware to responsibility, and purity tests to skill development

The Homelab Smell Test

Ask yourself:

1. If this system failed tomorrow, could I restore it?
2. If it were compromised, would I detect it?
3. Do I understand its security model?
4. Can I rebuild it from documentation?

Most Importantly – am I comfortable owning the outcome if something goes wrong? If yes, you’re operating. If no; you’re consuming. Both are valid, but not the same.

Final Thoughts

Owning hardware doesn’t automatically make you disciplined - there’s a ton of gym equipment collecting dust in my basement that proves the point. At the same time, renting infrastructure doesn’t automatically make you less serious. Self-hosting begins when you accept operational responsibility. A Homelab begins when that responsibility is assumed intentionally for learning and growth.

The goal isn’t absolute control - it’s informed control. Sometimes, the smartest decision is not to bring another service online, but to understand exactly what responsibility entails before doing so.

From a 233MHz NEC PowerMate in the late ‘90s to a modern Proxmox cluster and my Microlabs, the evolution of my Homelab has always been about learning operational responsibility, not just owning hardware. Media servers, automation, or convenience systems may compliment a network, but true lab is where experimentation, iteration, and risk teach lessons that directly translate into professional infrastructure management.