Home Lab Foundations

A home lab gets complicated surprisingly quickly. A few VMs become a dependency chain: DNS lives in one guest, monitoring in another, and the notes for fixing both are on a service that also needs the host to be running.

For a first build, I'd spend more time on that recovery problem than on choosing a second node. Enough memory, a separate backup target, and a network layout you understand will support a lot of useful work.

One host is enough to begin

I like Proxmox VE for a lab because it puts KVM VMs, LXC containers, networking, and backup facilities in one place. You can build a Windows test domain, try a logging stack, or throw away a broken Linux guest without rebuilding the host.

An 8-core system with 64 GB of RAM and 1 TB of NVMe storage is one reasonable planning example for several concurrent guests, with separate storage for recovery copies. It isn't a shopping requirement. Add up the memory and disk space for the workloads you actually want to run, leave room for the host, and expand when those workloads justify it.

For an initial split, I'd use something like:

Proxmox Host
+-- Docker VM: 6 vCPU, 16 GB RAM
|   +-- Small applications and test services
+-- Monitoring VM: 4 vCPU, 8 GB RAM
|   +-- Metrics, logs, detection experiments
+-- Automation LXC: 2 vCPU, 4 GB RAM
|   +-- Ansible and maintenance scripts
+-- Disposable Test VMs
    +-- Separate networks for each experiment

The vCPU assignments can exceed the host's physical core count, so concurrent demand still matters. A quiet application and a busy indexing job don't consume their allocations in the same way. Watch the actual contention before adding more guests.

A cluster makes sense when you want to study migration, quorum, or failover. Those are worthwhile experiments, but they bring their own failure cases. I wouldn't add three nodes merely to run a handful of services that fit on one.

Give Docker its own guest

Putting Docker inside a VM keeps application changes out of the hypervisor's operating system. If a container experiment damages the guest, you can restore or replace that VM while keeping the host available.

Use the installation instructions for the guest distribution and record the installed version. Pin application versions you care about. A compose file using latest doesn't tell you what you'll get when you rebuild it next month.

Be careful with management interfaces and the Docker socket. Access to the daemon can provide extensive control over the guest; mounting that socket into a container gives that container a powerful interface. Docker's security documentation explains the implications. Keep management access limited to the machines and identities that need it.

Make the network do less by default

A disposable test VM shouldn't be able to reach a family laptop just because both are at home. Separate management, ordinary services, and experiments, then allow the connections each needs.

One possible VLAN layout is:

10 Management   Proxmox, switch, access-point management
20 Servers      Application VMs and internal services
30 Monitoring   Logs and metrics
40 IoT          Cameras, TVs, and other appliances
50 Guest        Visitor devices
60 Lab          Disposable experiments

The numbers are arbitrary. The firewall policy is what creates the separation. Start with inter-VLAN traffic denied and add required flows, including DNS, time synchronization, updates, and log delivery. Check access from each network after applying the rules. A guest that cannot open the management UI may still reach a different administrative port you forgot about.

Keep a working route to the management network while changing it. Losing access to the switch and hypervisor in the same change is an unpleasant way to discover that your recovery notes are online only.

A VLAN by itself is insufficient containment for live malware work. That requires a separate design for the host, network, storage, and anything the experiment could reach. The disposable environments above are a starting point for ordinary infrastructure and security exercises.

Back up enough to rebuild

A snapshot is useful when an update fails. It won't help if the disk holding both the VM and its snapshots is lost. Keep recovery copies on a separate target and include the configuration around the guests: VM definitions, compose files, playbooks, and firewall and switch settings.

Write down the small exceptions too. A manually changed mount, an unusual UID mapping, or a one-off network fix can consume more recovery time than restoring the disk image.

Test a restore onto an isolated network so the restored machine doesn't collide with the original. Check its data, application startup, credentials, and scheduled jobs. Keep the recovery instructions somewhere you can read with the lab host switched off.

Add monitoring you can verify

Begin with host memory, disk space, temperatures, VM availability, and logs from the systems you're experimenting with. Add a detection stack when learning that stack is part of the work. Running several at once can use up the resources you needed for the experiment itself.

Generate a harmless event and follow it to the destination. A failed login should arrive with the right host identity and timestamp. When it doesn't, work through collection and forwarding before changing the detection rule.

Keep monitoring on a different update schedule from the workload it observes. If both break together, you lose useful context. Save configuration and check backups before updates, then verify the service from a client afterward.

Ansible is enough to start making guest configuration repeatable. I'd automate the baseline machine setup, agents, updates, and teardown before adding a scheduling UI. The payoff is being willing to discard a broken test VM because recreating it is routine.

One tool that cost me time

When I tried TacticalRMM in January 2025, I came away disappointed with how gated and unclear the Linux and macOS agent-signing requirements felt.

If you're considering it, check the current signing and distribution requirements early. My experience was with that January setup; the practical lesson is to settle the endpoint requirements before spending an evening on DNS and deployment files.

The next addition to a lab doesn't always need to be hardware. Restoring one VM, fixing one overly broad firewall rule, or turning a manual setup into a playbook can make every later experiment easier.