There was a post about https://showoff.io/ here not long ago. Seems they are doing quite similar things, except showoff.io costs a little. I didn't really compare features, though.
I've been using showoff to develop against the github service hook. I've got a paid account so I have a static url which means I only had to set it up once in github. I use a lot of cloud services and don't bother with a VPS. For $5 a month it's a really simple service that does just what I want.
i understand the case where you don't have a box with e.g. port 80 available and need to use their server as an endpoint, but otherwise is it really that hard to remember ssh -L and -R syntax as the article suggests?
i also don't really see where you'd need to tunnel and serve production traffic from your dev machine versus having a proper staging environment and testing there. that has "bad idea" written all over it.
> weβre all starting to see the benefits of having a production-like environment right there on your laptop so you can iteratively code and debug your app without deploying live, or even needing the Internet.
actually, real professionals have seen these benefits for ages. that is SOP for good programmers.
A lot of great startups were engineered by non-"real professionals", meaning they had little to no formal training in software development and/or little to no experience developing software in a professional setting. A lot of SOP is learned along the way; it is not always so obvious at the outset.
Correct, but I'd also like to point out the self-taught freelancers, small web dev shops, and/or hobbyist hackers that like to build things in a way that's comfortable for them. I wrote that in that way ("we're all starting to see") because it's something I've noticed in the real world (even here in the Valley) that is not necessarily common knowledge yet.
This is probably a bad idea. If you don't have access to or control over your local firewall, there is most likely an organizational reason for that (security). Opening up your development webserver to the public Internet without asking permission from your IT department first is a good way to either get hacked or to at least make some enemies within your corporate security department.
If you have access to your firewall, why not just open it up yourself?
> If you have access to your firewall, why not just open it up yourself?
If I want to temporarily open up my dev server so I can demo something to a client, this is beneficial because 1) it's a single line in my local terminal, not 30 clicks in a crappy router web admin and 2) it disappears as soon as I close the tunnel, I don't have to remember to undo the firewall changes.
I wrote a post a little while ago about DIYing this for people doing Rails/Rack apps on Mac who've got an nginx box public somewhere. It also uses a wildcard DNS trick to let you do all your apps with a single tunnel
I like that this makes it easier to steal unreleased code, demos, etc by just enumerating all possible subdomains of localtunnel.com that are 4 alphanumeric characters long.
Yeah, if you wanted to make the effort. Ease of use was definitely the primary metric being optimized here. Perhaps it's not as important to have a short, speakable URL; in which case it could be a SHA1 hash or something. Maybe URL shorteners can play the above role if needed. What do you think?
Obscuring the URL from brute forcing would make it difficult to find random information site-wide (but using a hash is probably asking for trouble; just generate a long random string).
However, if I knew a specific person were using this service (which, since this is a public website whose URL you share with one or more other people), I could find other ways to find it and then break the application or server behind the firewall and have access to a multitude of juicy information to steal. It's kind of like saying to an attacker: "hey, instead of attacking a random web server you could attack the developer's workstation!" Black hats like lulzsec, etc would have a ball.
I recommend a simple username/password combo at the very least to prevent unauthorized access. The whole 'access-behind-the-firewall' concept still gives me the heebie jeebies though, and I think short of a VM on the developer's workstation I would be very afraid to use such a service.
Thanks for the mention! Yes, we're similar, but built on more flexible technology (pure python, no ssh required, we can tunnel more protocols, etc.). Our solution is also open source for those who don't want to rely on a third-party front-end.
If people are trying it for the first time, I kinda recommend trying the new 0.4 release, it is way more user friendly than the old 0.3 which we consider 'stable'.
Although I haven't used any of the software, I greatly prefer the pagekite website to either localtunnel's or showoff-io's. Thanks for providing a depth of well-organized content. That said, you could benefit from simplifying your quickstart page and featuring it more prominently.
Thanks for the kinds words and the feedback! We got lots of good feedback last time these things were discussed here on HN, hopefully we've made some progress.
Regarding our quick-start, we absolutely agree - except rather than simplify it, we'd prefer to get rid of it altogether by improving the UI of the product itself to the point where it doesn't need so much explaining. That effort is ongoing and should launch later this summer. :-)
