Hacker News new | past | comments | ask | show | jobs | submit login

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: