I am using

> ssh -R 8080:localhost:8080 my.server.com

and have Caddy webserver running on my server (my.server.com) which is configured to proxy any requests to localhost:8080. It adds LetsEncrypt and makes sharing local web projects easy.

Purpose-built UX, Docker images, Kubernetes support, future plans to add LetsEncrypt automation. There are ways to make "ssh" work through a corporate proxy, but normally it's banned. Websockets over HTTPS usually goes through without being blocked.

Multiple upstream sites are supported with ease as well as multiple exit node domains. If SSH is working for your use-case, then I'd say stick with it.

At first I said why websockets, when you are using go you could simply had done TCP sockets. But then I realize websockets is probably the right choice. This allows you a single listening port for both inbound and outbound connections as you can simply route /api/proxy or proxy our whatever you are using as your endpoint.

At first I did not like it, and responded like others, over kill for something many people can do (or are doing) without the aid of a fancy tool like this. But then I realized trying to covey to others who are not system programmers how to setup something and realized I would rather spend my time doing something else and just point them to a tool.

Good job on this!

That doesn't really scale to a team though, esp for tools that have a common configuration (e.g. localhost ports).

Some sort of tooling to point "this machine to this VM" becomes needed.

Then for full stack development it is even harder, as the app has to have this endpoint injected into it.

It is all possible, just a pain. Writing a mobile app (https only!) that talks to a service I am writing has a rather annoying set of minimal requirements to get up and running. (This may be why Firebase Functions are so popular, super easy to go from nothing to deployed endpoints in just a few minutes.)

You can run this on Kubernetes for multi-team and multiple teams can share the same exit-node.

Yes! I just realized that you can do this without any fancy tools!

Well, the catch is you have to set up and maintain your own server running a proxy :-)

I don't think these tools are really claiming to sell anything fancy that you can't fairly straightforwardly do yourself - what you're buying is convenience (saved time and focus) - just pay for this tool and you're ready to go, within minutes.

Recently I spent an hour trying to get a bunch of "self hosted ngrok alternatives" to work and couldn't figure out any of them. Either I couldn't get them to compile or their documentation had me seriously fooled.

Then I found out how easy it was to set up ssh reverse tunneling. Sshd + systemd turned out to be all I needed for a pretty stable and persistent connection from anywhere. I was so satisfied to find that the most common tools out there could already handle this. Yay!

Give inlets a shot if you get time and let me know how you think it compares.

Seems like it could really be convenient for dev work... I'll keep it in mind in the future!

Very often the simplest and well-tested tools are more reliable and quicker to use together than yet another fancy tool.

"just pay for this tool" - it's free, OSS and accepts contributions.

Shameless self plug, but I wrote something that does the exact same thing as this (https://github.com/antoniomika/sish) but has some added benefits:

1. Don't require installing a local client, use something that is installed almost everywhere: ssh 2. Use a protocol that is already great at multiplexing: ssh 3. Supports authentication using PK/password auth: ssh 4. Completely opensource

Nothing crazy or flashy, just simple and does the job.

Sish is pretty cool and full of features.

I also like the idea of "onion-expose"[0], no need for a central server anymore and a stable address for free !

[0]: https://github.com/ethan2-0/onion-expose

You don't need a tool. Creating a temporary onion service is trivial.

If it's more trivial than an simple "pip install & onion-expose 8000", then please tell me ! (this is theorical, onion-expose is not yet on PyPI)

Also, let's learn from our history: https://news.ycombinator.com/item?id=9224

That does seem to be the theme with these new apps...

I like that they are using websockets to process the GET requests. I was thinking about this just this week and it occurred to me that the "Host Node" [1] doesn't even need to be a program, it could just be a browser since they also have websockets and a API for getting files. I made a POC (proof-of-concept / piece-of-crap) example for this idea: https://hostyoself.com

[1] https://github.com/alexellis/inlets#intro

See also fibridge[0][1]

[0] http://iobio.io/2019/06/12/introducing-fibridge/

[1] https://github.com/anderspitman/fibridge-proxy-rs

Seems like https://ngrok.com/ with extra steps

Except ngrok supports ssh.

These projects really need to consider plain TCP connections. It's a deal breaker for me.

My company installs ngrok on our embedded devices. When there is an issue, they connect it to the internet, type a keystroke, and I'm in.

Ngrok is closed source, I do explain the differences in the post. Ngrok is also almost always banned..

I haven't run into a single hospital network where it is banned, so far.

You can also use ngrok1, which you can host yourself. It's got the features you'd need. This would get around firewalls.

For remote access, Teleport for IOT supports a similar use case using SSH, where an agent can be run on an embedded device, optionally or always enabled that phones home, and allows SSH connections to be reverse tunneled back to the device behind a firewall. https://gravitational.com/blog/iot_security_teleport/

Disclaimer: I work for gravitational but not on teleport.

Can you share more details about this? Sounds very interesting!

I have an X11 key listener. When someone reports a problem and they have access to the internet, I have them type "__medxremotedebug". An ngrok process is started, the machine beeps to notify the user that the backdoor is open. I then login to ngrok.com, see the tunnel and connect to it. All the units have a public ssh key and only I have the private key.

This has saved me and my customers so many times.

Hmm? He asked.

Or my personal favourite: http://localhost.run/

https://serveo.net is similar.

If it’s this simple to host an arbitrary TCP reverse proxy, why would inlets make it a “non-goal”?

Surprising that a site like this operates on http.

https://localhost.run/ works (and when you use their tunnel, both http and https work).

Or https://sshreach.me

Is this a direct competitor to Zoom?

Comment of the week

Serveo is another good alternative to Inlets or ngrok that is completely free and pretty flexible: https://serveo.net/

Interesting, I will definitely try this out. If the Kubernetes ingress integration works well and it's stable, this could be really awesome.

I'm a bit curious about the choice of websockets as a protocol over the tunnel, though. Why is "tunnelling plain (non-HTTP) traffic over TCP" a non-goal? What's the benefit over just tunneling the HTTP traffic over a reverse SSH tunnel or similar?

EDIT: Maybe it's just a question of the author finding websockets "good enough" (despite performance overhead) and wanting to keep the scope small with a single implementation that isn't really going anywhere. Here a suggestion on using WebRTC instead of Websockets: https://github.com/alexellis/inlets/issues/49

> Thanks for the suggestion. I'll look into webrtc when I get time, but for the time-being I think web sockets are going to be the way inlets works.

That issue was not handled in a way that makes it an open source project I’d want to contribute to.

How would you prefer it be handled?

I also run ultrahook.com for unidirectional webhook only use case.

This seems like a solution for sharing a private development server with co-workers.

A decade ago we used another solution which seemed to work well enough: Developers had a Unix accounts on a Linux server. Their workspace was mounted as a remote filesystem. Interactive console access was available via SSH.

Inlets seems to still require a remote Linux server, but seems a like a more complicated way to solve the problem.

By using a shared server, we didn't need maintain container image to keep laptop environments sync'ed. If we wanted to upgrade the development database version, we upgraded the DB once on the shared server and everyone had the new version immediately.

I don't believe that's the main use case for this project. The main use case for stuff like this is if you're using some external API like Zuora or Twilio that needs to hit endpoints on your local test box. Something like this allows them to actually contact your machine indirectly.

I've used ngrok before and it's a great solution for quick tests. I guess this is an open-sourced version of that.

Thanks for clarifying that. I have occasionally had that need. Some protocols like SAML are actually doing in-browser redirects so they bypass that problem.

I'll bookmark this in case I have this need in the future.

I've been using https://github.com/fatedier/frp to expose UDP endpoints for a while. Works pretty well.

This looks very useful. I'm currently using localtunnel.me for this but will definitely give this a try too and subdomain option sometimes doesn't work on localtunnel.

Yep, free TLS and free domains.. and it is completely open source. Contributions are welcome too.

I just have port forwarding on my modem. Changed my aname record on my dns to point to my public IP of my modem. Technically I don't have a static address but until know (3 years?) I never needed to update it. Got my pine64 running an nginx with my java application behind it. Using let's encrypt for SSL certificates.

Sadly not possible for those of us poor souls stuck behind carrier-grade NAT. I do have an ipv6 range, but of course, there's no ipv6 connectivity from my workplace! And that's often where I want access from.

There are many of these so obviously it's useful for folks. What's your favorite use case? :D

WRT setting up a desktop as a remote workstation, where can a person go to learn more about how it works? Is it just about setting up port forwarding on your router, then using a proxy to deal with the non-static IP?

I use https://localtunnel.github.io/www/

Simple and works well

Ssh tunnels work well

I use http://holepunch.io Really stable. Also, much easier than this.

It's not the same thing, you may as well use grok, it's just as limiting. https://holepunch.io/pricing

Is this different than setting up openvpn and serving with haproxy?

Yeah, you don't have to setup openvpn and configure haproxy

Is that the only difference?

Try it :-) look at the video and how fast the connection is established.

If I was going for "establish a connection as fast as possible" I'd go for `autossh -R`. Maybe "inlets" has better naming, is that the reason we need to use it?

Really good name for this product.

Does it support Range requests?