• kekub 11 days ago

    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.

  • alexellisuk 11 days 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 11 days 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 11 days 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 11 days ago

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

  • davnicwil 11 days 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 11 days 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 11 days ago

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

  • macawfish 10 days ago

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

  • eeZah7Ux 11 days ago

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

  • alexellisuk 11 days ago

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

  • antoniomika 11 days ago

    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.

  • bantunes 10 days ago

    Sish is pretty cool and full of features.

  • Buetol 11 days ago

    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

  • eeZah7Ux 11 days ago

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

  • Buetol 11 days 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: https://news.ycombinator.com/item?id=9224

  • rbrtl 11 days ago

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

  • qrv3w 11 days 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: https://hostyoself.com

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

  • Svoka 11 days ago

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

  • pknopf 11 days 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 11 days ago

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

  • pknopf 11 days 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 11 days 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. https://gravitational.com/blog/iot_security_teleport/

    Disclaimer: I work for gravitational but not on teleport.

  • iampims 11 days ago

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

  • pknopf 11 days 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 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.

  • smashah 11 days ago

    Bro. TMI

  • pknopf 11 days ago

    Hmm? He asked.

  • gitgud 11 days ago

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

  • trevordixon 11 days ago

    https://serveo.net is similar.

  • jchook 11 days ago

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

  • sandGorgon 11 days ago

    Surprising that a site like this operates on http.

  • mceachen 10 days ago

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

  • gpmcadam 11 days ago

    Is this a direct competitor to Zoom?

  • haggy 11 days ago

    Comment of the week

  • discordance 11 days ago

    very funny

  • 11 days ago
  • rohug 11 days ago

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

  • Legogris 11 days 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: 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.

  • ComputerGuru 11 days ago

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

  • icebraining 11 days ago

    How would you prefer it be handled?

  • veesahni 11 days ago

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

  • markstos 11 days 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 11 days 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 11 days 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.

  • tyrbo 11 days ago

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

  • superasn 11 days ago

    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.

  • alexellisuk 11 days ago

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

  • ivolimmen 11 days 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 11 days 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 11 days ago

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

  • jammygit 11 days 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?

  • Zaheer 10 days ago

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

    Simple and works well

  • beardedwizard 11 days ago

    Ssh tunnels work well

  • corbinlc 11 days ago

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

  • alexellisuk 11 days ago

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

  • alexellisuk 11 days 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 11 days ago

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

  • guipsp 11 days ago

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

  • nurettin 11 days ago

    Is that the only difference?

  • alexellisuk 11 days ago

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

  • nurettin 10 days 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 11 days ago

    Really good name for this product.

  • anderspitman 11 days ago

    Does it support Range requests?

  • W0lf 11 days ago

    sounds a lot like smee.io to me?