you need to learn Load Balancing RIGHT NOW!! (and put one in your home network!)

A home network can be secured and simplified by exposing only a single public entry point—HTTPS on port 443—then using a Kemp “LoadMaster” load balancer to route that traffic to many internal services (Plex, NAS, websites, Proxmox, ESXi) based on domain names and URL/host rules. The payoff is practical: fewer router “holes,” one public IP/port for everything, and HTTPS certificates that keep external access clean and browser-friendly.

The tutorial starts with what load balancing does in general: when traffic grows, multiple backend servers can share the work, but clients still need a single address to reach the service. A load balancer sits in front, accepts incoming requests, and distributes them across “real servers,” while also monitoring health so dead or unhealthy backends don’t receive traffic. That enterprise pattern is then mapped to a home lab, where the real problem isn’t CPU spikes—it’s remote access.

Without a load balancer, remote access typically means opening multiple ports on the router (for example, 443 for a website, 50001 for a Synology NAS, 32400 for Plex, and others). That approach creates multiple inbound attack surfaces and runs into a hard limitation: port 443 can only point to one internal IP, so adding more HTTPS services becomes awkward or impossible. The solution presented is to close everything except port 443 and forward that single port to the load balancer’s virtual IP (VIP). From there, the load balancer routes requests internally.

The build uses three key components. First, Kemp LoadMaster runs as a virtual appliance on a hypervisor such as VMware ESXi (with guidance that other platforms like KVM or Proxmox may require workarounds). Second, a free domain is obtained from Freenom (example used: hackwell.tk). Third, Cloudflare manages DNS and SSL. Cloudflare’s “proxy” feature hides the home’s public IP address, and its integration with Let’s Encrypt provides certificates—crucially including wildcard coverage—so subdomains like plex.hackwell.tk and nas.hackwell.tk can use valid HTTPS.

Inside Kemp, the configuration begins by creating a VIP (the single internal IP that represents the public-facing portal) and then defining “virtual services” on TCP/443. Backend services are added as real servers, including multiple NAS instances and multiple web servers. Kemp health checks verify whether each backend is actually reachable using the right protocol (HTTPS, HTTP, or even ICMP ping), and traffic is withheld from unhealthy targets.

To make routing intelligent, the setup moves beyond basic layer-3 forwarding into layer-7 content switching. Content rules inspect the Host header (e.g., requests for plex.hackwell.tk) and switch to the correct subservice, forwarding traffic to the appropriate internal port (Plex to 32400, NAS to 501, and so on). The tutorial demonstrates that Plex, Proxmox, ESXi, and a multi-server website can all be reached securely through their own subdomains while still sharing the same external port 443.

Finally, the guide highlights operational benefits: automatic failover when a backend server goes down, centralized security controls such as a built-in web application firewall option, and an enterprise-like architecture that can be replicated in real deployments. The author notes an alternative SSL approach—having Kemp handle certificates directly via Let’s Encrypt—but keeps Cloudflare as the practical choice for the home lab.