Show HN: Inlets 2.0 – expose your local endpoints to the Internet | Hacker News Reader

Show HN: Inlets 2.0 – expose your local endpoints to the Internet

inlets.dev

218 pointsalexellisuk66 comments

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.

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!

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

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!

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

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

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.

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

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

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