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, 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!
I also really dig the site design.
Wonder how these compare to Ngrok?
So for my purposes, they did the same exact thing, but Cloudflare's was much more generous in terms of resource limits.
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)
Raw TCP support is in the works, and will come soon!
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)
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).
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).
Then on your local/dev server, check user & pass.
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 firstname.lastname@example.org or @auchenberg on Twitter.
Actual link https://github.com/agrinman/tunnelto
I've got a running joke with a colleague that rust is like the arch linux of programming languages.
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.