How to Access Self-Hosted Apps Remotely (Without Exposing Your Network)

A self-hosted app you cannot reach from outside your house is a hobby. The moment you can open it from a phone on cellular data, it becomes infrastructure. The difference between those two states is one honest decision about how you expose it.

Get that decision right and you have a service. Get it wrong and you have an open port on your home network and a very long weekend.

The three ways to reach a self-hosted app

1. Port forwarding

You forward a port on your router to the server, and the app is on the public internet.

Pros: works from any device, no client software, no third party. Cons: you have now published a service to the entire internet. Anything unpatched, misconfigured, or weakly authenticated is fair game. You also need a public IP, which many connections no longer provide.

Port forwarding is not automatically wrong — public sites need it. But it should be a deliberate decision for a service you intend to be public, not the default for your dashboard.

2. A VPN back into your network

You run WireGuard or OpenVPN on your server and connect to it from your devices. Once connected, you are effectively on your LAN.

Pros: nothing is exposed except the VPN port; strong cryptography; you reach every service at once. Cons: your traffic routes through home while connected, the VPN endpoint itself is public, and per-device onboarding gets tedious as the device count grows.

This is the classic answer and it is a good one. Its weak point is that the tunnel is all-or-nothing: connected means everything is reachable.

3. A private mesh network

Tools like Tailscale and Headscale build an encrypted peer-to-peer network between your devices and servers, without opening ports at all. Each machine gets a stable private address.

Pros: no inbound ports to open; works behind NAT and CGNAT; identity-based access controls; you can share one service with one person instead of the whole network. Cons: it is a managed overlay (unless you self-host the control plane), and you should understand the trust model before you rely on it.

For most homelabs in 2026, this is the best default for private services — and it pairs well with a public reverse proxy for the few services that genuinely need to be public.

The rule that keeps you out of trouble

Expose deliberately, per service. Never expose a whole machine by accident.

Every service should have an answer to: "who is allowed to reach this, and from where?" The common failure is a platform that treats everything as public the moment it is deployed. The correct behavior is a per-service choice:

• Private — reachable only from your own devices over the private network.
• Restricted — reachable from the internet, but only from specified IP ranges or behind an identity provider.
• Public — reachable by anyone, which should be a short and intentional list.

How DashCaddy handles this

DashCaddy's deploy options map directly onto that rule, which is why they are worth knowing before you expose anything:

• Private-network scoping. A service can be restricted to your private network so it never appears on the public proxy at all. For a dashboard, an admin panel, or a database UI, this is the right default.
• Allowed IP ranges. When a service must be reachable from outside, you can permit specific CIDR ranges rather than the whole internet.
• Automatic HTTPS. Services that are public still get a real certificate, so you are not trading security for convenience.
• A security surface. The Security Center exists so the answer to "what is exposed right now?" is a screen you can look at, not a guess.

These are per-deployment settings, not global switches — so exposing one service never quietly exposes the rest. The installation docs cover the dashboard, and the catalog guides document the deploy payload per app; the WireGuard template is there if you prefer to build your own tunnel instead of using a mesh network.

A practical setup, start to finish

1. Install DashCaddy on the host that will run your private services.
2. Join your devices to a private network. Install Tailscale (or point clients at your own Headscale) on your laptop, phone, and the server.
3. Deploy private services with network scoping on. Your dashboard, monitoring, and admin tools should not be public. Ever.
4. Pick the one or two services that must be public — a media server for the family, a photo server you share with a relative — and deploy those normally so they get a certificate and a real URL.
5. Verify from outside. Turn off Wi-Fi on your phone. The private services should be reachable over the private network; the public ones should load at their URL; nothing else should answer.

That five-step sequence gets you remote access without a port-forwarding free-for-all.

Mistakes worth avoiding

• Forwarding 443 to a whole host. You publish every service that host runs, including the ones you forgot about.
• Relying on "nobody knows the URL." Security by obscurity fails the first time a certificate transparency log is read.
• Leaving an admin UI on the public internet. Dashboards, database admin tools, and container managers belong on the private network.
• Forgetting the renewal. A private setup with an expired certificate trains you to click through warnings, which is exactly the habit that gets people phished.
• No monitoring on the remote path. Remote access that silently stops working is worse than none — see the homelab monitoring guide for what to watch.

Getting started

Install DashCaddy on any Linux host:

curl -fsSL https://get.dashcaddy.net | bash

Then deploy something, scope it to your private network, and confirm you can reach it from your phone with Wi-Fi off. If you are still choosing what to run, the full catalog and the best self-hosted apps roundup are good next reads, and one-click Docker deployment explains what happens during a deploy.