I want to clarify why this project exists (as many seem to point out that other projects or methods exist for doing this).
TL;DR; If you think of localtunnel as just a shitty ngrok (or name your project here), you are missing the point and probably don't have the same use cases I do.
1. It was made overnight at some hackathon because I was not satisfied with the other tunneling options I found. They required either an account or some stupid ssh setup. I got to thinking of ways to create a tunnel that simply had an CLI tool and instantly get a tunnel no setup. It worked, I kept it.
2. It is written as a library first, CLI tool second. This means it can be used to create tunnels in a test suite if you want to use services like saucelabs to run browser tests (see https://github.com/defunctzombie/zuul). This is leveraged by projects like socket.io and engine.io (among others). This is perhaps the main reason I keep it around despite there being alternative CLI tools.
3. Both the client and server code are availably and easy to install and use. Companies do this when they want to run their own tunnels for privacy (or whatever their reasons... I don't care).
4. Yes, I know the name is identical to the old ruby?python? one. Whatever. That one seems defunct now anyway.
ngrok doesn't have a programmatic API, but I'd love to add one soon. I've built out a library for this in https://github.com/inconshreveable/go-tunnel that will be the foundation for ngrok's next version providing a library in addition to the CLI tool.
Unfortunately, one of Go's weaknesses is that it doesn't embed into other languages like C, so I'd need a ground-up rewrite (in C, probably) with bindings to other languages.
If ngrok the command-line tool had a well defined programmatic interface (like RESTful JSON) would that useful, or is the burden of a separate binary/process to manage still too painful?
I wouldn't worry about the whole rewrite in c thing. If your server protocol is simple enough, writing clients in the native languages will be better than writing bindings. Installing bindings trips up a lot of users that are not used to compiled software.
As a bonus, you also get:
- Custom (sub) domains
- TLS tunnels if you want, not mandatory
- Other protocols than just HTTP/S
edit: I was wrong, I should've been a little more thorough. Looks like it's [a-z0-9]{4,10}.localtunnel.me, which is significantly larger.
WARNING: server returned more data than it should - server is vulnerable! (Heartbleed)
For example:
ssh -f -N -q -R 2222:localhost:22 my_name@remote.example.com
Decent writeup here:
Or the Go version: https://github.com/inconshreveable/ngrok
localtunnel v1 worked perfectly for me, localtunnelv2 never did (apparently no remote server was ever up) but it's weird that ngrok is a ruby project again.
Because, you will use this service for the development to give someone outside access to something. If you then close the tunnel, the service will forward any request to its own server either to the main pager or to an error page. That means, all data given with a request, either via GET or via POST, will be given to that service. That could include sensitive data. That means, this kind of service is security risk.
I'm sure I'm missing some obvious disadvantage…
(Shameless plug - I'm the author of httpipe)