tomspark wrote:
Reasonable ask, and you've already hit the catch: that networkmode edit works but gets wiped on every update — same rough edge people run into with manual container tweaks — so I wouldn't lean on it as a permanent setup. A dashboard toggle to route a chosen service (Tailscale here) through the VPN is the right way to do this, and I'm logging it as a feature request. One honest heads-up if you do wire it up manually: once Tailscale's exit traffic runs through gluetun, a VPN drop takes your exit node down with it — that's the tradeoff of the kill-switch. I'll post when there's a proper toggle for it.
tomspark wrote:
Thanks for the nudge, and sorry to keep you waiting. No build to share yet — it's flagged and on the list. It's tied to a bigger piece we're weighing: a proper way to set per-app options (routing one service through the VPN, pinning resources, that kind of thing) that survive updates, instead of the manual networkmode edit that keeps getting wiped. I don't want to give you a date I can't stand behind — it's a real chunk of work and I'd rather do it right than bolt it on. I'll make sure it stays in front of the dev side. Thanks for backing the project and for the patience.
Chris wrote:
Sixty days late, and you should have heard this from us — sorry. The bigger piece Tom was weighing did ship: per-app overrides. Put your change in state/overrides/tailscale.yml and it merges over our compose on every sudo sparkbox up. That file lives under state/, which upgrades preserve — so it stops getting wiped. One correction worth having: service:sb-gluetun was never going to work, because each module runs as its own compose project. Use networkmode: container:sb-gluetun instead. It needs the media module for gluetun, and sb-gluetun must already be running. Being straight with you: the toggle itself still isn't built, and dashboard-over-Tailscale drops while routed this way. — Chris