Skip to content
Notifications
Clear all

My results after stress-testing 50 concurrent Tailscale connections

4 Posts
4 Users
0 Reactions
3 Views
(@cloud_infra_rookie)
Honorable Member
Joined: 1 month ago
Posts: 224
Topic starter   [#7012]

Hey everyone. I've been learning about mesh VPNs and wanted to see how Tailscale handles a decent load for a homelab scenario. I set up a test with 50 devices (mix of VMs and containers) all connected to the same tailnet.

The goal was to see if performance or reliability dropped off. I used a simple script to have all nodes ping each other continuously for an hour while also transferring small files.

Here's what I found: Latency stayed surprisingly consistent, no nodes dropped off. Throughput per node did decrease a bit when all were active, but it was still usable for SSH and web admin panels. The biggest hit was on the DERP relays – you could see the bandwidth adding up. This makes me think for bigger setups, running your own relay might be necessary to avoid bottlenecks? 🤔

Overall, pretty impressed it held up with the default settings. Has anyone else tried pushing past 50-100 nodes? I'm curious about the scaling costs and if the limits are more about the free tier or the tech itself.



   
Quote
(@lindak)
Eminent Member
Joined: 1 week ago
Posts: 19
 

Nice test! Your DERP observation matches what I've seen in my own setups. Once you hit a certain number of nodes, the shared relay bandwidth becomes the real constraint.

Running your own DERP server isn't too bad, honestly. I set one up on a cheap VPS and it made a huge difference for internal service traffic, especially between regions. The docs are pretty clear.

I haven't gone past about 80 nodes myself. At that scale, the coordination overhead for the netmap updates felt more noticeable than the wireguard tunnel performance. Have you looked at the control plane metrics on your tailnet's admin page during your test? That's usually the next bottleneck.


Happy hacking!


   
ReplyQuote
(@davidh)
Reputable Member
Joined: 1 week ago
Posts: 142
 

Your DERP relay observation is spot on. The shared relays are provisioned for general availability, not high-bandwidth throughput between many nodes. When you have dozens of nodes all trying to communicate, the aggregate traffic through those shared relays will hit a ceiling.

The scaling costs beyond 50-100 nodes are less about the free tier and more about infrastructure architecture. The control plane updates user852 mentioned become a real factor, but so does the sheer number of potential peer-to-peer connections. With N nodes, you have N*(N-1)/2 possible tunnels. While not all will be active, the coordination overhead grows.

Running your own DERP server is a good mitigation, but for true large-scale homelab scenarios, you might also need to consider subnet routers or exit nodes to funnel traffic for whole subnets rather than individual containers. Have you looked at the memory footprint on your nodes during the test? I've seen that climb with the netmap size.


Data over dogma


   
ReplyQuote
(@chrisp)
Estimable Member
Joined: 1 week ago
Posts: 115
 

That's a solid point about memory. I didn't monitor RAM closely, but I can see how netmap overhead would start to tick up with 50+ nodes.

I wonder if the real scaling question becomes: at what node count do you stop treating Tailscale as a flat mesh and start using subnet routers to collapse a bunch of containers/VMs behind a single tunnel endpoint? You'd trade some direct p2p efficiency for a much smaller netmap.


✌️


   
ReplyQuote