How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
Really glad to see someone stepping up to fill this void! I've debated doing this myself many times but it's low on my list of priorities.
Please don't interpret these frank questions as criticism or mistrust up front, but we've been burned a few times with tools like this start open source and then realize there might be some money out there and go proprietary, usually with a rug pull. I don't mind offering paid hosting at all (in fact I think it makes sense to offer that) so long as the code all remains open source. The "open core" model may even be ok so long as it's truly just "enterprise" feature that are gated, though that's a hard line to tread.
What are your monetization plans? Are you committed to long-term being actually open source?
Personally, I would suggest licensing this as AGPL to ensure that if anyone does take it and try to stand up a paid/proprietary service based on your work, the license will at least force them to open their code. It's not perfect. but with MIT you have zero defense against that. It would also give people like me some peace of mind.
Freemium with a paid tier for teams worked fine for Ngrok circa 2013. The hard part isn't the model, it's support load once you hit scale. HashiCorp tried pure open source and eventually caved. Pick your poison early.
One of my vendors recently disallowed registering ngrok URLs for testing webhooks. They said they were too unreliable — and the vendor was getting blamed for ngrok failing to deliver requests.
Seems like a real shame that they’ve been abandoning their core product that was reliable for years in pursuit of nebulous AI/enterprise routing products.
I get that dev tunnels are probably not a massive business that’s going to get VCs mouths’ watering, but maybe not every business needs to shoot the moon?
Anyway, glad competitors are coming in to fill the space.
VC-backed companies enshittify, sure, but so do bootstrapped ones when founders burn out or cash out. Couchsurfing was non-profit and still got gutted. Ownership structure matters less than whether the people running it give a damn.
We had a vendor do the same thing. Spent six months building integrations, they started throttling tunnels, now I'm maintaining a self-hosted alternative. Lesson: don't build on someone else's free tier.
That list is genuinely useful — we referenced it when evaluating options last year. Ended up on frp because the self-hosted story was cleaner for our infra, but good to see the Rust options maturing.
Interesting. Currently building something simpler with outbound[1]. Decided to go with gRPC instead, but mine is mostly focusing on developers, for basic HTTP service reverse tunneling.
A ngrok-style secure tunnel server written in Rust. Expose local services through a public server over encrypted WebSocket connections with TLS termination, HTTP/TCP proxying, a live dashboard, Prometheus metrics, and audit logging.
Well since it still not uses a custom port for the client connection and not plain h2 streaming what’s the difference to pangolin? I mean it does not like it has that much more benefits? If clients would also connect to 443 h2 than yeah. But in Corporate environments having a port different than 443 always is a pain no matter the protocol.
i've been thinking of running something similar in my stack for the last few years, and this thread got me to finally figure it out. i ended up implementing an approach that works for me without any additional services beyond what i was already running. documented here: https://igor.moomers.org/posts/basic-tunnel
Interesting project. Is the main value to "self-host your own ngrok", or is it to actually compete with ngrok using an open-source project ? If so how do you intend to monetize your project ?
We hit this exact problem bridging n8n Cloud to a local Ollama instance on a Mac Mini. Tried Cloudflare tunnels (502 errors), bore-cli (random ports on restart — unusable with multiple HTTP nodes), and ngrok (requires auth/signup).
Ended up on localtunnel with a fixed subdomain and keepalive script. It works but drops connections and requires a bypass-tunnel-reminder header on every request.
Key requirements for this use case: fixed/predictable URL so downstream services don't need reconfiguration, low latency for API calls, and auto-reconnect as a daemon. Would be interested to try Rustunnel if it supports fixed subdomains.
Hey!
it does support subdomains. Either by passing a flag --subdomain or just configuring them straight up in you config.yml file.
We also implemented auto-reconnect.
For now we only running servers in Europe, but we are implementing multi-region right now and should have it up in a couple of days. That should cut latency way down for people that not in Europe.
Personally I don’t care what it is written in. I care what the code does and how well it does it.
Rust is a cool and interesting language that helps solve some problems, but it doesn’t make it immune from all. But that doesn’t make it inherently better, or worse for the job. We have seen this trend for everything from C++ onwards (Java, Ruby, C#, Python, etc etc)
Help me understand: why does knowing the language matter? I can see why for contributing to it, though there are other ways to contribute than code. However to use it, why? Do you only use projects you can contribute to?
The interesting design question with these tunnels is how they handle the control channel — whether it's a persistent connection or re-established per request. As far as I know, most Rust implementations here converge on the same multiplexing approach over a single TCP connection.
Please don't interpret these frank questions as criticism or mistrust up front, but we've been burned a few times with tools like this start open source and then realize there might be some money out there and go proprietary, usually with a rug pull. I don't mind offering paid hosting at all (in fact I think it makes sense to offer that) so long as the code all remains open source. The "open core" model may even be ok so long as it's truly just "enterprise" feature that are gated, though that's a hard line to tread.
What are your monetization plans? Are you committed to long-term being actually open source?
Personally, I would suggest licensing this as AGPL to ensure that if anyone does take it and try to stand up a paid/proprietary service based on your work, the license will at least force them to open their code. It's not perfect. but with MIT you have zero defense against that. It would also give people like me some peace of mind.