← Back to Forum
0
Getting Started
LocaltoNet vs SSH reverse tunnel for localhost webhooks
I don't need anything fancy most of the time, just a public URL I can point Stripe, GitHub, and similar stuff at while I poke at a local app. I've got a tiny VPS already, so ssh -R feels like the obvious cheap option, but LocaltoNet looks nicer if I'm constantly changing ports or want HTTPS/custom domain stuff without babysitting nginx again.
For anyone who's used both for a while, which one ends up being less friction in real use? Setup time is one thing, but I'm more curious about the annoying little operational bits, keeping it running, reusing stable URLs, and whether changing the local port 3 times in an afternoon turns one of these into a pain.
Comments (8)
If your local port changes a lot, LocaltoNet is the less annoying daily workflow, that's the one thing that pushed me away from plain
ssh -R. The tunnel itself is simple enough either way, but re-pointing stuff through the VPS every time I bounced between ports got old fast, while the hosted tunnel tools usually make that part a 5 second fix.I mostly agree, but the part that finally decided it for me was URL stability. With a VPS tunnel I kept ending up with little bits of glue around systemd, Caddy, and cert renewal just to make webhook endpoints stay predictable, whereas the managed tunnel gave me a fixed address with far less upkeep.
If you already have the VPS anyway, one compromise is to keep
ssh -Raround for occasional ad hoc tests and use LocaltoNet only for services like Stripe that are fussy about callback URLs.Yeah, that split matches what I ended up doing. The annoying part with the VPS route wasn't even the tunnel, it was all the extra duct tape around it once I wanted request logs, TLS that I didn't have to think about, and something that still worked after the laptop went to sleep because apparently I enjoy inventing chores for myself.
One thing I'd ask is whether LocaltoNet lets you remap the target locally without restarting the whole thing, because if you're bouncing between ports all afternoon that's the sort of tiny quality of life thing that decides it for me.
The deciding factor for me was process supervision, not the tunnel feature set:
ssh -Ris fine until you need autossh, a user service, and sane restart behavior after suspend or network flips, then it stops being the "simple" option in practice. If LocaltoNet can reconnect cleanly and let you retarget without rebuilding the public endpoint, I'd take that for regular webhook work every time.That was my experience too, the reconnect behavior is where the homemade route started feeling fussy. One tiny thing I'd add is header handling, I had a couple webhook tests act weird behind my VPS setup until I cleaned up forwarded host/proto details, and thats exactly the kind of nitpick I don't want to revisit when I'm just trying to test a checkout flow.
If anyone's checked recently, does LocaltoNet preserve the original request info cleanly enough out of the box?
Yes, and that original request info bit is exactly why I'd lean LocaltoNet for webhook stuff, Stripe/GitHub tend to be way happier when you don't have to remember which proxy header tweak your VPS stack needed this week. I can live with
ssh -Rfor random one-off sharing, but for repeated webhook testing the boring, already-wired HTTPS path has honestly saved me a bunch of head scratching.Same here, the thing I ended up caring about was whether the public endpoint stayed the same while I swapped what was listening locally. If LocaltoNet lets you keep one URL and just retarget from 3000 to 5173 or whatever without a bunch of clicks, that'd be a pretty big win for me.
That’s the part I’d want confirmed too, keeping one public address while flipping the backend port is way more important than it sounded to me at first. Since moving over, I've gotten a lot less patient with little proxy edits and service files, so if LocaltoNet can switch targets without touching DNS or the cert side, I'd probably pay for the convenience.
Please log in to post a comment.