> "feeling like it's not a good fit for me, and indiehosters in general."
Maintainer here so I'm gonna be biased with this hot take, but I really don't agree with this particular sentiment.
I would turn it around instead and say that most indie hosters are maybe not looking for the levels of protection a zero trust overlay network provides. That is a believable reason for me why it might be perceived as not a good fit. If you're not looking for the sort of security that OpenZiti affords the operator, it will certainly feel less of a fit than a classic VPN-like solution. It also focuses on a different paradigm wrt connectivity centered around individual services. That does mean the learning curve is absolutely steeper because it's not "just IP" and all our years of ip-based-know-how are useful, but not to make the most of the system. While one can use IP/L3/L4 just fine with OpenZiti, it's certainly not trying to be an IP-based VPN (like many of the other solutions are). That also might lead to feeling like it's not a great fit.
For the people who want the sort of security OpenZiti provides, however. It really is an easy-to-use (my bias showing) solution that plenty of indie hosters use already. :)
Not trying to sound too defensive here (a little is ok, right?) but I also appreciate the comments and feedback, thank you!
Couple of additional small notes (maintainer here)
> In a similar sense, why should enterprises trust OpenZiti?
you don't have to. It's open source - so you go look at all the code and judge for yourself but perhaps better than that (well different anyway) is that OpenZiti allows you to use your own PKI for identities if youlike. With third-party CA support, you can make your own key/cert and deploy them to identities if you desire. https://openziti.io/docs/learn/core-concepts/pki/#third-part...
> If services do not use e2ee
with OpenZiti you basically get this by default between OpenZiti clients. (once offloaded from the OpenZiti overlay, it's up to the underlying transport protocol)
The post demonstrates how to build a very simplistic ssh client using the Golang standard library and the golang.org/x/crypto extended packages. After that, it demonstrates how to remove the IP-based underlay connection with an OpenZiti net.Conn to create a zero trust ssh client - zssh.
Interesting idea. I'm not very well-versed in training models or LLMs or even Jupyter Notebooks, but the comment about port forwarding SSH caught my eye since I work on a free, open source zero-trust overlay network (OpenZiti). I tried to find some information about moonglow under the hood / how it worked but didn't succeed.
If you're interested, you might find embedding OpenZiti into Moonglow a pretty compelling alternative to port forwarding and it might open even crazier ideas once your connectivitiy is embedded into the app. You can find the cheapest compute for people and just connect them to that cheapest compute using your extension... Might be interesting? Anyway, I'd be happy to discuss some time if that sounds neat... Until then, good luck with your launch!
Cool! We actually don't do port forwarding over SSH, we do it over an ngrok-like solution that we forked/modified. I looked at a few options while we were designing this, including Tailscale and ngrok, but none of them exactly suited our needs, and the pricing would have been prohibitive for something that's a pretty core part of our product.
OpenZiti looks really cool though - I'll take a look!
At a glance, the RunPod's serverless and pod options would probably work well with OpenZiti. I didn't explore their vLLM option.
Using OpenZiti w/ Serverless probably means integrating an OpenZiti SDK with your serverless application. That way, it'll connect to the OpenZiti network every time it spawns.
The SDK option works anywhere you can deploy your application because it doesn't need any sidecar, agent, proxy, etc, so it's definitely the most flexible and I can give you some examples if you mention the language or framework you're using.
The pod option says "container based" so it'll take some investigation to find out if an OpenZiti sidecar or other tunneling proxy is an option. Would you be looking to publish something running in RunPod (the server is in RunPod), or access something elsewhere from a RunPod pod (the client is in RunPod), or both?
I poked at it a bit but there was no free trial period. I know a bunch of people are using OpenZiti and zrok for Jupyter notebooks in general... Here's a blog I saw not long back that might help but I wasn't able to prove/test/try it... (sorry)
OpenZiti maintainer (zrok sometimes). It depends on your definitions of peer to peer. the private sharing functionality is peer-to-peer at the application level using a zero trust tunnel, but it'll ride through/over the openziti overlay network (the zero trust part).
If you use the public sharing option, it's definitely "just" a reverse proxy back to your share location without the need to open a firewall hole in your home network. Super useful for plenty of tasks and there are numerous offerings like this.
You can self-host everything yourself if you like or you can use the NaaS version provided by NetFoundry. We operate the zrok/openziti overlay for you in that case. To self-host you would need an openziti overlay network, a zrok controller and zrok front end. It's pretty easy (well, easy for me maybe) overall. People are starting to self-host more and more zrok instances. The software is all strictly opensource and a liberal apache v2 license. You can find them on github:
Very neat. Lots of similar tools listed on
https://github.com/anderspitman/awesome-tunneling. Seems similar to zrok.io, ngrok, cloudflare tunnels, tailscale funnels and zrok although you're using http/3 explicitly.
Personally I work on two similar projects you might want to check out: zrok and OpenZiti. Similar projects, but zrok is closest to what you did here.
Yes it's very similar to ngrok or to tailscale funnels or to cloudflare tunnels because it's a SaaS offering that someone (my employer in this case) hosts for free for the world to use... However zrok is also self-hostable and yes you can set it up in daemon mode. Right now setting it up for more than one thing in daemon mode (referred to as zrok front door https://docs.zrok.io/docs/guides/frontdoor/) isn't quite as ergonomic as we would like (doable, just takes a wee bit more effort right now, you can read a post about it on our forum where someone did just that https://openziti.discourse.group/t/zrok-how-do-i-run-multipl...)
It won't timeout if you run it as a service in this way.
"better"? I mean that's up to you. It's quite similar that's for sure, doing largely the same sort of thing but it all depends on how you use it.
zrok is fully open source and fully self-hostable, that's probably the biggest difference? other than that I suppose it depends on your use case and what you like better. zrok has some interesting features with its caddy support, with drives, with zrok front door.
I don't have a full and complete list of similarities and differences but those are a few that come up that might differentiate it. I work on the OpenZiti project (the project zrok is built on/around) so I'm only adjacent to zrok (I use it more than develop it) and I've not done anything other than read the funnels docs for a few minutes :) If you're experienced with funnels thoguh, I'd be interested in what you thought when you tried zrok.
reply