--- title: "How to Access Self-Hosted Apps Remotely (Without Exposing Your Network)" description: "Port forwarding, VPNs, and private networks compared. Learn the safe way to reach self-hosted apps from anywhere, and how to scope a service to your own devices." date: "2026-10-07" author: "DashCaddy Team" tags: ["access self-hosted apps remotely", "remote access homelab", "tailscale homelab", "secure remote access", "self-hosted vpn"] readingMinutes: 8 --- 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](/docs/installation/) cover the dashboard, and the [catalog guides](/docs/catalog/) document the deploy payload per app; the [WireGuard template](/docs/catalog/wireguard/) 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](/blog/homelab-monitoring-guide/) for what to watch. ## Getting started Install DashCaddy on any Linux host: ```bash 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](/blog/self-hosted-app-catalog-guide/) and the [best self-hosted apps roundup](/blog/best-self-hosted-apps-homelab/) are good next reads, and [one-click Docker deployment](/blog/one-click-docker-deployment/) explains what happens during a deploy.