The idea: what this build is, and why it's shaped this way

This series documents a self-hosted home network — a small VPS, a VPN, and a Raspberry Pi — built one piece at a time, with the reasoning and the mistakes left in. It assumes you already know roughly what a VPS is; there are plenty of explainers for that elsewhere. What’s harder to find is an account of why you’d put these specific pieces together this way, and what the alternatives are. That’s what this is.

This is a high-level design overview: what I built, and the thinking behind each decision. There are no configuration steps here, and nothing in it is a recommendation — the choices suited my situation, not necessarily anyone else’s. What I hope is useful is the reasoning. Working out how to build something similar, and whether any of it is a good idea for you, is yours to do.

Where it started, and where it went

The first goal was small: run a self-hosted speed test (LibreSpeed) on a cheap server, reachable from anywhere. That alone justified a VPS — a small, always-on box with a stable public address, which a home connection doesn’t reliably give you.

But the speed test turned out to be the least important thing the server does. The real value came once a VPN went on it, because the VPN solved a problem that had nothing to do with speed tests.

The problem the VPN solved

I had a service at home that was already reachable from outside — an alarm panel with an IP module, so the alarm could be checked and managed remotely. It worked, and it worked the usual way: dynamic DNS, a hostname that tracks your home IP, with a port forwarded on the router to the device inside.

It was also a liability. DDNS plus a forwarded port is a permanent, advertised opening into your home network, and anything that gets through is already inside the LAN, one hop from every other device.

The VPN reverses this. Instead of the home accepting connections from outside, every device — phone, laptop, the alarm’s hop — dials out to the VPS and meets on the encrypted tunnel. The VPS is the only thing exposed to the internet, and it’s a disposable box in a datacentre with nothing on it but the tunnel and some configs. It’s a much better thing to expose than a home router, though not an absolute boundary: if an attacker compromised the VPS and got the VPN keys, the tunnel is a path toward the home rather than a wall. (That’s part of why the Pi later gets its own firewall rules limiting what the tunnel can reach.) What the home network gains is no inbound openings of its own: no forwarded ports, no DDNS hostname, nothing listening to accept an unsolicited connection. A scanner can still see the ISP-assigned address — it just can’t open a connection to anything behind it.

That’s the core of the build. Everything else follows from it.

The CGNAT problem — when DDNS can’t work at all

Many connections now sit behind CGNAT (carrier-grade NAT), where the ISP shares one public address among many customers and gives you only a private one. It’s common on mobile broadband and budget plans, and usually invisible until you try to reach something at home from outside.

CGNAT prevents inbound connections, which makes port forwarding impossible. DDNS still tracks your address faithfully, but it becomes pointless because the address it publishes isn’t publicly reachable — there’s nothing to forward a port to.

The VPS avoids this. Because every device dials out to the VPS, it doesn’t matter whether your home connection has a public IP, a CGNAT one, or one that changes — outbound connections work regardless. The stable public address the build depends on is the VPS’s, not the ISP’s. A side benefit: switch ISPs or move house and the VPS keeps the same address, so nothing downstream needs changing.

What else the tunnel provides

Once there’s a secure private network connecting all my devices, other things come with it:

• File sharing between devices that works the same at home or on mobile data — no cloud account, no third party holding the files.
• Ad and tracker blocking that follows my devices onto any network, not just home Wi-Fi.
• A private path to anything I host later — every future service is reachable over the tunnel without adding a new opening to the home network.

The pattern: public-facing things live on the disposable VPS; private things live at home and are only reachable through the tunnel.

Where the Raspberry Pi comes in

The home end of the tunnel needs something always on to anchor it. The obvious choice is the router — put the router in the VPN and the whole house is on the tunnel. I didn’t do that: it ties the tunnel to the router’s firmware (often poor), and risks the household’s internet every time I change the config.

Instead, a Raspberry Pi — a cheap, low-power, always-on mini computer — sits on the LAN as the home anchor. It holds the tunnel and routes traffic from remote devices to the alarm panel, so the router never has to know the VPN exists. That separation means I can rebuild or reconfigure the tunnel side without touching the household’s internet. The Pi also runs the file-sharing service (Samba) and the network-wide ad blocking.

The shape of it

The build is three tiers with a clear split of jobs:

• The VPS — public-facing, disposable, the only thing the internet can see. Runs the VPN hub and any public service.
• The tunnel — an encrypted private network in a hub-and-spoke layout, with the VPS as the hub every device connects through. The home’s single outbound-only connection to the outside.
• The home, anchored by the Pi — private services (alarm access, file sharing, ad blocking) reachable only across the tunnel, with the router left alone.

Other ways to do this

This isn’t the only way to solve the problem. Tools like Tailscale, ZeroTier, Cloudflare Tunnel, and router-native options such as MikroTik’s Back To Home also provide secure remote access without inbound exposure. I didn’t evaluate any of them — I went with a VPS and a VPN because that was what I wanted to build and learn, not because I compared and ruled the others out. If your goal is only to reach your home devices from anywhere, they’re worth researching on their own merits.

Why the VPS approach suited me:

• No managed platform in the path. The provider supplies hardware and an initial OS, nothing above that; no managed remote-access service sits between my devices.
• Latency. My own VPS in a datacentre close to home is a short, direct hop, and I chose the region for that.
• I wanted to build and understand it myself.

The rest of this series is how I built it — starting with the two first decisions: renting the box, and deciding whether to put a name in front of it.