kekub 3 months ago

I am using

> ssh -R 8080:localhost:8080

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

  • alexellisuk 3 months ago

    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.

    • mbrumlow 3 months ago

      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!

  • com2kid 3 months ago

    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.)

  • macawfish 3 months ago

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

    • davnicwil 3 months ago

      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.

      • macawfish 3 months ago

        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!

        • alexellisuk 3 months ago

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

          • macawfish 3 months ago

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

        • eeZah7Ux 3 months ago

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

      • alexellisuk 3 months ago

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

antoniomika 3 months ago

Shameless self plug, but I wrote something that does the exact same thing as this ( 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.

  • bantunes 3 months ago

    Sish is pretty cool and full of features.

Buetol 3 months ago

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


  • eeZah7Ux 3 months ago

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

    • Buetol 3 months ago

      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:

    • rbrtl 3 months ago

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

qrv3w 3 months ago

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:


Svoka 3 months ago

Seems like with extra steps

  • pknopf 3 months ago

    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.

    • alexellisuk 3 months ago

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

      • pknopf 3 months ago

        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.

    • kevin_nisbet 3 months ago

      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.

      Disclaimer: I work for gravitational but not on teleport.

    • iampims 3 months ago

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

      • pknopf 3 months ago

        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, 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.

        • smashah 3 months ago

          Bro. TMI

          • pknopf 3 months ago

            Hmm? He asked.

gpmcadam 3 months ago

Is this a direct competitor to Zoom?

rohug 3 months ago

Serveo is another good alternative to Inlets or ngrok that is completely free and pretty flexible:

Legogris 3 months ago

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:

> 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.

  • ComputerGuru 3 months ago

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

    • icebraining 3 months ago

      How would you prefer it be handled?

veesahni 3 months ago

I also run for unidirectional webhook only use case.

markstos 3 months ago

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.

  • asdfman123 3 months ago

    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.

    • markstos 3 months ago

      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.

superasn 3 months ago

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

  • alexellisuk 3 months ago

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

ivolimmen 3 months ago

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.

  • kingosticks 3 months ago

    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.

thomas536 3 months ago

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

jammygit 3 months ago

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?

alexellisuk 3 months ago

Inlets is designed to be super easy to use, from provisioning the exit-node, to punching out for your first service / endpoint.

It'd be great some of the folks commenting to try the project and then bring some feedback via GitHub, Slack, Twitter etc.

What did you like? What would you like to see next? What can be improved?

nurettin 3 months ago

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

  • guipsp 3 months ago

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

    • nurettin 3 months ago

      Is that the only difference?

      • alexellisuk 3 months ago

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

        • nurettin 3 months ago

          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?

MaconBacon 3 months ago

Really good name for this product.

W0lf 3 months ago

sounds a lot like to me?