Home Lab Foundations

For a home lab, I would start with one stable virtualization host, an understandable network, and notes that survive the machine being rebuilt. This is a starting architecture, not a shopping list or a claim that every tool below has been retested on its latest release.

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

Why I Usually Start With Proxmox

Proxmox VE provides KVM virtual machines, LXC containers, networking, and backup facilities. I like that combination for a disposable lab. A single host keeps the initial recovery and networking problems small enough to understand.

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
• an isolated test subnet with no route to personal devices; live malware work needs additional containment beyond a VLAN

Hardware That Does Not Waste Your Time

For several concurrent VMs, this is an illustrative capacity target. Size it from your actual workloads before buying hardware:

• 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, isolated 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. That gives the container workload a separate operating system and recovery boundary.

Follow the current Docker installation instructions for the guest distribution you choose. I removed the old convenience-script and unpinned Portainer command from this note: it obscured the version being installed and exposed an administrative interface without explaining its access boundary.

If you add a container-management UI, keep it on the management network and pin the version you have reviewed. Access to the Docker daemon is powerful host access. Docker's security documentation explains why control of that interface needs particular care. Mounting its socket into another container extends that trust to the container.

Updates

Keep an inventory of versions and a simple update procedure: save configuration, confirm a usable backup, update a small group, and check the service from a client. A disposable application and the logging service used to understand its failures should not necessarily update together.

Automatic updates can be appropriate for a throwaway experiment, but first decide how you will identify the changed version and restore the prior one. The old updater example has been removed because a scheduled container replacement alone did not establish either of those controls.

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

In the original January 2025 account, 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 was my experience at the time, not a current assessment of its signing or distribution policy. Check the project's current requirements before basing a new deployment on that old note.

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

Make Recovery Part Of The Experiment

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.

Before adding another service, restore one existing VM into an isolated network and check its configuration, data, and access controls. That exercise will tell you more about the lab's foundations than another dashboard.