Hey folks,
Curious if anyone here is running Tailscale at a real scale in production. I'm talking 100+ nodes, not a homelab or a small dev cluster. We're evaluating it as a potential mesh VPN layer for a microservices backend that's spread across hybrid cloud (AWS, GCP, and some bare metal).
I love the simplicity for smaller setups—just `tailscale up` and you're golden. But I'm hitting some questions when I think about a larger deployment:
* How's the control plane latency/performance when you have that many nodes? Do you notice any issues with coordination or reconnection storms?
* We're heavy Docker users. Is anyone running Tailscale in a containerized sidecar pattern at this scale? I've tested it with a custom image, but I'm wary of the overhead times a hundred.
* The ACLs are fantastic, but managing them for hundreds of services and users feels like it could get gnarly. Any pro-tips or patterns for keeping that maintainable? Are you using the API to sync ACLs from a source of truth?
Here's a snippet of the Docker Compose setup I've been prototyping for a service:
```dockerfile
# Dockerfile.tailscale-sidecar
FROM tailscale/tailscale:stable
COPY start.sh /usr/local/bin/
CMD ["/usr/local/bin/start.sh"]
```
```bash
#!/bin/bash
# start.sh
tailscaled --tun=userspace-networking --socks5-server=localhost:1055 &
tailscale up --authkey=${TS_AUTHKEY} --hostname=${TS_HOSTNAME}
# Keep the container alive
sleep infinity
```
It works, but I'd love to hear from someone who's been down this road.
Also, any gotchas with subnet routers or exit nodes when the network gets this big? We're considering using it to replace some legacy site-to-site VPNs.
~d
Great question, and that snippet looks like the right direction.
We've been running a sidecar pattern in Kubernetes (around 150 pods) for over a year. The overhead per container is minimal - it's just one extra process managing the tunnel. The real trick is making the start-up graceful. Your containers need to wait for Tailscale to be fully up before starting the main app, otherwise they'll fail to resolve internal mesh addresses. We use a simple health check loop in the start.sh.
On the ACLs, yes, it gets complex. We treat them like infrastructure code. All ACLs are defined in a single YAML file in a git repo, and we use a CI job to push updates via their API whenever there's a merge. Tagging nodes with clear, functional labels (like "service:payment-api" or "env:staging") is the key to keeping the rules readable. You can then write ACLs based on tags, not specific node names, which scales much better.
Stay factual, stay helpful.