Most people assume that a VPS is a more reliable home server because it is always on and should be doing real work. Mine is not. I previously talked about how my NAS is just dumb storage and my local Debian server handles the calculation. All significant workload remains on my Dell Latitude home server: Docker services, databases, media, and anything that actually has data. The VPS in my architecture follows the same philosophy, just from the opposite end of the tunnel. It only has one boring task: bringing Internet traffic to my home network. That’s the idea, really.
A VPS is best when it’s disposable: the intelligence, status and data belong at home.
I stopped treating my VPS like just another server
The less you can do, the less that can go wrong
I had been renting VPS long before I started hosting on my own. From my own publishing to free and open source web applications, I had used several VPSs along the way: Digital Ocean, Hetzner, Linode and Vultr. So when I first rented the VPS for my home lab, I considered it another Linux server and decided to use every ounce of computing power I had to make it worth every penny spent. I tried to add as many amenities as possible because my mind was programmed that way and all the other self-hosting guides suggested the same thing.
A little context about my home lab before I explain why I chose a VPS in the first place. I built my home lab server from a repurposed 8 year old laptop. The laptop was a Dell Latitude 7480; It had a Core i5-6300U CPU, about 11.6GB of RAM, and a 256GB SSD. Today, it has more than 15 batteries with more than 20 containers that power my home. This is the computing part and I have a 6 year old Synology NAS that handles the storage part. So regardless of what I throw at the server, my data will always be safe on completely different hardware.
Now, why did I choose a VPS when I already had a bare-metal Debian server? I have two Internet connections to my home and neither gave me a public IPv4 address because both sitting behind CGNAT. That meant that the traditional method of drilling a hole in my router to expose self-hosted services was not possible for me. I didn’t add the VPS because I wanted another server, but it was the only practical way to do it.
The VPS is not where my home lab lives; This is how the outside world arrives.
I didn’t just go with VPS as my only option; I tried 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 did not agree with the implementation. I wanted to own my entire entry route, in the infrastructure that I actually controlled. And I was already using Cloudflare for DNS, CDN, Pages and Workers. Adding another layer meant keeping all my eggs in one basket. Running the tunnel endpoint on my own VPS meant a clearer separation of responsibilities.
Each piece had one job, and only one.
Pangolin opens the door, Headscale checks who is knocking
So once the VPS had a job, the next question was obvious. What do you really need to do? The simple answer was to accept the traffic and forward it home. After that, everything was simple. Pangolin felt like the best alternative to Cloudflare since the concepts were similar under different names. Pangolin handled the control plane panel, Gerbil handled the WireGuard server, Traefik handled the reverse proxy, and Newt ran as the tunnel client.
Once that was resolved, I had to think about the secure private access part. Tailscale was already on all my devices, so instead of replacing the entire system, I just pointed mine. self-hosted Headscale control server instead of Tailscale’s coordination servers. After that, Pangolin took care of the public part and Headscale took care of the rest. I could host some 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 just for those jobs?
Today, the VPS stores almost nothing and simply acts as a gateway to the public. The laptop is still the brain of the architecture, where the real computing happens and finally the NAS functions 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 ignore
I haven’t had to try this the hard way yet and I’d rather not have to. I’ve been using the new architecture for about a month. And all the problems I had faced were coming from the home server, not the VPS or NAS. And honestly, that was the point, not a gap in the story. That didn’t happen because the VPS was magically more reliable, but because the VPS had only one function: the gateway to the public. And that came with very little responsibility to fail in an interesting way.
If I remember correctly, I faced a minor problem. Due to my nature of work, I am always trying out different services. I was trying Starting AdGuard with Unbound and then without him. When I temporarily stopped Unbound and switched to DoH, 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 removed all external access until I intervened. Although once I restarted the container it immediately restored the tunnel. It was a direct example of the income layer needing a boost, not a complete recovery.
This was the smallest possible version of a VPS side problem; possibly not even on the VPS side. If the tunnel client had a more stable local DNS to depend on, it probably wouldn’t have had to deal with it. The point of the story was that you didn’t have to recover from a catastrophe, such as recovering a database, rebuilding the state of an application, or repairing Docker volumes; he was simply getting the input route 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 issue that once broke Immich and Nextcloud. What I would do is recreate the VPS in less than a minute, and in a few more minutes, redeploy Pangolin and reconnect to Newt, and you would be good to go. Recovery was easy not because Pangolin was special, but because the VPS literally owns nothing: no databases, no media, no Docker volumes, no user files.
Yes, there is a real drawback: my home Internet connection. External services still depend on it. My dual WAN setup reduces it to some extent, but it doesn’t eliminate the risk. History revealed no defect in my architecture; it reinforced that I put complexity in the only place it really belongs.
The smartest thing my VPS does is nothing
I used to treat the VPS as the “real server” because it contained the public IP, but once I started self-hosting, I realized that it’s just the front door – the house is still my house. The Dell Latitude server has intelligence, the NAS stores data, and the VPS simply takes visitors to the right place. Good homelab design is not about making each device or infrastructure as capable as possible, but rather giving each a clear and limited responsibility.
