A lot of people seem to be a bit confused about the point of ngrok, why it's useful, how much it costs, etc. Let me try and help out. :)
For me, the killer feature for ngrok is testing/developing webhooks. You install ngrok in your dev environment, start it up, then point the stripe/slack/whatever webhook your working on at the generated URL.
ngrok will 1) proxy that request through to your dev environment 2) log the request 3) log the response 4) let you replay previous requests. It could not be more helpful for developing webhook handlers, and has literally saved me hours of work in the last couple of months alone.
Finally, the free tier is all you need for that; it gives you a unique ngrok subdomain which changes every time you start the tunnel and some (generous) usage caps, both of which are fine for this usage.
People pointing out the potential security issues are correct, but that's an argument to be careful and think about what you're doing. Besides, what's your proposed alternative? Because most of the obvious ones have equally troubling issues.
That's is exactly how I used it too: develop locally, but expose it to a payment provider's webhook call through ngrok. It's very convenient, and has the added advantage that you can replay the webhook call without going through the entire process at the payment provider.
I actually tried using it in this manner recently to test paypal IPN notifications, but it seems like paypal denies the SSL installed on the ngrok urls. I had to setup a domain with letsencrypt instead.
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 :)
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)
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.
> 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.
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.
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.
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.
> 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.
> 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.
>>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.
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.
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.
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.
Makes me sad to see all the negativeness towards this service, which clearly works and serves a need some people have.
Yes, there are alternatives, but I hate when people jump to dismiss service like this, without fully considering what issues the proposed alternatives have. Obviously it is ok to mention the alternative options, but that can be made in constructive way.
Let's celebrate the fact that somebody has built and released something and even seems to have a business model to support it. Instead of complaining about 5-20 bucks per month, try to figure out how you could channel some of your corporate multimillion IT budget to this fellow hacker. Wouldn't it be great if building and running this kind of small solutions would be actually a viable way of making living?
Literally the most terrifying service for any security-minded operations-focused person. Wonderful tool, interesting and useful in a dizzying array of aspects - but dear lord, I've had some real horrific moments when users told me that they installed it to allow access to their (private) repos for testing.
If your users have to resort to this they are not getting the appropriate support they need.
If your users are productive, chances are so is the company that pays both your salaries. If your users have to fight their infrastructure people to get their jobs done, you company will fail to effectively compete against those companies that don't.
It astounds me that so few security people understand what their purpose is: Your purpose is to assist the company you work for to keep on existing, and even make a profit. If you disempower those that are most effective in helping the company do what it does you're effectively destroying your own livelihood, and everyone else that is dependent on it.
Uh, no. The purpose of a security team is to prevent data from being exfiltrated from the company's control. Passwords, PII, HIPPA/other-compliance-controlled stuff, source code, etc. are all at risk of being stolen at all times, which means that security is a game of constant vigilance. And since everybody has at least a bit of this data under their control, this means that everybody is involved with security. (At least two of my past employers have had the motto, "Everybody is on the security team.")
Productivity means nothing in the face of data exfiltration. You only have to fail once at guarding a password in order to be completely compromised. If we seem tightly wound, it's because we have fully internalized and grok the stakes of our efforts and the entailment of failure.
"Our infrastructure sucked, so I used an insecure tool to leak our credentials to third parties, because I couldn't be productive otherwise!" is not really a valid excuse in this light, since there's no amount of productivity which offsets data exfiltration.
None of that matters to the company if in protecting it you tie staffs hands sufficient behind their back that the company fails.
And you harm security if you're being sufficiently inflexible that staff see it as essential to circumvent your security measures to be able to do their job. Because they will almost certainly manage to do so.
As such, if you hurt productivity enough, you are also going to be failing at protecting company data by making people find alternative solutions, and you're not likely to get permission to go far enough to stop it unless you're working in a field where security clearance is the norm.
That mindset, while successful from the security perspective, can result in the slow death by strangulation. Ensuring the success of a company should always be your #1 priority, security is an important piece in ensuring the success of a company, but it isn't the only piece.
If you're dismissing it as a security nightmare without considering why someone would want to use it and trying to figure out how to make it work or come up with alternatives, then you're failing your mission IMO. There's ways of securing ngrok... you can self host, put it behind a firewall, and whitelist services. It may still open a potential attack vector, but so does the mere existence of connecting to the internet. It's a balancing act, we should all be familiar with.
Pretty sure a lot of people using this don't even have a "security team." They likely have corporate IT that takes 2 weeks to add a DNS entry. Something complex like mapping a public IP to a dev server would take an act of $DEITY.
> If your users have to resort to this they are not getting the appropriate support they need.
I don't see where this follows from. "private repos" and "testing" implies "local testing" for me. If that implication does not hold, the development workflow is seriously screwed. (Don't tell me there is no money for a local test setup when you have dedicated IT security.)
And in my experience, more often than not, it is screwed because someone decided to use some other flashy tool without realizing the security implications.
If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends.
> If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends.
Wouldn't that still be the same, considering ngrok is just doing the tunneling. In this case, ngrok is your trusty hoster. You can park your trust into your own VM in Digital Ocean, or you can park it at ngrok.
Surely ngrok doesn't access repo directory and only acts as port forwarding tool. Haven't used it to be sure though, but that's what i'm getting from it.
well, if you've exposed your dev app running on your laptop to the internet, any exploit in your app now works against your laptop endpoint instead of a production endpoint.
your laptop is a very different environment from production: there are probably different protections, firewalls, monitoring, etc in place. additionally, while your laptop (hopefully) doesn't have direct access to production databases, you probably have stuff lying around that you wouldn't want an attacker to get their hands on: sensitive work documents, your Chrome cookies just sitting in a sqlite database somewhere, source code for all the repositories you have checked out locally (not just the one app that has the exploit).
I don't agree that "using ngrok is not a security risk".
What's the problem with exposing port 3000 to let someone demo an app for an hour? By the time someone discovers the exposed address and port, and then figures out how to exploit the service that's running, I'll have already shut down the service.
true, maybe there's no problem for your use case. using something like ngrok is a gamble:
if the only thing on the line is low-value things like whatever is on your personal laptop (or even whatever is on a spartan vanilla ubuntu VM that your app is running in), then maybe it's not a very big gamble.
if the laptop has corporate secrets on it or it can be used as by an attacker to pivot into company internal systems through the VPN you're also connected to, however, that's a completely different story.
Thanks for creating ngrok. Sharing my experience and use case:
I tried ngrok (and localtunnel) two months ago to show a localhost WordPress site. Both failed because WordPress uses absolute links to reference css, js and img assets.
So the site was visible under whatever.ngrok.com but the assets where still linked to localhost. I read the FAQ at https://ngrok.com/faq#wordpress and tried all the mentioned plugins plus some other hacks. None did work. In the end I wasted almost one day.
I ended up renting a Simple PHP Hosting for 2 days to which I cloned the site. Which was also half a day but only cost me 2 € (site was online only for 2 days or so) and in the end, it did work.
One is a big proprietary blob of mistrust and the other is localtunnel? Sorry if that sounds harsh but it's a shame I can't build and make sure that everything is above board.
Good on you though , that apart it seems a great idea well implemented. Easy to throw stuff up for prospects/clients in an agile way without having to talk to devops.
Why not free as in bird? It is already free as in beer.
I stopped used ngrok because after opening the tunneled URL a few times it started saying "too many HTTP requests" on a Wordpress project. It is common for those to have many images/scripts/styles so throttling by number of requests makes ngrok unusable, now a happy localtunnel user.
ngrok has connection limits, but not request limits. Perhaps your server wasn't using keep-alive connections? It's mentioned in the pricing FAQ (scroll down a bit from this link):
Yeah my bad, it probably says "connections limit", I don't have time to figure out my way around it; other devs may do thought. I just want to fire it up and start working.
Not really, it was just an example; you can leave blank the Wordpress theme index.php and that way it makes only that request; the problem is more general: Real web sites are full of content (AKA. full of requests), that's just how it is.
What is the point of ngrok besides being a paid for third party single point of failure and security liability ?
The website says it is for exposing a local server behind nat or firewall to the internet.
1. local server is by definition supposed not to be exposed to the internet
2. to expose a server behind a NAT there's this thing called port forwarding
3. to expose a server behind a firewall there's this thing called a DMZ or correctly configuring the firewall
There's a lot of data collection happening, the privacy policy is leading on the weak side. Is there an option to opt out of all this data collection so when comes the time to disclose, sell, give or share data I can be guaranteed my data or any data generated by my use of ngrok will not (you can't share something you don't have)?
What makes ngrok better than a free software tunnel solution I can use by myself with no third party involved ?
Think of a front end developer working on a mobile site. Now, in an ideal world everyone would know how to set up an SSH tunnel, but let's be real here, even you probably have to look up the exact flags you're supposed to use every time you want to set up one. Combine this with the need for a publicly accessible server somewhere, and it should become somewhat clear that many simply do not possess the skills, resources, and/or couldn't be bothered to go through the trouble. With ngrok, you just download a single binary, make it executable, and you're ready to go. It's easy enough for most, although I suspect a GUI would further increase its reach.
Corporate policies often prevent employees from connecting their private phones to the internal network, so simply accessing the internal IP isn't really doable. You might be able to apply to have your device whitelisted, but that may take days, perhaps weeks, and even if you're approved, it doesn't really help as you cannot show your work to others (e.g. your team lead) without having their devices whitelisted as well. You might argue that everyone should have a company-provided phone with access to the network, and that's certainly a solution. Realistic? At most companies, probably not. You might have shared phones but who wants to work like that? Plus, there are developers who feel more comfortable playing with their own phones anyway. Regardless of which and whose device they have, they'd still be limited to WiFi only. Sure, you can emulate slower networks, but that's one more thing to know about. With a tunnel, you can see how the thing you're working on feels over a real 4G connection with no additional configuration. All this while developing locally with no need to waste time deploying to a separate environment.
That's just one use case where ngrok shines. The fact that you do not need to "correctly configure a firewall" is a selling point. Does it circumvent the firewall and expose machines on the internal network? Yes it does, and that's certainly a concern. But since people are people, perhaps you should have a similar, easy to use service available for your developers so that they don't have to resort to third party services you have no control over.
I'm not sure how you've interpreted the post that way. The point of that one specific thing was nothing more than to bring attention to the fact that even users who do have the skills to do this all by themselves often can't recall how exactly to get it all going without googling or reading manpages a bit, and that people who are less familiar with these things would be even less likely to know how to set up an SSH tunnel properly, or perhaps even know about them.
For example, even though I use SSH tunnels quite often, and can in fact remember the flags, I sometimes don't remember if the local or remote port came first. A minor issue for me perhaps, but I'm sure you can imagine someone getting stuck at some point, and having to bother a team mate to check what's going on, which is an entirely avoidable waste of time. You also have minor ops overhead for making sure the tunnel servers stay up and running.
In the end, aren't nearly all tech businesses about improving the user experience in some way? For example, you could set up your own mail server (and deal with the issues that come with it) instead of using Mailgun/Sendgrid, or take a taxi (or drive) instead of using Uber/Lyft.
It's intellectually dishonest to cherry-pick that and then ignore the part about having to have a server with DNS, fixed IP, public SSL configured, etc.
Can you speak to security? I love using ngrok to test stuff in dev that requires SSL without having to setup up SSL. Of course that means it's running through your cert. Obviously one shouldn't run anything protected through your system, but what is your visibility into that traffic?
Why not just setup SSL in your development environment? It's seriously not that difficult at all, there's zero reason to use Ngrok (although I'm sure it does what it does very well), plus asking this question after you're already paying is kind of silly.
So how exactly does the tunneling service work? Is it something like LogMeIn Hamachi? From what I understand, you need an intermediary server between two nodes in the network to create a connection like this. So do you have to pay hosting costs to create this pipeline?
Yes that's correct, ngrok hosts servers around the world that serve as 'relays' which accept connections on your behalf and then copy the bytes through to a persistent connection initiated by the ngrok client. It's the same principle as a reverse SSH tunnel
”I want to expose a local server behind a NAT or firewall to the internet.”
This is genius. It immediately simply told me exactly what your and service does. A few common, short examples beneath that would also be great. I would see this being great to show off an app on the development branch to a client in a meeting.
Hey -- great utility! Feature request: a way to kill an existing tunnel. I often forget to take down a tunnel established from a home machine, and then while working on my laptop I find myself locked out. I'd love to be able to optionally kill an existing tunnel and replace it with a current one.
Correct me but there seems to be a free vs. paid plan?
Seems free vs. paid is about reserving/custom domain vs. random one and a lot of security related feature. But the basic tunneling works for free am I correct in that?
Also what does the user really mean in terms of ngrok concurrent user or kind of named seat.
I don't have a question, but I did want to thank you so much for this service. For our usage, which involves lots of disparate services sitting in all sorts of places, it makes it quick and painless to shuffle around our graph of connections between them for development, debugging, and production testing.
It's a service that, for us, is worth its weight in gold for all the configuration and maintenance we don't have to do. It's definitely one of the first tools in our toolbox we reach for. Thank you very much for ngrok!
Do you mean: "why can't I set up port forwarding on my firewall, then create a DNS record for my domain that points to my current IP, then wait for that to propagate around the internet before I can use it, then do it all again when I move from e.g. office->home or my IP changes because of my ISP"? No reason.
Man you'll be floored when you'll learn that 90% of people going online never have a "real IP". Servers see the IP of the NAT's most of the time. ngrok doesn't require an outside-accessible IP.
You're still going to need to set up port forwarding on the firewall of each site you develop at, and if you use DHCP with no static assignment... more fun.
Honestly it depends on your use case, port forwarding and dyndns is trivial to configure, but if you're using development time to do it more than a few times then it's a non-trivial efficiency leak
It takes care of NAT/Firewalls, so you can sit on the airport if you wish and share something you work on locally. Even if it's your own home network, you'd have to go through the process of forwarding ports, have a static local and external IP, configure either a web server or a local proxy. I'm in no way affiliated to ngrok, I just think it's an awesome piece of software and use it regularly.
Are you sure about this being possible on airport provided networks ? My experience with airport networks is that pretty much everything is locked down and you can't set up anything from the airport.
It'll work from everywhere that allows an outbound connection. You're right there may be issues if you can't ssh out, but most airport networks I've been on has allowed ssh. It'd be a good idea for them to support tunnelling over SSL too, though.
It will definitely be interesting to see how public internet providers (airports, coffee shops, etc) handle IPv6 in the future. Will they leave their LAN_IN firewall open and leave filtering to the client, or will we keep the status quo and filter at the router?
Used to use your paid version until the new pricing model. I don't use it often enough to warrant paying, so I just setup the old version on my own VPS.
A report's good, but I care more about assurance of the integrity of the software I was running than having Windows Defender not quarantine my stuff. My build server has been remote-inaccessible all week when a simple 'no compromise of binaries that I know of, quite sure it's a false positive' would have sufficed.
Love it for developing anything using webhooks and also hybrid mobile apps (I have my app pull the JS from the Dev box I'm working on via ngrok without having to rebuild the app or deploy the code anywhere).
I almost forgot how useful it was for working with webhooks! One of those things I forget about until I've been banging my head on my desk for a couple hours.
Nice tool, but without committing for annual billing (which I don't intend to do, not for the first year of usage) it's $10 a month. My internet connection, my mobile plan, my Photoshop & Lightroom subscription, a huge collection of music (Spotify), 3K~5K movies and TV shows (Netflix), etc., all cost approximately the same. I mean, sure, $120 a year is pocket change for somebody using Ngrok professionally, but that's still super disproportional, compared to, say, monster of a piece of software like Photoshop. I'd probably subscribe for $2, but otherwise, IMO, frp [0] on a $3 VPS [1] is better value, with the extra benefit of being FOSS and having zero limits.
You can use ngrok without paying, you just get weird domains like n56897as.ngrok.com (this is off the top of my head, idk how close I got to a real one). This works fine most of the time.
I came here to mention Scaleway ARM servers which cost 3/mo with unlimited bandwidth. With reverse SSH tunneling, there's no need for a dedicated service.
The combined cost for me is enough that it’s cheaper to rent a dedicated octacore xeon with 16G ram, 250G SSD and 1TB HDD and unlimited traffic with a 1Gbps line[1], and run my own services. In fact, I pay less than 50% of what I’d pay for the services, I have far more performance, and can offer these services to 10 people at no cost, and still come in better.
These services might be worth it if you’re in SV, but 10$/mo is something different to a person earning 300k$/year in SV, and to a student earning 8k$/year somewhere else.
Yup, that’s exactly what I’m doing now. Transcoding video, even on the fly (after I had several situations where lag with Twitch was massive, and with nginx-rtmp and nginx-hls it was nil)
People having bills is irrelevant to consumers. If your product pricing relies on pitching a sob story about how you're a small indy developer, you've failed.
This comes off as really petty. It's good software that saves you a ton of time and effort. You spend $10 without thinking about it in tons of other places. If anything I think he should charge more
The amount of time spent thinking about this and setting up an alternative vs just using ngrok, when billed at your market hourly rate, is far more than $10. This shouldn't be a real issue.
"Time spent thinking" counts for Ngrok too: comparing alternatives is a pragmatic thing to do, before pulling a trigger on something. Not to mention that this is all part of reading Hacker News (I found frp through some previous thread).
Setting up a VPS with frp on it would take 30 minutes tops (assuming that I don't already have one and that I'm in no hurry). Even if I was some big shot, doing $120 an hour, that's just 60 / (10 - 3) = 8.5 months of Ngrok. These $60 would be a good investment by my book.
But I'm not counting pennies here, I'm merely pointing out that the pricing is unreasonable. I can afford it, but its usefulness per dollar is disappointing.
For example, compose.com can host a Pg database for $17, one master and one slave, with automatic backups, a rich control panel, competent customer support, batteries included. It's maybe only twice as expensive as replicating the setup on your own (which would take literally weeks for a single person), and brings almost as much value as hiring a sysadmin. And then there's Ngrok, 3-4 times as expensive as DIY, while saving you a total of 30-60 minutes of one-time effort. And costs more than a half of a pretty great Pg server. Ridiculous.
Props to the people behind Ngrok, if they're in the black with this pricing. Good strategy/marketing.
PSA: if you want to provide remote access to a local service, but don't want the potentially-terrifying security implications, use Tor Authenticated Onion Services (AKA "HiddenServiceAuthorizeClient" [0]).
On a machine on the LAN, install Tor and set up an authenticated onion service, and point it to the desired endpoint. In order to access the service, clients need a manually-loaded encryption key (and Tor, of course). Without this key, nobody will be able even to discover your endpoint, let alone actually connect to it.
A fantastic open-source javascript alternative is localtunnel (https://github.com/localtunnel/localtunnel). I've used this more often than ngrok after ngrok became a paid service.
ngrok is open source as well: https://github.com/inconshreveable/ngrok
I've used localtunnel before but due to some misbehavior on windows (which i can't remember anymore), switched to ngrok.
I see some people arguing that "you should use a dev/staging environment with a public IP" instead of having ngrok tunneling traffic directly to your local dev box.
When you're editing HTML/CSS, you don't have to run a deploy script before checking how your markup renders. Ngrok gives people writing web services the same convenience when dealing with requests from a 3rd party on the Net.
It is the equivalent of saving your HTML/CSS source files and instantly seeing the changes when you reload your browser.
I just wrote a little proof-of-concept Alexa app that crawls HumbleBundle ('Bundled Goods', very much beta quality at the moment) and ngrok was invaluable for developing it quickly.
Ngrok is the coolest tool I use on a pretty consistent basis. Developing webhooks locally is usually what I use it for, and the web interface replay capability is amazing. The creator gave a great talk on why he built it and how it progressed over the years: https://www.youtube.com/watch?v=F_xNOVY96Ng
I've used ngrok for a while now, and I love it. I used it just last night to test out some webrtc stuff I was doing. Was able to get friends from around the world on video chat served from localhost within seconds.
It's also super handy when building webhooks, you can use the unique URL to test out apis without having to deploy anything. I can't rave about it enough.
The title of this submission makes it sound like a selling-fridges-to-eskimos scam product - you need to read quite a bit to find out what's it actually about and that it solves (or simplifies) an actual use-case.
I think a better comparision is with DynDNS services: It sets up a public host connected to your own machine - but unlike DynDNS, the host doesn't point to your machine's IP directly. Instead, requests are routed through a proxy/tunnel, so your machine can be kept behind a firewall and is only available through the public host.
(I figure, the proxy allows for some more neat tricks, such as restricting ports/urls/etc or holding requests open while your machine changes IPs.)
For a part-time programmer Mechanical Engineer, it is such a gratifying task to use ngrok. I first came across it a couple of years back. Great Project, great development, open sourced and well written in go. https://github.com/inconshreveable/ngrok/tree/master/src/ngr...
It takes two seconds to deploy an application in the evening from my kitchen table, check it also on my mobile and the next day access it from work also and show it to co-workers.
I've been on the free tier for a while and have been meaning to upgrade to show support for such a great service. Seeing this post this morning reminded me. Upgraded for the year!
It's possible to roll your own ngrok clone via SSH tunnels, a publicly-available server somewhere, and autossh. This is basically ssh-tunnel-as-a-service.
Never used it, what's the difference between ngrok and using DMZ with port-forwarding? are they the same thing? What's the technical advantage other than it is easy to use? I can port-forwarding easily on my router to expose whatever port to the public, why do I need ngrok?
With a DDNS + Port-forwarding you can easily have what Ngrok provides? or am I missing something?
For me ngrok spares me all the talk with infra team to have the public port exposed and the setup of a test server just to for a mere 10 or 20 calls I need to receive from some new service I am checking.
I use it to prototype webhook entry points, and only need to receive a few call to have a quick confirmation I receive what I expected from the docs.
Once I have enough info I can start building a more solid project and jump through all the hoops to have it on a real server with a subdomain and a public facing interface and all the security needed etc. I'd just hate to go through the whole process first, only to discover the service is unusable for my purpose, or the data I receive doesn't make any sense.
1) My university blocks LogMeInHamachi which is the main tool i've tried to get around hosting behind a NAT. Will this likely be blocked too, or is it not possible to tell without trying
2) Is there any costs associated with this. Do i ever need to pay
3) Does the person connecting to my server also require a special client or does this appear to them as any standard connection would.
Free Plan
For quick demos and other simple tunneling needs.
* HTTP/TCP tunnels on random URLs/ports
* 1 online ngrok process
* 4 tunnels per ngrok process
* 40 connections / minute
It seems the answer was there in the site and you guys answered between me thinking about it and posting the question. Should have refreshed before submitting my question :).
I'd rather pay a very small amount for something that does exactly what it says on the tin, every time, than some sketchy app that maybe works, or monetizes in weird ways by selling me or my traffic or whatever.
It's a professional tool with real use. That's worth money.
I really like ngrok. I use it a lot. I just really dislike how the TCP tunnels work. With HTTP you get a unique subdomain which makes it harder for people to just scan and connect. With TCP, it's always 0.tcp.ngrok.io, so you can just scan that domain and connect to anything that's open.
I'not currently using it (so I did not test this) but seems like you have the option of custom TCP as I can see here https://ngrok.com/product#pricing for Pro account.
I have been using this for quite a while and it's really useful.
Even though I have VPSs available, where I could make a SSH tunnel, this is simply way more convenient, so I end up using ngrok a lot for development
long time ngrok user here. used several times to show my prototypes to the others. It's simpler than deploying on heroku (or anywhere actually), and is without restrictions ofc because you use your own hw.
Even with IPv6, you might get issued a work laptop that has software installed to randomly delete some of your files.
Well, yeah, of course, incompetent or malicious company IT can prevent you from being a productive developer and you may then feel the need to work around that, that is largely orthogonal to whether the world is using IPv6 or not.
For me, the killer feature for ngrok is testing/developing webhooks. You install ngrok in your dev environment, start it up, then point the stripe/slack/whatever webhook your working on at the generated URL.
ngrok will 1) proxy that request through to your dev environment 2) log the request 3) log the response 4) let you replay previous requests. It could not be more helpful for developing webhook handlers, and has literally saved me hours of work in the last couple of months alone.
Finally, the free tier is all you need for that; it gives you a unique ngrok subdomain which changes every time you start the tunnel and some (generous) usage caps, both of which are fine for this usage.
People pointing out the potential security issues are correct, but that's an argument to be careful and think about what you're doing. Besides, what's your proposed alternative? Because most of the obvious ones have equally troubling issues.