When I built my homelab, security was an afterthought. I had a Proxmox host, a 24-port switch, and an itchy trigger finger for new containers. Six months later, I was running 40 services behind a single reverse proxy. My “lab” had become a public-facing server with my home address attached to a DNS record.
That is the moment many homelabs stop being harmless experiments. Once a service is exposed to the internet, it becomes part of the public attack surface. The hardware may sit in a spare room, but the network is no longer private.
A single vulnerability in the reverse proxy, a management interface, or one exposed application could provide an attacker with a path to many other services. The goal is not to build an impenetrable network. The goal is to limit what happens when one component fails.
The good news is that securing a homelab does not require a corporate security budget. It requires realistic priorities, a clear threat model, and a willingness to make the network boring.
Small Networks Are Still Targets
A common assumption is that attackers ignore residential IP addresses because they are not valuable. Automated scanners do not make that distinction. Services such as Shodan and Censys continuously index exposed systems, while opportunistic scans reach public addresses without any knowledge of who owns them.
I learned this the uncomfortable way. My first setup placed everything on the same flat network: personal computers, cameras, hypervisor management, test containers, and internet-facing applications. Nothing catastrophic happened, but the layout meant that one compromised service could potentially reach almost everything else.
The problem was not that every service was vulnerable. The problem was that I had made trust the default.
Start With a Threat Model
Before changing firewall rules, decide what you are protecting and from whom.
For most homelabs, the realistic threats include:
- Automated internet scans and brute-force attempts
- Vulnerable or abandoned applications
- A compromised container or virtual machine
- Malicious or infected devices on the local network
- Accidental exposure caused by port forwarding or UPnP
- Lost credentials, leaked API keys, or stolen backups
This model does not need to be formal. It simply helps distinguish important controls from security theater. Protecting the Proxmox management interface is usually more valuable than hiding the exact version of a low-risk internal dashboard.
Segment the Network With VLANs
The first major improvement I made was replacing the flat network with separate zones. VLANs are not magic security boundaries, but they create useful barriers and make access decisions explicit.
A practical layout might include:
- **Management:** hypervisors, switches, routers, and administration tools
- **Servers:** internal applications and databases
- **DMZ:** services that must be reachable from the internet
- **IoT:** cameras, televisions, and other low-trust devices
- **Clients:** laptops, phones, and personal workstations
- **Guest:** devices that should receive internet access only
The important part is not the number of VLANs. It is the policy between them. A web server in the DMZ should not be able to initiate connections to the management VLAN. An IoT camera should not need access to a database. A guest device should not be able to scan the server network.
Start with deny-by-default rules between zones, then add only the traffic that is required. Document those exceptions. If you cannot explain why a rule exists, it probably deserves another look.
Keep Management Off the Internet
Hypervisor panels, router interfaces, switch administration pages, SSH, and database ports should not be publicly exposed. Restrict them to the management VLAN or make them reachable through a VPN.
A VPN is preferable to opening several administration ports, but it still needs protection. Use strong authentication, keep the VPN software updated, and limit which internal networks VPN users can reach. Remote access should not automatically equal unrestricted access to every device.
Multi-factor authentication is especially valuable for externally reachable accounts. Where possible, use hardware-backed keys or an authenticator app rather than relying only on passwords.
Treat the Reverse Proxy as a Boundary
A reverse proxy can simplify certificates and centralize authentication, but it also becomes a high-value target. Do not treat it as a trusted bridge into the entire network.
Run it in the DMZ or in a tightly restricted server segment. Permit it to reach only the specific backends it serves. A public blog should not require network access to the hypervisor, backup server, or home automation controller.
Add authentication in front of administrative applications, even if those applications have their own login screens. Remove unused routes, disable unnecessary modules, and monitor the proxy logs for repeated failures and unusual paths.
A reverse proxy reduces exposed ports. It does not remove the need for isolation.
Make Firewall Rules Boring
A good firewall policy is predictable:
- Deny unsolicited inbound traffic from the internet
- Allow only the public ports that are required
- Block direct access to internal management services
- Restrict outbound traffic from high-risk or disposable systems
- Log denied traffic at sensible levels
- Review rules periodically and remove old exceptions
Avoid exposing services simply because they are convenient to access. If an application is used only at home, keep it internal. If it needs remote access occasionally, use a VPN or an access gateway instead of permanently publishing it.
Disable automatic port forwarding such as UPnP unless there is a specific, understood reason to keep it enabled. Unexpected exposure is one of the easiest ways for a carefully designed firewall policy to be bypassed.
Assume Containers Can Fail
Containers are lightweight and convenient, but they are not a replacement for security boundaries. A container with excessive privileges, access to the Docker socket, host filesystem mounts, or broad network access can turn an application compromise into a host compromise.
Use least privilege:
- Avoid privileged containers unless they are genuinely necessary
- Do not mount the container runtime socket into ordinary applications
- Use read-only filesystems where practical
- Give services only the host directories and capabilities they need
- Separate sensitive workloads from experimental ones
- Keep images, packages, and base systems updated
Virtual machines can provide stronger isolation for workloads with different trust levels, although they still require patching and careful configuration.
Protect Backups From the Main Network
Backups are part of the security boundary. If ransomware or an attacker can modify the only backup location, recovery may not be possible.
Keep multiple copies, including at least one that is offline or otherwise inaccessible from normal workloads. Use immutable or append-only storage when available. Test restoration regularly; a backup that has never been restored is an assumption, not a recovery plan.
Do not give every service credentials to the backup system. A media server should not be able to delete hypervisor backups.
Monitor the Failures You Expect
You do not need a full enterprise security operations center, but you should know when important things fail.
Useful signals include:
- Repeated authentication failures
- New or unexpected internet-facing ports
- Containers restarting unexpectedly
- Changes to firewall or DNS configuration
- Storage usage increasing rapidly
- Backup jobs failing
- Certificates nearing expiration
Centralized logs are helpful, but even a small alerting setup is better than discovering a problem months later. Review logs after making major changes and establish a simple process for responding to alerts.
Build for Recovery, Not Perfection
Security controls will eventually be misconfigured, bypassed, or made obsolete. Design the homelab so that rebuilding is possible.
Keep infrastructure configuration in version control. Record VLANs, firewall rules, DNS entries, and service dependencies. Store secrets separately from public configuration. Maintain an emergency access path that does not depend on the service currently being repaired.
Most importantly, practice deleting and recreating a non-critical service. Recovery becomes much less stressful when the process is familiar.
A Practical Starting Checklist
If your homelab is currently flat and widely exposed, start here:
1. Inventory every internet-facing port and service.
2. Remove exposures that are not strictly necessary.
3. Disable UPnP and review router port-forwarding rules.
4. Move management interfaces behind a VPN.
5. Create separate VLANs for management, servers, clients, IoT, and guests.
6. Apply deny-by-default rules between VLANs.
7. Update the host, containers, applications, and reverse proxy.
8. Remove unnecessary container privileges and host mounts.
9. Create an offline or immutable backup.
10. Test restoring one service from that backup.
These changes do not need to happen all at once. The first objective is to reduce the blast radius of a mistake.
Conclusion
A homelab is supposed to be a place for experimentation, but experimentation should not mean unrestricted trust. Public services, containers, credentials, backups, and management interfaces all deserve different levels of protection.
The most effective design is usually not the most complicated one. It is the one with clear boundaries, minimal exposure, least-privilege access, reliable backups, and a recovery plan.
Build as though one service will be compromised. Build as though a password will be leaked. Build as though a firewall rule will be wrong.
That mindset turns security from a hope into an architecture.