Overview
A useful homelab is the best learning environment a security professional can have, and the right answer to "what should I learn on" if you are early in your career or moving into a new area. The constraint is usually budget, and the goal is usually not the equipment; the goal is the muscle memory of running real infrastructure and the judgment that comes from breaking it.
What makes a homelab useful is not the gear, it is the operating discipline. A $300 box running OPNsense, two VLANs, a small cluster of VMs, and a documented topology you can rebuild from a checklist is more useful than a $3,000 rack with no documentation and no isolation from the main network. The expensive setup that lives on a shelf is decoration; the cheap setup that you actually use is a tool.
This article is the build I would recommend today with a hard ceiling of around $600 for the initial setup, plus a recurring monthly cost for an internet connection that you are willing to treat as a learning environment. The numbers are calibrated to the used market in North America in the 2024-2026 window and will drift with hardware pricing; the architecture and the operating discipline are the part that does not move.
How it works
A homelab has five logical components, and the budget allocation is roughly proportional to how much each one matters for the learning outcome. Compute is where the work happens; a single mini PC is enough to start, two nodes is the right answer once you want to learn clustering or run a hypervisor that can survive a host failure. Network is the part most beginners under-invest in; a dedicated firewall appliance or a mini PC running OPNsense or pfSense gives you a real router to learn on, which is one of the highest-leverage skills in the field. Storage is the part most beginners over-invest in; an SSD for boot and a single large HDD for bulk storage is the right starting point. The management plane is the tools you use to operate the lab (a jump host, a documentation repo, a monitoring stack), and the off-host backup is the part that nobody adds until they have lost something and regret it.
The compute node is a used business-class mini PC or thin client. The right model depends on what is available locally, but the target is: a recent-generation Intel or AMD CPU with at least 4 cores, 16 GB of RAM (32 GB if you can stretch the budget), an NVMe slot for boot, and at least one SATA or NVMe slot for storage. The Lenovo ThinkCentre Tiny series, the HP ProDesk/EliteDesk Mini series, and the Dell OptiPlex Micro series are all over the used market at $80-$200 each. Avoid consumer-grade all-in-ones and laptops; the thermals and the expandability are wrong for a 24/7 workload.
The network is the part that teaches the most. A mini PC with two Intel NICs running OPNsense (free, open source, a real router OS, not a toy) gives you a real firewall, real VLAN support, real DHCP and DNS services, and a real place to learn the protocols. The alternative is a used enterprise firewall (a Fortigate, a Palo Alto, a SonicWall from a refurbisher) but those have licensing costs and the operational model is opaque; the OPNsense path teaches you more for less money.
Storage is a single SSD for the hypervisor boot and a single large HDD for bulk storage, both in the compute node or in a separate NAS if you want to learn NAS-style storage. A 500 GB NVMe boot drive and a 4-8 TB surveillance-rated HDD is a reasonable starting configuration; the HDD is rated for 24/7 spin, which the compute drive is not. Do not invest in a RAID array until you have a reason to (a reason is "I am running critical stateful services that I cannot afford to rebuild"); the operational cost of RAID is real and the learning value is low until you actually have the workloads.
In practice
The under-$600 build, component by component, calibrated to the 2024-2026 used market. Prices will move, treat them as a sanity check rather than gospel. Two used business-class mini PCs at $120 each ($240). One is the compute node, the other is the firewall; one more is the high-water mark. A 500 GB NVMe SSD ($30 used, $50 new). A 4 TB surveillance-rated HDD ($60-80 used). An unmanaged gigabit switch ($25). Two Cat6 patch cables and one longer Cat6 run to your internet connection ($15). A small used UPS ($40-60). The total lands around $410-$470 for the hardware; the rest of the budget goes to incidentals (an extra NIC if the firewall mini PC only has one, a USB drive for OPNsense installation media, the cables you forgot).
The software stack is the part that does the teaching. OPNsense on the firewall node for routing, firewalling, DHCP, DNS, and VLANs. Proxmox VE on the compute node for the hypervisor (free, well-documented, supports clustering, supports ZFS, supports GPU passthrough, supports live migration). A handful of VMs to actually run: a Linux VM for general tinkering, a Windows VM for Active Directory experiments, a small Debian VM as a jump host with Tailscale or WireGuard for remote access, and a pihole or AdGuard Home VM for DNS-level ad blocking in the lab. The point is not the specific software; the point is that you have a real network, a real firewall, real VMs, and a real set of services you can break and rebuild.
The architecture that holds up: the firewall is the gateway. It has two interfaces, one to your main network (or directly to the internet if you are brave) and one to the lab network. The lab network is its own subnet, its own VLAN, with no route to anything on your main network except what you explicitly allow. The compute node sits on the lab network and runs Proxmox. The VMs run on Proxmox and connect to the lab network. Remote access is via Tailscale or WireGuard, not via a public IP; you do not expose the lab to the internet unless you have a specific reason to, and the specific reason is usually a CTF or a deliberately vulnerable target like HackTheBox or VulnHub.
Documentation is the cheap thing that you will not do and will regret not doing. The right starting point is a single markdown file (or a Notion page, or an Obsidian vault, depending on your preference) with the network topology, the IP ranges, the MAC addresses of each interface, the credentials (or, better, the location of the credentials in your password manager), and the procedure for rebuilding the firewall from scratch. The procedure is the part that matters; it is what you reach for when something is broken at 11pm and you need to recover.
Common mistakes
The most common mistake is treating the homelab as a thing to show off rather than a thing to use. The aesthetic of a homelab (the rack, the labels, the cable management, the blinking lights) is satisfying but it is not the goal. The goal is the operational knowledge that comes from running a real network and a real set of services. A $300 setup that you actually use beats a $3,000 setup that you look at.
The second is exposing the lab to the internet. The temptation is real (you want to test things against real internet traffic, you want to host something, you want to learn about public-facing services), but the security cost is also real. A homelab that is exposed to the internet will be attacked within hours, often by automated scanners that are looking for exactly the kind of misconfigured services a homelab tends to run. The right answer for remote access is a VPN (Tailscale is the easiest, WireGuard is the right answer if you want to learn the protocol), not a public IP. The right answer for hosting a public service is to pay a real cloud provider $5/month, not to expose your lab.
The third is using the lab as a place to test real things with real credentials. The lab is not a sandbox if it has your real email password, your real banking credentials, or your real API keys. Use the lab for fake credentials that look like real ones (a Stripe test key, a sandbox API token, a password that matches your real password length and complexity but is for a service that does not exist). The reason is that a homelab is a place where mistakes happen, and mistakes that involve real credentials are expensive.
The fourth is not backing up the configuration. The compute node will eventually fail (the SSD will die, the PSU will die, the OS will get corrupted by an aborted update), and the question is whether you can rebuild it from your documentation in an evening or whether you lose a weekend. The right answer is: document the configuration in a way that lives outside the lab (a git repo on your main machine, or a private GitHub repo, or an Obsidian vault synced to the cloud), and back up the data that matters (the VMs that you do not want to rebuild, the database state, the certificate keys) to a separate physical location (an external drive, a cloud backup, or a friend's house if you have that kind of friend).
The fifth is not treating the lab as an environment that has its own security posture. The lab is a network with real vulnerabilities and real attack surface, and if it can reach your main network, your main network has the same attack surface as the lab. The lab should be isolated from the main network (its own VLAN, no route to the main network unless you explicitly need it, and the route should be denied by default and only allowed for specific services on a case-by-case basis). The lab should also have its own monitoring (a simple syslog server, or a small Wazuh/Suricata deployment if you want to learn detection engineering), because the lab is where you will see real attacks against your own services first.
Defensive guidance
Treat the lab as a small production environment, not as a toy. That means: change default credentials, keep the OS patched, document what is running and why, and review the access controls the same way you would for a real service. The lab is the best place to learn the discipline of running a real environment, and the discipline you build there is the discipline you bring to your real work.
Isolate the lab from your main network. The lab should have its own subnet, its own VLAN, its own firewall, and no route to the main network unless you explicitly need one. The exception is for specific services that you want to be able to reach from the main network (a VPN endpoint, a development VM that you want to access from your laptop), and even those should be allow-listed rather than blanket-permitted.
Use a VPN for remote access, not a public IP. Tailscale is the easiest (it is a managed WireGuard mesh that handles the key exchange for you); WireGuard is the right answer if you want to learn the protocol and you do not mind doing the key exchange by hand. The wrong answer is exposing SSH, RDP, or a web UI to the public internet, even on a non-standard port. The wrong answer is also UPnP, which opens ports dynamically and is a security nightmare on a homelab.
Use the lab to learn the discipline that is hard to learn from tutorials. Backups, change management, access reviews, incident response, monitoring, logging, capacity planning: all of these are things you can practice in a homelab at low cost, and the muscle memory is the thing that translates to real work. The right way to use a homelab is to run real services on it, break them on purpose, fix them on purpose, and document the whole thing.
Do not let the lab become an entry point into the rest of your network. The most common homelab-to-main-network compromise is a service on the lab that has a vulnerability, an attacker that exploits the vulnerability, and a default route from the lab to the main network that the attacker uses to pivot. The fix is the firewall policy: no route from the lab to the main network unless you have explicitly allowed it, and the allow should be specific (this lab VM can reach that main-network host on that specific port for that specific reason). The fix is also monitoring: you should know when the lab talks to the main network, and you should be alerted when the lab talks to the main network in a way you did not expect.