Hacker News Reader

Comment by planetix | Hacker News Reader

> Besides, what's your proposed alternative?

Setup a proper development environment that mirrors the production environment?

If you don't have a static IP that's internet-accessible, and that which you can arbitrarily point your domain to, how would you go about doing this?

Some, if not most, services won't allow you to redirect cold to an IP address, they want some domain of sorts. There are alternatives, but I think "setup a proper dev environment" alone misses the point of what ngrok does.

The 'easiest' alternative I've tried before was to VPN into my Linux box to get a static internal IP, use a spare domain for the webhook then internally redirect the webhook traffic to my local machine. In the end I'm achieving what ngrok is doing (and none of it involves setting up a proper dev environment, cos I would already have one anyways), but I'd like to hear of better alternatives :)

Surely you've heard of dynamic DNS?

nip.io and xip.io even could be used, but that won't help if there's no static ip.

of course you can portforward your ip via vpn or ssh tunnel. And that's would be the exact equivalent of ngrok, but with way more time and frustration to set it up.

oups, meant "routable" instead of "static"

Ngrok also works without port forwarding through a router

Surely you've noticed this:

> don't have a static IP that's internet-accessible

I am one of those people :) I don't pay my ISP extra for a "real" IP address, so I have literally no way to receive incoming connections from the internet into my home network, it's all behind their NAT.

You don't need a static IP.

You do need a public IP.

And you probably have one at the office, or you surely do at your hosting service or ... But if you really don't then a VPS with unlimited data is cheaper than ngrok basic plan - and a lot more useful.

The whole reason why I VPN into a box is that it has a static and publicly accessible IP address. Interesting that all the other alternatives proposed basically do the same thing. Point to an URL you control, and proxy traffic to where you want.

i tend to fire up reverse port forwarding with ssh + special subdomain + ask nginx to proxy to the reverse-forwarded port on that special subdomain to resolve this, obviously you'd still need a static and public ip somewhere, but any ssh-accessible host will now do.

it's a bit of setup, but works quite well once set. does _not_ provide the features ngrok does of replay, etc, but at least it's 100% your own infrastructure.

edit: to clarify: no reason why it should be a special subdomain, i just use beta.mywebsite.com, just something that belongs to you and is globally dns resolvable, could be mytestdomain.com for your use. you can skip nginx if you don't mind binding to port 80 directly (i.e: no webserver already exists on that machine)

I do exactly this. I also have it set up with let's encrypt so that the Webhooks are encrypted.

Locally, I also mirror the LE keys and add a hosts file entry for the test domain to localhost.

This means I can test locally with proper ssl certs.

+1 original reason i did it was so i can have the LE cert to test a slack bot i was developing (they require webhooks have SSL to do that)

> but at least it's 100% your own infrastructure

This is probably a good thing for security. But for the use case of development against third party services, it seems like an unnecessary constraint.

That's staging, usually there is only one per project.

As a developer, ngrok makes it really easy to show-off your feature branch to customers/rest of the team, regardless of your location. And you're not dependent on having a CI deploying to per-branch environments.

Your dev environment is never going to be identical to your production environment, because you don't write code directly in production. Test and acc should be identical to prod, but for dev that's pointless.

Yes, I have that. How does that help me quickly iterate on getting proper handling for inbound webhooks from Stripe?

Stripe wants a URL to send the payloads too, and my proper development environment is (not surprisingly) running inside a vagrant on my dev machine inside our office LAN. I could open up a port on our firewall and forward it through to my laptop but:

1) ngrok is easier

2) ngrok provides additional features

3) This has every drawback ngrok has and more

4) None of this has anything to do with having a proper dev environment. :)

Can't reply so an edit: Yes, ngrok is actually easier than port forwarding. Plus it has logging and replay.

I'd imagine that for this purpose a proper dev environment would well be isolated your "office LAN".

ngrok can not possibly be easier than port forwarding.

Except it is. By far. And it works everywhere. I could do webhook development on a plane.

ngrok is way easier.

Run `ngrok http 3000` or whatever port your app is running on and you're done. Now you have both an HTTP and HTTPS endpoint that you can publicly access.

Some webhook providing services also require HTTPS. ngrok gives you that right off the bat. Setting up self signed certs and running nginx, or faking a FQDN and using xip so that you can register a real certificate seems like overkill if all you want to do is test a webhook.

ngrok is also perfect for live demo'ing apps to clients.

> ngrok can not possibly be easier than port forwarding.

Oh come on, of course it can. I use port forwarding myself, but ngrok literally makes testing remote webhooks as simple as running "ngrok". That's it. It's definitely what I recommend coworkers who just want a quick solution to test out 3rd party service integrations.

Um, just signing up for ngrok - 10 times more effort than port forwarding. Then you have to learn how to ngrok. And thats that's before actually figuring out what ngrok really is, how sensible it is to route data through a third party etc. etc. etc.

For people without public IPs - why not just learn how to setup an SSH tunnel instead? Similar effort, save it as a script. Boom, you actually learned something useful too.

"learn how to ngrok" "figuring out what ngrok really is"

...really? You're trying very, very hard to dislike this tool and it's kind of funny. What is the objection to it, exactly? It makes a task easier. You don't have to use it, but others can.

If you're proposing SSH tunnels as an alternative, where am I SSHing to? I need a publicly accessible remote box. So I'll need to set that up, then set up an SSH tunnel. Or, install a CLI tool and learn one command.

Apparently, the gp simply believes that "port forwarding" is the be-all/end-all, and anything else is inferior.

I've used ngrok because it was something that I could generally count on other people being able to install. I can't always be sure they understand how to do some of the more advanced stuff being suggested in this thread (they may not have permissions, or time, or technical knowhow).

I don't dislike it, at all. People seem to like it and I have no reason to distrust that. And if you really don't have any box to SSH to and can't see any use of a VPS other than an SSH tunnel then fine - ngrok is probably great.

But... If the only reason you do this is because you haven't got a clue about what dynamic DNS is, as many here seems to do, or you feel that setting up a SSH tunnel is complicated then I'm going to assume that you have no clue about the security implications of using something such as ngrok (or an SSH tunnel) to your local machine - and should probably not under any circumstances be allowed to set one up at your office.

That assumption might be wrong, but the discussions here only reinforce my belief that the niche for this (perhaps excellent) tool should be extremely small even within the HN audience. And that it isn't (currently at the top of the front page) is quite concerning. It solves a very small problem that I can solve with tools I (and most people on HN) already have installed - without going through someone else's cloud. Without registering for yet another service (bad or good, doesn't matter).

I'm questioning that there is a need for this among the HN audience. And I'm questioning that most people that have a need for it should be allowed to use it. Whether the tool is awesome or not is besides the point.

I have no clue about the security implications. What can go wrong if I use ngrok for my development environment that receives development webooks? Please enlighten me.

> how sensible it is to route data through a third party

Maybe don't keep sensitive data on your dev machine?

I'm not sure you've ever used ngrok. There's no sign up. You literally just run the binary with a port as a argument and that's it. It also gives you access logging that you wouldn't otherwise have.

So it's not similar effort, especially given that I use it on my corporate network where doing port forwarding more assuredly would be difficult and problematic.

>>but ngrok literally makes testing remote webhooks as simple as running "ngrok". That's it.

Not quite. If you are on the free tier, you also need to change your stripe/slack/whatever webhook URL to the new endpoint URL it gives you each time you run it.

Not a huge hassle, but it's worth mentioning.

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.

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...)

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.

Using ngrok does not make it a hard dependency.

> 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.

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.

Reply on news.ycombinator.com