[corford]

Or just maintain a $2.50 Vultr instance and on your dev box create a bash alias for a command that sets up a reverse ssh tunnel to it.

Then all you need to do is a one time setup of nginx on your Vultr (or DO or whatever) box to accept incoming webhook requests from e.g. stripe and proxy them down the ssh tunnel to your dev machine.

With the above in place, you'd literally hit one button on your keyboard to establish the tunnel and spawn whatever local process you want to receive the webhooks and... voila. It's secure, gives you logging and works from anywhere without needing any external port forwarding.

[Lazare]

Yes, but, ngrok is cheaper, easier, faster, and provides some additional niceties that this setup doesn't. What's the advantage? (Plus, now I have a VPS to maintain...)

[corford]

It's more secure, easier to audit, removes a hard dependency on ngrok, gives you a static IP that never changes and you get more flexibility (plus you can share the same box amongst all your dev team if you wanted - you'd just assign different port combos to each team member). In terms of maintenance, apt-get update && apt-get upgrade in a daily cron job is largely all you'd ever need...

Agree none of that may be worth it in your case. Personally, I don't think there's anything wrong with ngrok in certain circumstances. The above is just an alternative approach with different trade-offs/benefits.

[Lazare]

> Agree none of that may be worth it in your case.

It's not that I don't think that it's worth it, it's that I'm still not seeing the advantage.

"More secure", if I assume that throwing a VPS up on Vultr, and adding apt-get update/upgrade to a cron job is more secure. "Easier to audit", if I assume that I go to the trouble to somehow make it auditable. "Removes a hard dependency on ngrok", if I assume that my planned usage of ngrok was actually a hard dependency (it's not). "Gives me a static ip", if I assume I have the slightest use for such a thing when my planned use is "spend a couple hours hacking on a webhook handler". "Can share the same box among multiple devs", if I assume that would give me any benefits.

> The above is just an alternative approach with different trade-offs/benefits.

For my specific case, it seems more like an alternative approach which is almost as good, almost as easy, and almost as cheap.

The big question mark is really about security; but in principle you should be using both solutions as an ephemeral tunnel for sending sandbox data from a cloud service to a local dev environment. Even if I assume every single bit of data that I sent through ngrok was being read by an attacker (not a bad assumption!) I'm fine, because no production data, keys, credentials, etc., went through it.

You're quite right that ngrok is doing a very, very basic thing that you could duplicate, if you wanted to, very easily. But it's free (for the sort of use being discussed here), and easy, and the replay/logging is more useful than you might think.

[corford]

Like I said, different trade offs for different circumstances/tastes.

Personally, I prefer a generic solution that doesn't rely on a specific third party for something as everyday as tunnelling internet requests back to my dev machine. I value that more than the replay and zero-maintenance benefits of ngrok.

Doesn't mean my approach is better than yours. Just means my approach suits me more :)

Edit: btw my earlier post should have read "easier to debug" rather than audit - sorry.

[hamandcheese]

Using ngrok does not make it a hard dependency.