How many public IPv4 addresses does a homelab need?

A homelab rarely grows one service at a time. By the time a game server, a couple of web dashboards, and maybe a mail server all need to be reached from outside the house, most people either buy a public address for every single one or assume one address covers everything. Neither guess is right, and guessing costs money either way.

Here is the actual method: which services can share one routed IPv4 address, which ones need their own, and how to get those addresses to a home network sitting behind carrier-grade NAT (CGNAT).

How many addresses you actually need

1. List every service that someone other than you, or a system outside your control, needs to reach directly. Skip anything you only check yourself over your own VPN mesh — that never needs a public address.
2. Mark the ones that speak HTTP or HTTPS. Every one of those can sit behind a single reverse proxy on one routed address, whatever port they listen on internally.
3. Count what is left. Each of those needs a routed address of its own.

Five HTTPS dashboards and one Minecraft server come out to two addresses: one for the dashboards behind the proxy, one for Minecraft. Add a personal mail server and it becomes three, because a mail server needs its own reverse DNS record too. A homelab that only its owner reaches, over a VPN mesh, needs zero.

What can share an address, and what can't

The proxy trick in step 2 only works on traffic that carries a hostname it can read. That is the entire rule.

A reverse proxy like Caddy, Traefik, or nginx reads that hostname off the Host header or the TLS handshake's SNI field, then forwards the connection to the matching internal service, each with its own certificate.

Confirm CGNAT is actually the blocker first

Before adding any address, check whether the home connection can already accept inbound traffic at all. Compare the IPv4 shown in the router's WAN status page with the address an external IP-check service reports from outside. A match means the router owns a public address and a normal port forward may already work for a single service. A mismatch, or a WAN address inside 100.64.0.0/10, means an ISP-side NAT sits between the router and the internet.

Why CGNAT stops you hosting a server at home covers that detection step in full. The rest of this guide assumes that check already ruled out a plain port forward.

Getting the addresses to your home network

Each address reaches the house through an outbound tunnel, since CGNAT cannot accept an inbound one. WireGuard fits because the tunnel starts from inside the house over ordinary outbound UDP; GRE expects a stable public address on both ends, so GRE vs. WireGuard is worth reading before picking one.

The base pattern for routing any single one of these addresses to its destination is in How to get a public IP for a home server.

On a Proxmox homelab that usually means one address per VM, covered host by host in How to add public IPv4 addresses to Proxmox VMs. The Minecraft case has its own walkthrough in How to host a Minecraft server at home behind CGNAT.

Why not just use Tailscale Funnel or Cloudflare Tunnel

Tailscale Funnel only listens on ports 443, 8443, and 10000, and only over TLS. It removes the need to run your own proxy, but it covers exactly the same HTTPS traffic the proxy already handles, nothing more.

Cloudflare Tunnel goes further and carries SSH, RDP, and other generic TCP traffic through cloudflared, but the connection still reaches Cloudflare's edge before it reaches the homelab. A public Minecraft server open to strangers, or a mail server that needs its own reverse DNS record, sits outside what either product provides.

Both are a fine way to publish an HTTPS dashboard without opening anything at the router. Neither replaces a routed address for the "no" column above.