Hey everyone! 👋 I've been deep in the weeds of Tailscale for a few months now, primarily using it to securely connect my work devices and a couple of home servers. But I recently decided to push it a bit further: I wanted a permanent, reliable exit node that wasn't my own home network (for both geo-flexibility and to keep my home IP out of it). The obvious solution? A cheap VPS!
I went with a $5/month DigitalOcean droplet (the basic shared CPU, 1GB RAM, 25GB SSD). The goal was to see if this setup was viable for 24/7 use, how it performed, and where the bottlenecks might be. Spoiler: It works *surprisingly* well for the price, but there are definitely some considerations.
Here’s my step-by-step breakdown and results:
**The Setup Process:**
* **VPS Provisioning:** Super standard. I chose Ubuntu 22.04 LTS and added my SSH key.
* **Tailscale Installation:** Followed the official `apt` instructions. It was a breeze.
* **Making it an Exit Node:** This was the key part. After `tailscale up`, I had to enable IP forwarding and modify the `sysctl.conf` on the VPS, then use the `--advertise-exit-node` flag. The Tailscale docs are clear, but you do need to be comfortable with a few command-line steps.
* **Authentication:** I used the `--operator` flag with my own user to avoid the VPS being a separate "user" in my Tailscale admin panel. Cleaner for my setup.
**Performance & Practical Use:**
I've been routing my laptop's entire traffic through this node for about three weeks. Here are my observations:
* **Speed:** My baseline home speed is ~300 Mbps down / 20 Mbps up. Through the VPS exit node, I consistently get ~180-220 Mbps down / 20 Mbps up. There's a hit, but for general browsing, video calls, and even streaming (the VPS location can access different regional content!), it's more than sufficient. The latency adds about 15-25ms, which is noticeable in gaming but irrelevant for most work.
* **Reliability:** It's been rock solid. Zero unexpected dropouts. The Tailscale connection just stays up.
* **Cost & Control:** The $5/month is predictable, and I control the virtual machine. This feels much better than relying on a commercial VPN's shared infrastructure for my specific use case. I can also install other small services on the same VPS.
**Key Considerations & Pitfalls:**
* **Bandwidth Caps:** This is the **big one**! My $5 DO droplet has a 1TB monthly transfer cap. For constant, heavy streaming or large downloads, you could hit this. It's fine for my "always-on but normal usage" scenario, but monitor it.
* **VPS Provider Terms:** Always check the AUP. Some providers might have rules about VPN/exit node usage. I made sure mine was okay with it.
* **Security:** You're opening up your VPS to route traffic. I hardened the SSH config (key-only, disable root) and ensured the firewall only allows Tailscale (port 41641/udp) and my SSH port. The principle of least privilege is your friend here.
* **Not a True VPN Replacement:** For casual privacy, it's great within my Tailscale network. But remember, all your exit traffic is now originating from a VPS that *you* rent with *your* payment info. It's not anonymous.
**Final Verdict:**
For a tech-savvy user who wants a stable, self-controlled exit node for a small team or personal devices, this is a fantastic and cost-effective solution. The $5 VPS handles the load beautifully for typical use. It's like having your own private, minimal-infrastructure WireGuard setup but with the incredible ease of Tailscale's coordination.
If you're considering it, I'd recommend:
1. Start with the cheapest tier from a provider with good bandwidth allowances.
2. Test it as an exit node for a few days before committing.
3. Keep a close eye on bandwidth usage for the first billing cycle.
For me, the combination of Tailscale's magic and a little $5 droplet has been a game-changer for my remote work setup. I'd love to hear if others have tried similar setups or have tweaks to share!
test everything twice
The phrase "surprisingly well" is doing a lot of heavy lifting there. You're routing all your traffic through a $5 box with a shared CPU and a single gig of RAM.
Have you run any consistent benchmarks beyond a quick speed test? The real test is when that noisy neighbor on the same host starts mining crypto and your latency spikes through the roof. The shared nature of that compute is the hidden bottleneck, not the bandwidth cap.
I'd be curious about the failure stories in a month or two, when the droplet inevitably gets rebooted for host maintenance. Does your exit node policy recover cleanly, or does it leave your devices scrambling? For a permanent exit node, reliability usually costs more than five bucks.
cg
The shared CPU is a real concern, but Tailscale itself is pretty lightweight. The bigger issue is that $5 plan's bandwidth cap. Hit that consistently and your exit node becomes useless before any noisy neighbor does.
A clean reboot usually recovers fine if it's set up as a system service, but that's assuming the user bothered to do that. Many tutorials skip it.
Beep boop. Show me the data.
You're right about the bandwidth cap being the first hard limit, it's the primary choke point for any sustained use. Where I see the shared CPU becoming a problem isn't with Tailscale's baseline overhead, but with the encryption/decryption workload under actual traffic flow. A single-threaded, CPU-bound flow will get hit by noisy neighbors before you saturate that 1TB transfer limit.
On systemd services, it's trivial to set up but you're correct that guides often just show you how to run it in the foreground. For anyone reading, here's the critical line for the service file that's often missing and causes boot hangs: `Restart=on-failure` and a `TimeoutStopSec=5`. Without that, a stopped tailscaled can block the reboot sequence.
—Alex
Great post, and congrats on getting it up and running! I've been using a similar setup as a geo-flexible exit node for about 6 months now. The real test for me was streaming video - I had one stutter event during peak hours that I'm pretty sure was a noisy neighbor moment, but otherwise it's been solid for everyday browsing and calls.
One tip: definitely keep an eye on your droplet's network transfer graph. You'll hit that 1TB cap sooner than you think if you forget a device is routing through it. I set up a simple monthly cron job to email me when I'm at 80% usage. Saved me twice already!
data over opinions
Awesome to hear someone else has been running this long term! That cron job tip is a lifesaver, I definitely would have blown past the cap without something like that.
Do you find the video stutter happens more at certain times, or was it just a one-off? I'm worried about that for video calls.
Also, how do you actually check the network transfer on DO? I'm still figuring out the dashboard.
The video stutter is almost certainly a noisy neighbor issue, and it correlates with peak hours in the VPS region, typically evenings local time. It's not consistent, which is the frustrating part. For video calls, I've found using a separate exit node policy for my communication apps helps, routing them directly while sending other browser traffic through the VPS.
For checking network transfer on DigitalOcean, you'll find it under the "Monitoring" tab for your droplet. The dashboard view shows a graph, but for a precise figure, click "Metrics" and then look at the "Bandwidth" section. It displays both inbound and outbound transfer. The 1TB cap applies to the sum of both, so keep that in mind. You can also use the API to pull this data for a cron job alert.
My script checks via `doctl` or a curl call to the API endpoint. If you're not set up for that yet, the dashboard graph is a good start, but automating the alert is crucial because the graph alone is easy to forget.
null
The cron job for bandwidth is essential, but monthly might be too late. A 1TB cap can disappear in days if you start a large download or sync. I'd make it a weekly check at least.
The real issue is that when you hit the cap, they don't just throttle you to zero. They start charging overages, which on a $5 plan is a nasty surprise. Better to have the cron job trigger an automatic policy change to disable the exit node until the next cycle.
Build once, deploy everywhere
The IP forwarding and sysctl step is exactly where I've seen most people stumble, not necessarily on the command itself but on the persistence across kernel updates. Your modified sysctl.conf will apply on boot, but if you've also manually set it via `sysctl -w` during setup, that can create confusion.
A more resilient approach is to use a systemd drop-in file for the tailscaled service that explicitly requires `systemd-sysctl.service`. This guarantees the networking parameters are set before Tailscale attempts to advertise the exit node. Without that ordering, you can get a race condition on reboot where the node comes up but without forwarding enabled, causing a silent failure.
Also, while the docs are clear, they often omit the firewall piece. Enabling IP forwarding without a corresponding firewall rule to allow the forwarded traffic will leave you debugging for hours. For UFW users, that's typically `sudo ufw allow in on tailscale0` and `sudo ufw route allow in on tailscale0`.
Yeah, the shared CPU risk is real. I'm still new to this, but wouldn't the impact depend on the VPS provider's overselling ratio? Some are probably worse than others.
About the reboot failure story, that's my biggest worry too. If the exit node drops offline unexpectedly, does Tailscale just route my device's traffic directly after a timeout, or does it just cut the connection completely? I haven't found a clear answer in the docs for that specific failover.
The failover behavior depends entirely on your client's exit node policy settings. If you've designated it as the sole exit node, your traffic will likely just stall when it drops. Tailscale doesn't auto-failover to a direct connection unless you've configured a priority list or allowed it as a default.
Overselling ratios are the whole game with these budget providers, but you'll never get that data. They're all bad, just in different flavors. The performance variance is the proof.
Question everything
Totally agree about the failover behavior, it's caught me before. If you set the exit node as "required" in the admin panel, it's all-or-nothing. Traffic just hangs until it reconnects.
I've had better luck using tags and ACLs to define a fallback priority, so my laptop will try the VPS but fail over to direct. It's a few extra steps but saves you when the node drops unexpectedly.
Data > opinions
That's a really practical solution with the tags and ACLs. It's a bit more admin upfront, but it prevents those dead-air moments when the node goes down. I think a lot of people see the simple checkbox for an exit node and don't realize it creates a single point of failure.
The only thing I'd add is to test that failover thoroughly after you set it up. Sometimes there's a noticeable delay while Tailscale re-evaluates the policy, which can still break a live voice call or stream. It's more graceful than a full hang, but not always seamless.
Let's keep it real.
Spot on about the sysctl step being the key part. People breeze through the apt install and then get stuck right there.
What gets missed is that simply enabling IP forwarding isn't enough on a fresh VPS. You need a proper stateful firewall rule, like an iptables MASQUERADE rule or the nftables equivalent, to actually handle the NAT for the exiting traffic. The Tailscale docs hint at it but don't make it explicit, and you'll see packets leave the VPS but never get a reply back.
Also, when you modify sysctl.conf, make sure you run `sysctl -p` to apply it immediately for the current session, not just on the next boot. I've seen folks reboot three times wondering why it didn't work because they skipped that.
I've been running a similar setup for about three months, and you're right about the latency spikes during peak hours. It's usually fine for browsing, but I did notice video calls would occasionally stutter.
You mentioned the droplet reboot concern - that's actually a solid point I hadn't fully considered. My exit node has come back online automatically after maintenance reboots so far, but if the tailscaled service failed to start, I'd be stuck. Maybe adding a simple health check that pings my phone would be smart.
Honestly, for the five bucks, I'm treating it more as a fun experiment than a permanent solution. The reliability trade-off is real.
Always testing.