Home IT Lab & Self-Hosted Infrastructure

Why I maintain a home lab

The lab is where I practice the parts of IT and application support that are difficult to learn from a diagram alone: hardware changes, Linux administration, virtualization, network services, shared storage, backups, migrations, service recovery, and the operational tradeoffs of keeping multiple applications running together.

It is an evolving environment rather than a frozen product. I use it to test architectures, recover from mistakes, document repeatable procedures, and understand how application behavior changes when storage, networking, compute, or access layers fail.

Architecture principle

My documented design separates three responsibilities: persistent storage and backend services, virtualization and compute, and small infrastructure services. That makes it easier to change applications without coupling every experiment to the NAS or the network layer.

Practical work represented in the lab

• Proxmox VM and LXC lifecycle management
• Unraid storage, shared data, and application data placement
• NFS mounts between compute and storage systems
• Docker and service isolation
• Backup, restore, migration, and recovery exercises
• DNS, reverse proxy, remote-access, and internal service routing
• Media, photo, automation, and AI-oriented self-hosted workloads
• GPU passthrough and acceleration experiments where appropriate
• Monitoring and troubleshooting across host, guest, storage, and network layers

A design rule I keep returning to

The hypervisor should stay boring. Applications belong in isolated guests; persistent data should have a clear home; infrastructure should remain small enough to recover independently.

What is deliberately not claimed

The service list changes frequently. The diagram describes the architectural separation I use and have documented; it does not imply that every service I have evaluated or planned is permanently deployed at the same time.