Home Lab Foundations

I get asked about home labs a lot. My answer is usually less exciting than people expect: start with one stable virtualization host, keep the network understandable, and document what you changed.

The lab should make experiments cheap. It should not become a second job.

Why I Usually Start With Proxmox

Proxmox VE is a good foundation because it gives you full VMs, LXC containers, snapshots, backups, VLAN-aware networking, and a usable web UI without a licensing fight. Underneath, it is Debian, KVM, and LXC. That makes it easy to troubleshoot when something breaks.

For security work, the important part is not the UI. It is the ability to spin up disposable environments:

• a Windows test domain
• a Linux logging stack
• a vulnerable app network
• an EDR or SIEM trial
• a malware-analysis subnet with no route to the rest of the house

Hardware That Does Not Waste Your Time

You can start smaller, but this is the point where the lab stops feeling cramped:

• 8-core CPU
• 64 GB RAM
• 1 TB NVMe for active workloads
• separate bulk storage for ISOs, backups, and snapshots
• at least 1 GbE networking

If you want to run several Windows VMs, memory matters more than people think. If you want to test storage, backups, or monitoring, disk layout matters more than CPU.

A Simple Layout

This is the kind of split I would use before adding anything fancy:

Proxmox Host
+-- Docker VM
|   +-- 6 vCPU
|   +-- 16 GB RAM
|   +-- Portainer, small apps, test services
+-- Monitoring VM
|   +-- 4 vCPU
|   +-- 8 GB RAM
|   +-- Grafana, InfluxDB, Wazuh or equivalent
+-- Automation LXC
|   +-- 2 vCPU
|   +-- 4 GB RAM
|   +-- Ansible, Semaphore, scripts
+-- Disposable Test VMs
    +-- short-lived experiments, malware-safe networks, vendor trials

Do not build a cluster until you know why you need one. A single reliable node teaches more than three fragile ones.

Docker Host

I like putting Docker inside a VM instead of directly on the Proxmox host. It keeps the hypervisor boring.

sudo apt update
sudo apt upgrade -y

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker "$USER"

docker volume create portainer_data
docker run -d \
  --name portainer \
  --restart=always \
  -p 9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

Portainer is not required, but it is useful when you are juggling experiments and want a quick view of what is running.

Updates

Watchtower can be useful, but I do not let it update everything blindly. Auto-updating internet-facing services without a rollback plan is how a lab becomes a troubleshooting exercise at midnight.

Use labels or separate compose files so you can choose what updates automatically:

services:
  watchtower:
    image: containrrr/watchtower
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --label-enable --cleanup --schedule "0 0 4 * * *"

Monitoring

Grafana plus a metrics backend is enough for most labs. If you are learning detection engineering, add Wazuh, Security Onion, or another stack you actually plan to use.

Track the basics first:

• host CPU, memory, disk, and temperature
• VM uptime and resource use
• network throughput by VLAN
• failed logins
• suspicious process or file events on test machines

The goal is to learn how telemetry behaves, not to make a dashboard wall.

Network Segmentation

A home lab should not share one flat network with laptops, phones, IoT devices, and test malware.

My baseline VLAN split:

10 Management   Proxmox, switch, AP management
20 Servers      Docker hosts, internal services
30 Monitoring   SIEM, logs, metrics
40 IoT          TVs, cameras, smart devices
50 Guest        untrusted clients
60 Lab          disposable experiments

Default deny between VLANs. Open only what you can explain.

Backups

Snapshots are not backups. They are convenient rollback points.

Use Proxmox Backup Server or another real backup target, and test restores. Back up:

• VM definitions
• important volumes
• compose files
• Ansible playbooks
• firewall and switch configs
• notes about weird one-off fixes

If you cannot rebuild the lab from notes, the lab is undocumented infrastructure.

Automation

Ansible is enough for most home labs. Semaphore is a decent web UI if you want to run playbooks without SSHing into a control node every time.

The highest-value playbooks are boring:

• create a baseline Linux VM
• install security agents
• rotate test credentials
• apply OS updates
• collect logs
• shut down disposable environments

TacticalRMM Note

I tried TacticalRMM and came away disappointed. The Linux and macOS agent signing story felt more gated and less clearly documented than I expected. If you are evaluating it, check the agent signing requirements before you spend time on DNS, compose files, and deployment prep.

That may not matter for your lab. It mattered for mine.

What To Avoid

• exposing lab services to the internet because it is convenient
• putting secrets in compose files
• running everything as latest
• mixing malware tests with personal devices
• treating a lab SIEM as proof of production readiness
• buying more hardware before fixing the network and backups

The Point

A good home lab gives you a place to be wrong cheaply. Build it so you can break things, restore them, and understand what happened.

Start small. Keep the host stable. Segment the network. Write down changes. Add tools only when they answer a question you actually have.