Self-hosting culture learned one pattern very well: if you want remote access to something, forward a port and point traffic at the box.
That made sense for a long time. It was simple, local, and easy to explain. Your router had the public IP. Your service lived behind it. You told the router where to send the traffic. Done.
The problem is that a working setup is not always a good default.
If a service is meant for you, or for a small group of trusted people, putting it directly on the public internet should not be the first move anymore. That is especially true for SSH, admin panels, hypervisor consoles, NAS interfaces, dashboards, and all the small control surfaces that collect in a homelab over time.
The better question is not, “How do I expose this?”
It is, “Who actually needs to reach this, and from where?”
Why port forwarding became the habit
Port forwarding stuck because it solved a real problem without needing much infrastructure.
It also became the answer in thousands of tutorials, forum replies, Reddit comments, and setup guides. Need to reach a service from outside the house? Open a port. Need a quick demo? Open a port. Need access to a dashboard while you are away? Open a port.
That habit is understandable. It is also worth rechecking.
Publishing a service to the internet is not a neutral setup step. It means you are now responsible for patching it, hardening it, logging it, watching it, and remembering why it was exposed six months from now when Future You is trying to untangle the network. Future You deserves better documentation. Future You is tired.
CISA has been direct about this for management interfaces. In 2023, it told federal agencies to secure internet-exposed management interfaces by removing them from the public internet or putting stronger controls in front of them (CISA). Earlier guidance from CISA and the NSA made the same basic point: if something does not need internet connectivity, disconnect it from the internet and use compensating controls where connectivity cannot be removed (CISA/NSA).
That does not mean every exposed port is reckless. It means exposure should be a decision, not muscle memory.
Better access patterns are normal now
The good news is that remote access no longer has to mean punching inbound holes in the firewall for every useful thing you run.
There are better patterns now. Not magic patterns. Not “set this up and stop thinking” patterns. Just better defaults for common use cases.
Overlay networks, for services meant for you
If the service is mainly for you and a few trusted people, an overlay network is usually the first option I would consider.
Tools like Tailscale and ZeroTier create a private network across your devices, so your laptop, phone, and servers can talk as if they were on the same LAN. Tailscale’s docs say most users do not need to open firewall ports at all (Tailscale). When direct peer-to-peer connectivity is not possible, Tailscale can fall back to relayed connections, including DERP relays and peer relay paths depending on the setup (Tailscale).
That makes overlays a good fit for:
- SSH
- Proxmox or other hypervisor management
- NAS admin panels
- internal dashboards
- RDP or other remote admin tools
- personal services that do not need random public visitors
It is not a good fit for a service that is supposed to be publicly reachable by anyone on the open internet.
The tradeoff is straightforward. You reduce broad exposure, but now the remote-access layer matters. Authentication, device trust, account recovery, patching, and access review still count. “Use a VPN” is not a substitute for judgment. NSA and CISA say as much in their remote-access VPN guidance, including MFA, timely patching, and limiting management exposure (NSA/CISA PDF).
Reverse tunnels, for publishing one specific web app
If you need to expose a specific web app, a reverse tunnel can be a cleaner fit than opening inbound ports.
Instead of waiting for the internet to connect directly to your server, the server creates an outbound connection to a provider edge. Traffic comes back through that tunnel to the app you configured. Cloudflare Tunnel documents this as an outbound-only model and recommends blocking unsolicited ingress traffic so only configured tunnel services are exposed (Cloudflare).
That can make sense for:
- a public site
- a status page
- a temporary demo
- a small app you want reachable without exposing your raw home IP
This is one reason tunnels show up in my homelab architecture. They are useful, especially when you want a narrow path into one service without opening inbound ports broadly.
The catch is dependency. You are trusting the tunnel provider and its control plane. If it has an outage, a policy problem, or a bad day, your access path can get weird. That does not make tunnels bad. It makes them a tradeoff.
Identity-aware access, for web apps that should not be open to everyone
Sometimes a service needs to be reachable from outside, but not by everyone.
That is where identity-aware access layers can help. The idea is simple: put authentication in front of the app before the app itself gets to answer. For browser-based tools, that can be a better fit than exposing the app directly and hoping its login page is the only thing anyone finds.
This works well for dashboards, family portals, small internal tools, or admin-ish web apps used by a trusted group.
It is not universal. It mainly helps with browser-based services, and it adds reliance on both the access layer and the identity provider. If you lean on third-party control planes for access, understand that dependency. That is close to the same trust-boundary problem I wrote about in the Vercel post: different incident class, same basic lesson. Access layers deserve real attention.
When direct exposure is still the right answer
Some services really do need to be public.
Public websites, game servers, mail infrastructure, public APIs, federation endpoints, and similar services may need direct exposure. There is no value in pretending everything can disappear behind a private overlay or identity gate.
The point is not “never expose anything.”
The point is “know why this is exposed.”
Let’s Encrypt is a good example. If you use HTTP-01 validation, your server needs to be reachable on port 80 because that challenge can only be completed on port 80 (Let’s Encrypt). That is a real reason. If you do not want that path, DNS-01 is another option, with its own tradeoffs.
If you do expose something directly, treat it like an internet-facing service because that is what it is:
- Open only the ports you actually need.
- Isolate exposed services from management networks.
- Patch aggressively.
- Use MFA, keys, sane passwords, rate limiting, and basic abuse controls.
- Log enough to notice failed logins, traffic spikes, and repeated probing.
- Document why the exposure exists.
That last part matters. A lot of homelab advice gets through the port-forwarding step and then quietly wanders off before monitoring enters the room. If you publish something, you should be able to see what is happening to it. That is part of why the monitoring stack I actually trust matters.
A practical decision rule
Here is the simple version.
If the service is private, keep it private.
If it is web-based and needs limited outside access, put identity in front of it.
If it needs to be public, expose only what is necessary and harden it properly.
If it is latency-sensitive, protocol-specific, or awkward behind a tunnel, direct exposure may still be the right answer. Fine. The point is to choose on purpose.
What I would not do anymore is treat “open a port and see what happens” as normal homelab hygiene.
That habit made sense when the alternatives were worse. The alternatives are not worse now.
Practical takeaway
Take 15 minutes and audit every forwarded port you have.
For each one, ask:
- Who actually needs access?
- Does this need to be public, or just reachable by me?
- Would an overlay network solve this more cleanly?
- Would a reverse tunnel or identity gate make more sense for this app?
- If it has to stay public, am I actually treating it like a public service?
A lot of self-hosting security gets framed as exotic threat models and expensive tooling. Usually it starts with a simpler move: stop publishing things by habit.
Publish them because there is a reason.