[grade=A] SEO expansion: generated sitemap (14->108 URLs) + RSS feed + 4 keyword articles + 77-app catalog hub

src/content/blog/access-self-hosted-apps-remotely.md

@@ -0,0 +1,90 @@
+---
+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.