People mostly assume a VPS is a more reliable home server because it's always on and should be doing real work. Mine isn’t. I previously talked about how my NAS is just dumb storage and my local Debian server handles the compute. All meaningful workload stays on my Dell Latitude home server — Docker services, databases, media, and anything that actually owns data. The VPS in my architecture follows the same philosophy, just from the opposite end of the tunnel. It has only one boring job of getting internet traffic into my home network. That's the whole idea, really.
A VPS is best when it's disposable — the intelligence, state, and data belong at home.
I stopped treating my VPS like another server
The less it can do, the less that can go wrong
I had been renting VPSs long before I started self-hosting. From my own publication to free and open-source web apps, I had used various VPSs along the way — Digital Ocean, Hetzner, Linode, and Vultr. So, when I first rented the VPS for my homelab, I thought of it as another Linux server and decided to utilize every ounce of compute power it had to make every cent spent worth it. I tried adding as many services as possible because my mind was programmed that way, and every other self-hosting guide suggested the same.
A little bit of context about my homelab before I jump into why I chose a VPS in the first place. I built my homelab server out of a repurposed 8-year-old laptop. The laptop was a Dell Latitude 7480; it had a Core i5-6300U CPU, roughly 11.6GB of RAM, and a 256GB SSD. Today, it runs more than 15 stacks with 20+ containers powering my home. This is the compute part, and I have a 6-year-old Synology NAS handling the storage part. So, whatever I throw at the server, my data is always safe on entirely different hardware.
Now, why did I choose a VPS when I already had a bare-metal Debian server? I have two internet connections for my home, and neither gave me a public IPv4 address because both sat behind CGNAT. That meant the traditional method of punching a hole through my router for exposing the self-hosted services wasn’t possible for me. I didn’t add the VPS because I wanted another server, but it was the only practical way in.
The VPS isn't where my homelab lives; it's how the outside world reaches it.
I didn't just settle on the VPS as my only option; I did try other alternatives first. Cloudflare Tunnel and Tailscale were two of the examples. They worked, and I used them for some time too. But my self-hosting ideology didn’t agree with the implementation. I wanted to own my whole ingress path, on infrastructure I actually controlled. And I was already using Cloudflare for DNS, CDN, Pages, and Workers. Adding another layer to it meant keeping all my eggs in one basket. Running the tunnel endpoint on my own VPS meant a cleaner separation of responsibilities.
Every piece had one job, and only one
Pangolin opens the door, Headscale checks who's knocking
So once the VPS had one job, the next question was obvious. What does it actually need to do? The simple answer was to accept traffic and forward it home. After that, it was straightforward. Pangolin felt like the best Cloudflare alternative since the concepts were similar under different names. Pangolin handled the control plane dashboard, Gerbil handled the WireGuard server, Traefik handled the reverse proxy, and Newt ran as the tunnel client.
Once that settled, I needed to think about the secure private access part. Tailscale was already on all my devices, so instead of replacing the whole system, I just pointed to my own self-hosted Headscale control server rather than Tailscale's coordination servers. After that, Pangolin handled the public-facing piece, and Headscale handled the rest. I could host a few of my services on the VPS, maybe Immich or Jellyfin, but why bother adding more latency, storage bills, and another place to maintain when my local server and NAS are there only for those jobs?
Today, the VPS stores almost nothing and simply acts as the public-facing front door. The laptop remains the brain of the architecture, where actual computation happens, and finally the NAS works as dumb storage. The more boring the VPS became, the happier I was with the overall architecture.
A dead VPS costs me an afternoon — a dead server costs me everything
One of these failures I can shrug off
I haven't had to test this the hard way yet, and I'd rather not have to. I have been using the new architecture for about a month now. And all the issues I had dealt with came from the home server — not the VPS or the NAS. And honestly, that was kind of the point, not a gap in the story. That happened not because the VPS was magically more reliable, but because the VPS had only one job, the public-facing front door. And that was very little responsibility to actually fail in an interesting way.
If I recall correctly, I did face a minor issue. Due to my nature of work, I am always trying different services. I was testing AdGuard Home with Unbound and then without it. When I temporarily stopped Unbound and switched to DoH, the DNS briefly became unavailable. And during that window, the newt container that connects to the Pangolin control plane lost its connection. It didn't automatically recover once DNS came back and that took down the whole external access until I stepped in. Though once I restarted the container, it immediately restored the tunnel. It was a direct example of the ingress layer needing a nudge, not a full recovery.
This was the smallest possible version of a VPS-side hiccup — arguably not even VPS-sided. If the tunnel client had a steadier local DNS to depend on, I probably wouldn't have had to face it. The point of the story was that I didn’t have to recover a catastrophe, like recovering a database, rebuilding application state, or repairing Docker volumes; it was simply getting the ingress path to talk again.
And in the worst-case scenario, if the VPS disappeared tomorrow, it would be an easier job than fixing a WatchTower auto-update mess that once broke Immich and Nextcloud. What I would do is recreate the VPS in under a minute and, in another few minutes, redeploy Pangolin and reconnect Newt, and I would be good to go. The recovery was easy not because Pangolin was special, but because the VPS literally owns nothing — no databases, no media, no Docker volumes, and no user files.
Yes, there is one genuine downside of it — my home internet connection. The external services still depend on it. My dual-WAN setup reduces it to a point, but it doesn’t eliminate the risk. The story didn't reveal a flaw in my architecture — it reinforced that I put complexity in the only place where it actually belongs.
The smartest thing my VPS does is nothing
I used to treat the VPS as the "real server" because it held the public IP, but once I started self-hosting, I realized it's just the front door — the house is still at home. The Dell Latitude server owns intelligence, the NAS stores data, and the VPS just gets visitors to the right place. Good homelab design isn’t about making every device or infrastructure as capable as possible, but it’s about giving each one a clear and limited responsibility.