Sean Wong

Adding Remote Access to a Home Server, Carefully

by · Monday. Jul 27, 2026

topicsself-hosthomelabnetworking

Reaching the server from outside, without opening the front door

The whole point of this series has been a quiet, LAN-only home server. Everything lives on my local network, nothing is exposed to the internet, and that’s a feature, not a limitation. But there are a few honest moments where I want my photos or documents while I’m away from home, and I don’t want to drive back to grab them.

Remote access is useful. Exposing services blindly violates the local-first philosophy. So the question isn’t “how do I open this up,” it’s “what’s the smallest amount of exposure that gets me what I need?” This post is me comparing the options through that lens: risk versus convenience, not features.

What this solves

  • Keeps LAN-only as the default.
  • Picks the safest remote-access option for a calm server.
  • Names a simple threat model instead of hand-waving security.
  • Decides which services should never leave the LAN.

LAN-only is still the default

Before any of this, I want to be clear: most days, the right answer is to change nothing. The server sits on the LAN behind Pi-hole and Caddy, and that’s where it’s safest. Nothing exposed means almost nothing to attack from the open internet.

So remote access isn’t an upgrade I’m chasing. It’s an exception I’m carving out carefully, for the few cases that actually justify it. If a use case doesn’t clear that bar, the service just stays local.

The use cases that actually justify it

Here’s my honest list of times I’ve wanted remote access. Notice how short it is.

  • Pulling up a Paperless document while I’m at an appointment.
  • Checking that Immich backed up my phone before I wiped it for a trip.
  • Showing someone a photo from my own library, not a re-upload to someone else’s cloud.

That’s about it. I do not need Jellyfin streaming over the internet, I do not need my dashboard public, and I definitely don’t need an admin panel reachable from a coffee shop. Once I wrote the list out, it became obvious that I want occasional access to a couple of services, not a public website.

A simple threat model

You can’t pick a tool until you’ve named what you’re actually worried about. I’m not running a bank, so my threat model is modest and that’s fine.

What I’m worried about:

  • Automated bots scanning every IP for exposed services and known bugs.
  • A vulnerability in one self-hosted app becoming a way into my whole network.
  • Me misconfiguring something and not noticing it’s wide open.

What I’m not really worried about: a targeted attacker who specifically wants my homelab. The realistic risk is the internet’s background noise, the constant drive-by scanning that finds anything you accidentally leave exposed. The safest setups remove me from that noise entirely, so there’s nothing to find in the first place.

The four options, ranked by risk

Now the comparison. Four common ways to reach a home server, roughly from least to most exposure.

Tailscale (mesh VPN). Builds a private network between my devices using WireGuard under the hood. Nothing is published to the public internet. My phone and my server just act like they’re on the same LAN, wherever I am. Lowest exposure, easiest setup.

Plain WireGuard. The same encrypted tunnel, but I run the server myself. More control, no third party in the path, but I have to open one UDP port on my router and manage keys by hand. Low exposure, more effort.

Cloudflare Tunnel. An outbound connection from my server to Cloudflare, so I don’t open any inbound ports. It can publish a service at a real hostname with HTTPS. Convenient, but it does put a service on the public web, which means I’m back in the scanning noise and leaning on extra access controls.

Public reverse proxy. Forward ports 80/443 from my router straight to Caddy and serve things publicly. Maximum convenience, maximum exposure. This is the option that puts my home IP and my self-hosted apps directly in front of every bot on the internet. For a calm server holding personal data, that’s the one I want to avoid.

The safest first step: a mesh VPN

For my use cases, Tailscale wins clearly. It gives me exactly the short list above, with basically no public exposure, and it took less time to set up than installing most of the apps in this series.

The shape is simple. Install it on the server and on my phone:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Do the same on the phone, sign in to the same account, and now both devices share a private network. From anywhere, I can reach the server at its Tailscale address as if I were home. One detail I like: I can keep using my clean local hostnames by advertising Pi-hole as the tailnet’s DNS server in the Tailscale admin console, so immich.home.arpa works on the road too. The catch worth flagging: those hostnames have to resolve to the server’s Tailscale IP, not its 192.168.x LAN address (or you turn on Tailscale subnet routing so the LAN range is reachable over the tunnel). Point them at the LAN IP and they’ll quietly fail the moment you leave the house, which is a confusing thing to debug from a coffee shop.

Nothing is published. There’s no inbound port, no public certificate, no hostname for a bot to find. The server stays invisible to the internet and visible only to my own devices. That’s the version of remote access that fits a local-first project.

Which services just stay local forever

Even with a VPN in place, not everything earns remote access. The mesh tunnel lets me reach the whole server, but I still decide what I actually open from outside, and I keep that list short on purpose.

What stays strictly local for me:

  • Pi-hole’s admin panel (network infrastructure, no reason to touch it remotely)
  • The Caddy and router admin pages
  • qBittorrent’s web UI

The rule I settled on: if a service controls the network or could be a foothold into everything else, it never leaves the LAN, full stop. Remote access is a convenience for reading my own data, not a reason to expose the machinery that runs the house. Keeping that line bright is what lets me add remote access without feeling like I betrayed the whole point.

What’s next

With backups in part 14 and careful remote access here, the server is protected and reachable on my terms. Next up in part 16, I look at monitoring: knowing when the server is down, full, or overheating, without turning my calm homelab into a second job.