Show HN: Tunnelto.dev – expose localhost with a public URL (built in Rust) | Hacker News Reader

Show HN: Tunnelto.dev – expose localhost with a public URL (built in Rust)

tunnelto.dev

100 pointsagrinman38 comments

Hi HN!

I'm Alex, one of the creators of tunnelto.dev. We built this service because it's crucial to be able to test your website, app, or backend server as if it were in production. We built tunnelto.dev is both a free service (hosted by us) and an open source project (that you can host yourself). Both the tunnelto.dev CLI and server are open source on GitHub[1], built in Rust.

Since you can host it yourself, there's no vendor lock-in...perfect for use in the enterprise when you can't breach the corporate network. Tunnelto.dev is free even with customized sub-domains. We only charge a small monthly fee if you want to reserve specific domains for yourself on our hosted version.

Happy to answer any questions you might have!

[1]: https://github.com/agrinman/tunnelto

Would be happy to hear more about motivation and/or funding.

I needed a tool like this where I could host the server myself (inside the corp. network) and I realized it would be valuable to have unified CLI that works both with hosted and self-hosted servers.

So a side project out of need while employed. Nice.

I also really dig the site design.

At my last job I used cloudflare tunnels to do stuff like this (stripe web hooks, showing our site to my PM, etc).

https://developers.cloudflare.com/argo-tunnel/trycloudflare

I didn't know Cloudflare offered that, looks nice.

Wonder how these compare to Ngrok?

I used ngrok at first but quickly got frustrated due to the maximum of 40 connections/minute (without paying money). Our web app was pretty bloated so refreshing the page twice would disable the tunnel for the rest of the minute, which you can imagine was pretty annoying. Supposedly keepalives are supposed to mitigate this, but our dev server must not have implemented it?

So for my purposes, they did the same exact thing, but Cloudflare's was much more generous in terms of resource limits.

Hey Alex, the pricing is definitely appealing. I currently pay for ngrok, but $15/mo puts it on my watchlist of things to get rid of.

One thing i do like about ngrok that i didn't seem to see in tunnelto.dev, however, is: - the ability to forward TCP ports (these basically get forwarded to 0.tcp.ngrok.io at a particular port) - the ability to specify a subdomain - this is particularly handy if you want something that's going to stick around for a while (i.e longer than a couple of hours)

Hi there! Thanks for the feedback. We actually do support sub-domains, via, the --subdomain flag! :)

Raw TCP support is in the works, and will come soon!

Speaking as an ngrok user, their documentation is terrible and has caused me to waste huge amounts of time trying to figure out how to do things or whether it can do things. Take documentation seriously (and no, "it's open source" doesn't count as documentation for a product you ask people to pay for).

Can tunnelto open multiple ports on the same sub domain? Does the documentation explain clearly how to do this or that it's not supported if it isn't?

Do you support https tunneling (for example https to the subdomain followed by either http or https to the local machine)? Do your docs explain how to do this and if you don't support it do the docs say so?

I'd love a competitor to ngrok, but it has to actually be better at the places where ngrok is weak (which have very little to do with implementation or functionality)

Also, ngrok's support for introspection of data flowing over the tunnel was what got me to be a paying user of ngrok. Surprise! Their docs didn't mention it doesn't work for https tunnels. If their docs had been competent I probably would still have become a paying subscriber but I would have been a much less pissed off paying user than I was after subscribing, burning time trying to figure out what I was doing wrong, and finally concluding that feature didn't work. Oh, and ngrok support has never even acknowledged receipt of a single email, much less provide actual support. If you want people to pay, you need to treat it as a business not a hobby.

Really sorry about the frustrations! We're working on improving both of those pain points (as well as many other things). If you're still an ngrok user, send me an email at alan at ngrok dot com

And this is why I’m a paying ngrok customer. Alan is great and worked with us on a custom TCP production plan. Have been a customer ever since.

Thanks for the feedback. Full transparency our only documentation is the website, dashboard, and of course mainly the --help flag in the CLI. Part of this is because we've kept the first release very minimal and simple, so there's not so much to document (yet).

To answer your questions here though,

- multiple ports on the same domain: currently no, but this is definitely on the list.

- https tunneling: we enforce TLS on all subdomains and handle that for you via a wildcard cert. We actually don't support non-https currently (and may never if there's no demand for it).

Are there any security risks with allowing internet traffic to be forwarded inside your local network? (genuinely curious my networking knowledge is a bit lacking)

Yes.

Any normal attacks that could be executed against a server on the internet could now be executed against your local server.

Which means, if your local/dev API endpoints have vulnerabilities, you will be exposed.

To help protect against attacks, you will want to block all 3rd party requests.

A possible solution would be to use HTTP basic auth (assuming tunnelto passes along the basic auth headers).

Ex. https://user:pass@t1.tunnelto.dev/api/hello

Then on your local/dev server, check user & pass.

How does this differ from ngrok?

I assume mainly because it's written in Rust and not Go?

we built it in rust and open sourced the server so you can host it yourself (when you need to!)

Is there any documentation on how to host it yourself?

This is just perfect timing, I’m about to set up end to end tests on CI and need Stripe webhooks forwarding. Stripe CLI is not super reliable and ngrok is kind of expensive for what it does, I’ll definitely give it a go.

What would be super useful is a daemon mode that will run in the background while writing the bound address to STDOUT.

Kenneth here from Stripe. We'd love to know more about the reliability issues you experience with the CLI.

How can I best reach you?

My email is auchenberg@stripe.com or @auchenberg on Twitter.

Talk soon!

Has a broken github link in website.

Actual link https://github.com/agrinman/tunnelto

thanks for the find, fixed!

How does this compare to inlets.dev?

Any chance of getting binaries for other OSes like FreeBSD instead of just Linux and Windows?

It's open source, I guess you can compile it yourself: https://github.com/agrinman/tunnelto

Installing Rust is trivial via rustup.rs. And then the tool is just one "cargo install" (or "cargo build" locally).

It def helps when running a local server

Can I reverse-proxy ports to paths?

Not sure I understand what you mean, mind giving me an example?

A common usecase: I have http(s) running on 8080 and a websocket on 8081. I would make an nginx rule to proxy_pass / to 8080 and /ws to 8081.

Got it. Currently this use case is not supported on the same subdomain, but you could definitely open up two different tunnels (on different subdomains) to do this. Definitely not ideal, so we'll look into adding support for this.

Seemingly everyone in the rust crowd feels the irresistible desire to tell everyone about the language on every possible occasion, why is this? Every other project on this earth the creator just tells about how awesome the product is, how insightful the journey was or how much fun he had with it, but then that one rust guy comes along with "Project x y (Built with rust!)".

I've got a running joke with a colleague that rust is like the arch linux of programming languages.

I guess because they are marketing that their product will have much lesser vulnerabilities (than c/c++) while maintaining performance.

I appreciate being told something is in Rust because it immediately tells me that the friction to compile the tool/library is going to be very low which I appreciate a lot. (Dev machines, CI/CD, VPS-es etc.)

I've had to install a lot of C and C++ tools and libraries and the frustration when they don't compile on a particular VPS or a colleague's machine is something you can never recoup.

When a README tells me "this is in Rust" I know that the thing is just one "cargo install" away. And rustup is the easiest and quickest way to install a programming language I've ever experienced in 18.5 years in the job.

You and your colleague need to be less judgemental. People don't always praise tech because of emotional reasons. There's merit to a good chunk of what you'd call tech hype out there.

Looks fun. Is there (optional) IPv6 on front?

There is already Pagekite and it's been around for many years.

Reply on news.ycombinator.com