Ngrok Alternatives
github.com
github.com
But for the price of ngrok I'm paying for a domain and a 2gb ram/2 CPU VM on hetzner and using SSH tunnels to nginx reverse proxy.
And setting up a shared server for a team with subdomains is just 10 mins of config changes per user - no way they can justify the cost for me.
If it was some symbolic price like 20$/year then I wouldn't bother, otherwise I'll take the VM I can load other random dev crap to when I need it.
And you're using standard web tech to set this up - if you aren't familiar with something required to set this up you will be better off learning it in the long run (if you're the target audience for ngrok) : VM setup, nginx, reverse proxy, SSH tunneling, let's encrypt, domain management/DNS - all valuable fundamental skills to acquire on a small project.
But I'm interested in a different demographic. Someone who wants to run their own blog, or run a Nextcloud server for their family, or host albums from their photography work shouldn't need to understand DNS, TLS certs, IP addresses, ports, etc. They should be able to install an app on their laptop (or old Android phone, or Raspberry Pi), go through a quick OAuth flow to tunnel out of their home network, and have their content available to the rest of the web.
Obviously there are UX and security concerns, but these are solvable problems.
The issue is that DNS and registrar services are fragmented by design, and there doesn't seem to be a standard DNS API that would make it easy to simply say"select your domain registrar" and use that to start an oauth flow then manage DNS records for a site. Therefore, anyone who does run even a simple service like hosted wordpress (without using the host as their registrar) needs to at least have basic knowledge of what DNS records are and how to put in their registrar without messing up email records or other subdomains they might have.
That said, I think DNS might not be the right layer of abstraction to simplify this. I think we need an open tunneling protocol[3].
[0]: https://www.domainconnect.org/
[1]: https://github.com/takingnames/namedrop-protocol-spec
[2]: https://takingnames.io/blog/introducing-takingnames-io
[3]: https://forum.indiebits.io/t/toward-an-open-tunneling-protoc...
Also do you think you'd pay $40/year? that's less than what you're paying Hetzner for no management.
I wouldn't pay $40/year because the value of having a random instance up with domain/ssl and nginx running all the time has been handy many times so far - worth way more than what I pay for the machine. At this point ngrok would be a downgrade for my use case, but if it was something like 20$/year when I was looking into it I probably wouldn't have bothered setting it up.
ngrok http 8000 -subdomain=my-custom-subdomain
> For a business, paying $10/dev/month for ngrok is a rounding error.
$10 here, $10 there, and next thing you know every unix command line app I'm running is charging $10.
But I think that point is moot because a service that costs $X in perpetuity must justify its costs with continuous new features and must be compared to alternatives. If I just wanted a basic proxy I’d run one of the open source alternatives in a container. If it required too much work, make a contribution to the project to make it easier for everyone. The value of ngrok is in its extra features, but the bulk of the cost is probably in setting up an actual VM and running it, which isn’t that hard these days and can be automated even in an open source offering. When considering the value of ngrok you can’t simply justify it by saying how much time it saves you. You have to compare it to the market, which includes free open source alternatives. So the real question to ask is whether the added features of ngrok plus the time savings over using some open source alternative is worth the extra cost over the time span I’d be using it. If time span is infinite, then maybe it makes sense to do a one-time extra cost of learning how to setup an open source alternative and paying a bit less for the actual VM costs. Maybe ngrok’s added features are indeed worth paying for. But telling yourself your time is not worth looking into this is a lazy justification for unnecessary subscriptions.
Even easier, create predefined ports in caddy and connect to those via ssh. Assign domains to them like proxy<1-1000>.example.com. Connect to one via ssh that is free. Done. That's 2 seconds once it is setup.
Even easier and cheaper if you do not have a "random server exposed to the internet", take one of the alternatives shown by op which allows to deploy a digital ocean or Hetzner vm automatically. Done, like a few seconds from the command line.
10$ a month for something like this is over priced but I guess you prove that it is a valid business.
For anyone doing this as a hobby sure, but if this is your business then it’s nuts not to just pay the cheap toll.
So it's not 120$/year - it's 120$/year/developer.
And setting it up for yourself - I've found multiple instances where having a configurable nginx reverse proxy on a public server saved me a bunch of time, it's much more flexible than ngrok.
Nginx or Caddy aren't all that hard to set up, for example: https://blog.kronis.dev/tutorials/how-to-use-nginx-to-proxy-...
Actually with WireGuard, OpenVPN and the like, you can do some pretty interesting (and sometimes problematic) things as well, so there's definitely a lot of flexibility with a few footguns here and there: https://blog.kronis.dev/tutorials/how-to-publicly-access-you...
Disclaimer: everyone's setup has their own requirements and whatnot. If using external services works for you, that's great! Also, that second article of mine may serve as an example of that NOT to do (you typically would only want to selectively forward ports, rather than forwarding all of the traffic like i did).
If I have 100 devs that's $12,000/year (ignoring any bulk discount), right? Are you saying that in a company with 100 developers they cannot spare enough time to run their own server cheaper than that?
Additionally, while the amount is 'cheap' in the isolated sense, when you start adding all those 'cheap' services together they quickly add up and suddenly your per-dev costs start getting out of control. In all cases you should consider the value of the service being provided. While I love ngrok, the functionality can easily be replaced for most use cases and move you from a per-dev cost to a relatively (yeah, large numbers of users will cause server scaling/cost changes) fixed cost instead.
Edit: Just to add on, $10/month is more than I pay for Gsuite or Jira on a per dev basis. The Ngrok pricing is drastically off base IMHO.
I also set it up for a team I worked with - took me 2 hours to get it running again and then the rest of the day to document and add keys for people and explain how and why they should use it. This was a team of 9 people - so in one day I did 1080$ - cost of small instance - for the year. That's above my daily rate so worth it for the owner as well.
10$/dev/month is not a lot - but this is such a trivial service that you setup once and forget, also there's a lot of friction in getting things like this approved and pretty much everyone has a some discretionary cloud provider budget.
Yes, but every tool on the wild wants you to pay 10 bucks per user per month. github/gitlab, jira, random CI/CD tool, gitpod, private repo, tailscale/zerotrust, dockerhub, 1password, okta, notion...
Depending on your size, those costs can add up pretty quickly.
ngrok is a very low hanging fruit for keeping expenses at bay, 10 bucks per user is ridiculously expensive for the service they are providing.
Written by the same guy that wrote awesome-proxy list in the original post.
First, it lets you easily see what the Webhooks payload looks like in real life. Second, it lets you hit your endpoint repeatedly with the same payload (while iterating on your code), without having to trigger the 3rd party event again.
``` ssh -tR "${HOST_PORT}:localhost:${LOCAL_PORT}" "${USER}@${HOST}" "multitail --basename -mb 2MB --follow-all --mergeall -n 0 -cS apache /srv/mydomain/logs/access.log -n 0 -cS apache_error /srv/mydomain/logs/error.log" ```
Which at least lets me see the nginx request logs as they come in. But no, I can't replay them or anything.
You could start a multiplayer game of StarCraft just by putting in your friends IP. It was wonderful and how the internet was meant to be
In order to get to a p2p world, I think maybe the best balance point is for most people to connect to the internet through a local tunneling/VPN company which also provides them with a public inbound IP. This has many benefits including:
* Hides all your behavior from your ISP, turning them into a dumb pipe and encouraging net neutrality.
* Since VPNs don't necessarily require hardware, it's much cheaper for VPN companies to start up and compete with each other. This can also have the effect of decentralizing a lot of power into many small local companies, as opposed to large (inter)national ISPs.
* Allows new protocols like IPv6, HTTP/3, etc to be adopted more quickly because VPN companies can implement them for all their users at once.
Unfortunately this technology might need a rebranding first, as a lot of VPN companies these days feel quite scammy and make some dubious claims about what they accomplish.
I think tunneling is a safer and easier approach for most people. They never have to expose their IP or ports, and the application on the private end of the tunnel can run in a sandbox to protect the rest of the user's stuff.
Oh p2p apps can and definitely should be sandboxing. That's not a unique feature of tunneling. The exposed IP and trickiness of educating users on opening ports are much bigger issues. That said, if you're willing to accept the risk of exposing your IP, all we really need is wider UPnP support. But just like IPv6 it's been around forever but hasn't taken off.
It's really a chicken-egg problem. We're not going to get IPv6, UPnP, fast upload internet speeds, simple sandboxing on all major OSes, etc, until we can prove that people want p2p apps and there's money to be made by supporting them. But p2p apps are difficult to build without those things, unless you use tunneling...
Note that you can get maybe 90% of the way there by using NAT traversal[0]. But you still need relays (tunneling) for the last 10%. Given the other benefits, I think going straight to tunneling makes sense.
* Cloudflare can handle a DDoS. Your home router can't.
* The application can't automatically open a port without something like UPnP, which isn't widely deployed enough to rely on.
* Your IP stays private.
* You don't need to use things like DynDNS to keep your DNS records in sync with the IP your ISP gives you.
What do you mean by "built-in" exactly? You mean adopted standards that are widely deployed?
Assuming that, with tunneling it doesn't matter if it's built-in, because you're side-stepping the devices between you and the public internet. Any device that can open a TCP connection to a remote IP address can create a tunnel, and then it's only constrained by the limitations of the tunnel provider, not by the home router, the ISP, or any software therein.
Maybe this would be more productive and I can learn something if we reduce the scope. How would you solve the DDoS problem in a network full of true p2p IPv6 devices?
It sounds like it, from what I understand, you're saying that each application would connect to a service like CloudFlare to open a tunnel to itself, right?
> What do you mean by "built-in" exactly? You mean adopted standards that are widely deployed?
No, I mean "running an application or library that knows how to open a port/tunnel". Remember that in the p2p case each computer has an externally accessible IP address, so all ports are just blocked by the firewall and the user can open them (or the application can request to have them open).
> Any device that can open a TCP connection to a remote IP address can create a tunnel, and then it's only constrained by the limitations of the tunnel provider, not by the home router, the ISP, or any software therein.
That's true, but in the p2p case, all ports are already open. You're using a firewall to block them, for security. If you want to allow programs to become connectable, you wouldn't block their ports. If you didn't, you would block them even in the tunneling case.
The point about DynDNS stands, but you still need some DNS even in the tunneling case (unless you assume that the tunnel endpoint has a static IP but your IP is dynamic, which there's no reason to assume, as it might well be the other way around).
> How would you solve the DDoS problem in a network full of true p2p IPv6 devices?
Same as you'd solve it in the tunneling case, you'd use a service that can absorb the DDoS. There's nothing that makes a tunnel inherently DDoS-resistant, it's just that one of the providers you can use for tunneling (CloudFlare) can provide you with anti-DDoS services.
I think we've mixed up too many things in the discussion. The main benefit I see in p2p vs tunneling is that tunneling hides your IP, but p2p lets you choose the port numbers (you can't choose whatever port you want for your tunnel, because all users have to share an IP). All the other features seem equal to me in both cases.
That would be ideal. But you could also have a GUI program that manages mapping tunnels to ports for apps that don't have built-in support.
> No, I mean "running an application or library that knows how to open a port/tunnel".
Ah that makes more sense. Yeah you're correct that is something that has to be added, but it's as easy as installing any other app, which is much easier than buying a new router, switching to an ISP that supports IPv6, etc.
> The point about DynDNS stands, but you still need some DNS even in the tunneling case
If the tunneling is offered by the same service that sells domains, this can be much more streamlined to the point where it's unnecessary for the user to understand DNS. That's what I'm working towards with TakingNames.io[0].
> Same as you'd solve it in the tunneling case, you'd use a service that can absorb the DDoS.
If you're routing through a 3rd-party anyway, why not tunnel and gain all the additional benefits?
> I think we've mixed up too many things in the discussion
I agree. I didn't want to leave any of your questions hanging, but if you want to continue the discussion feel free to drop anything you find uninteresting.
> p2p lets you choose the port numbers (you can't choose whatever port you want for your tunnel, because all users have to share an IP)
This is not a bad point. I do wish DNS had a way to specify ports in records. However, this is essentially solved by SNI routing. It does have the limitation of forcing you to use TLS for everything, but I don't think that's too big of a problem for now.
To be clear, I wish we had IPv6/UPnP everywhere and things worked the way you're describing, but I don't see it happening for many years to come. I'm betting on tunneling for the next decade or so.
Right, this sounds basically like what the firewall does in the p2p case.
> which is much easier than buying a new router, switching to an ISP that supports IPv6, etc.
Yes, if you can't just open a port, a tunnel is easier, true.
> If you're routing through a 3rd-party anyway, why not tunnel and gain all the additional benefits?
Well, you wouldn't be routing through a third party. DDoSes are costly and you usually don't need to protect against them if you're a home user.
> I do wish DNS had a way to specify ports in records.
That's what SRV records are for, no?
> but I don't see it happening for many years to come
Hmm, I don't think we need it everywhere, just where people care to use it, but maybe. I'm not as pessimistic, as my home ISP gives me a (fairly static? I've never actually checked) IPv4 where I opened a bunch of ports, but it would certainly be better if each of my home devices could be addressable from the internet.
TakingNames is an interesting idea, though I'd have to think a bit more about it to tell if I'd find it useful :P The current method of just opening a port on my router has worked extremely well for me so far!
You need to run a tor daemon on the server side and then a tor browser or tor on the client side, but other than that there is no other setup or intermediary service/server necessary. This solves a lot of pain that many ngrok alternatives still require you to run (or pay for using) some central hub server, have a public IP & DNS, etc.
Just follow the first part, and change the port to whatever you are using
You always need a compatible client on the other side
But yeah if your goal is "expose this thing with a public IP/DNS" then there is no way around using your own server, or buying/leeching off a service like ngrok.
You don't need any incoming ports open for a tor hidden service either though. Both the server and client side connect out to tor, and then get routed to each other over it.
onionpipe forwards ports on the local host to remote Onion addresses as Tor hidden services and vice-versa.
we’ve got some exciting improvements we’re looking to share with the community very soon here
<3 to you all
Honestly I would be very interested in hearing what you think the best plan for competing with Cloudflare Tunnel is. I've been keeping a close eye on this space for a couple years now, and Tunnel seems well on its way to dominating the mindshare.
It can be very hard to compete with a bundled loss-leader offering.
Question for you - do you have a plan in mind for handling teams?
Right now it seems like the only way to handle it is with a manual naming convention:
https://{my-team-name}-{my-name}-api.ngrok.io
And then every single team member has to copy this convention by hand and you have to register webhooks, etc with these new routes.
It gets tedious fast.
Do you have ideas to work around this or register team members behind the scenes and still route traffic appropriately?
edit: feel free to email me as well at alan at ngrok dot com
Also, I would love to hear about your experience buying a /24 if you've written about it somewhere.
ngrok http 80 --oauth=google
That would be pretty cool.
I use Cloudflare Tunnel for all of my self-hosted applications (e.g. https://piperswe.me). Configuring it can be a bit of a pain (generating secrets, setting up systemd service, etc.), but its integration with the rest of the Cloudflare CDN products is worth it IMO.
It will be lots cheaper per month than Ngrok, of course, but it will take more setup.
It seems like ngrok went from kind of a humble presentation to a more splashy look and maybe larger feature set.
The company is also actively recruiting sr swe’s right now.
Was the product bought or did the company take capital relatively recently?
It was such an understated thing for so long.
> As much as it pains me to say it, Cloudflare seems well positioned to eat ngrok's lunch. AFAIK they offer everything ngrok does plus auto TLS certs, CDN, domain name registration, and tons of other features. They also have way more edge servers for terminating tunnels close to the origin devices. And they can afford to do all this for free as a loss leader product. It's the AWS bundling effect. Oh and the client source code is available.
> I don't want to see Cloudflare completely take over this space, but Cloudflare Tunnel is tough to compete with.
> One knob ngrok could still turn is adding auto TLS certs which are managed on the client side. Then you can offer e2ee which is something Cloudflare will probably never do.
We haven't been bought and haven't taken any capital, but we have made some massive investments into our product: new ways of connecting, new ways of securing, reliability, etc. There are a couple announcements coming soon I don't want to spoil. We've been a quiet crew for a while!
On the recruiting side, we've got tons of openings in product engineering (junior, senior, management, PMs) and across the rest of the company. Please don't hesitate to reach out if you have an interest in working with us.
* You can't do end-to-end encryption, ie Cloudflare terminates TLS for all requests and can see your data.
* Cloudflare's ToS specifically says you can only use the free tier for HTML websites. Anything else (ie video streaming, photo albums, etc) is technically grounds for suspension, although that seems to be rare in practice.
* Not open source. You can't self-host the server. (EDIT: Client is Apache licensed now) Client source code is available but not FOSS.
They recently changed that, may be I am missing something?: https://github.com/cloudflare/cloudflared/blob/master/LICENS...
I am hoping this will be added one day, because it blocked me a number of times already.
[0]: https://forum.indiebits.io/t/how-to-forward-ssh-port-example...
I use this every day because I always forget to shut down the agent on my home computer before going to the office.
Since ngrok is written on Go here is some pure C clone: https://github.com/dosgo/ngrok-c
I will appreciate if someone assist how to run it.
Here is issue: https://github.com/dosgo/ngrok-c/issues/84