7 ms·

A ngrok-style secure tunnel server written in Rust and Open Source

107 points by joaoh82 6mo ago

joaoh82 6mo ago
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.
- OpenDQV 6mo ago
  nice - i will check this out! but to be honest ngrok is working well for me. tell me why i should change?
  - joaoh82 6mo ago
    For now is free. And when we start charging will definitely be cheaper. Also, the project is open source and there is good documentation on how to standup your own infra, if you want to go down that path.
mikeocool 6mo ago
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.
- danielbln 6mo ago
  Once a business takes on VC and/or goes public, enshittification will inevitably follow.
  - simantel 6mo ago
    Wow I had no idea ngrok had raised $50M, that's wild!
joaoh82 6mo ago
Btw, if anyone wants to test on our own servers just request an api key with github issues: https://github.com/joaoh82/rustunnel?tab=readme-ov-file#getting-an-auth-token https://github.com/joaoh82/rustunnel?tab=readme-ov-file#gett...
freedomben 6mo ago
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.
- thegreatpeter 6mo ago
  It should be monetized to support the long term commitment
  - freedomben 6mo ago
    I have no problem with monetization. I do have a problem with rug-pulling, especially if it's a tool I'm adopting into my workflow. I ask about monetization strategy because it can be an indicator. If the answer is, "never thought about it" then rug pull is a strong possibility. If the answer is, "planning to offer paid hosting" then that can be a positive sign.
    - joaoh82 6mo ago
      Very good points. Including the AGPL, that is definitely a better license for this type of project. I am just used to starting with MIT when I start a new open source project, but you have a point. About monetization, that is definitely very important. For now, and not sure how long, could be days or weeks, I am offering api-keys at no charge, because I want the feedback of real users. But obviously that is not sustainable in the long term, servers cost money and monetization also help keep the project alive. At a second stage, I am planning to offer monthly or yearly plans with different limitations or unlimited also. But I am also planning on offering pay per use with short lives api-keys targeting agentic workflows, for example or people that dont really want to pay a monthly fee, but instead just cents for a short-lived tunnel. For the monthly plans, I am planning to keep as low cost as possible, just enough to maintain the infrastructure and development + some overhead.
abricq 6mo ago
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 ?
- johnisgood 6mo ago
  Hmm, how to monetize such projects?
  - joaoh82 6mo ago
    About monetization, that is definitely very important. For now, and not sure how long, could be days or weeks, I am offering api-keys at no charge, because I want the feedback of real users. But obviously that is not sustainable in the long term, servers cost money and monetization also help keep the project alive. At a second stage, I am planning to offer monthly or yearly plans with different limitations or unlimited also. But I am also planning on offering pay per use with short lives api-keys targeting agentic workflows, for example or people that dont really want to pay a monthly fee, but instead just cents for a short-lived tunnel. For the monthly plans, I am planning to keep as low cost as possible, just enough to maintain the infrastructure and development + some overhead.
basedhusky46 6mo ago
[flagged]
- dizhn 6mo ago
  verbatim
ollybee 6mo ago
Add it to the list https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling
- joaoh82 6mo ago
  Nice! Will do!
mewrcreate 6mo ago
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.
- joaoh82 6mo ago
  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.
kwakubiney 6mo ago
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. [1]https://github.com/kwakubiney/outbound https://github.com/kwakubiney/outbound
- joaoh82 6mo ago
  Interesting! I'll take a look.
veverkap 6mo ago
Not trying to be a jerk but how is this different than the Rust solutions listed on https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling already? What makes your solution better or different?
- joaoh82 6mo ago
  [flagged]
  - morgaesis 6mo ago
    We know what open source is. You failed to answer how your solution is _different_ from others on the list. Your readme won't answer that question.
- rgilliotte 6mo ago
  Fair point, and honestly at work I'd push back the same way: shipping a custom tunnel solution when mature ones exist? Why? But for personal projects I think the calculus is different. Rebuilding something is great to understand how it works
  - lsharkey602 6mo ago
    I'm not experienced like some people posting here, but vouching for this comment that projects may have value for personal development and education.
Boulos00191 6mo ago
[flagged]
- dizhn 6mo ago
  verbatim
jockm 6mo ago
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)
- loeg 6mo ago
  This isn't responsive to the article. Please avoid generic tangents.
  - jockm 6mo ago
    I disagree, it was a response to the article's title. I could have said it better, but it wasn't just a random rant
- jamesreadsnews 6mo ago
  I feel knowing the language is important when sharing an open source project. From the title, I know this is something I could edit/review/use.
  - jockm 6mo ago
    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?
merb 6mo ago
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.
search_facility 6mo ago
Interesting! Can it be used in Google Colab to open temporary access to python server? NGROK can be attached this way in 6 lines of code
- joaoh82 6mo ago
  that is a very good use case. I am definitely adding this to the roadmap at least a maybe. Thanks for the question.
davidliu847386 6mo ago
[flagged]
DeepTradeX_83 6mo ago
[dead]
goatyishere25 6mo ago
[flagged]
ChrisLanca61570 6mo ago
[dead]
davidliu847386 6mo ago
[dead]
igor47 6mo ago
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 https://igor.moomers.org/posts/basic-tunnel

107 points by joaoh82 6mo ago

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.

OpenDQV 6mo ago
nice - i will check this out! but to be honest ngrok is working well for me. tell me why i should change?
- joaoh82 6mo ago
  For now is free. And when we start charging will definitely be cheaper. Also, the project is open source and there is good documentation on how to standup your own infra, if you want to go down that path.

mikeocool 6mo ago

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.

danielbln 6mo ago
Once a business takes on VC and/or goes public, enshittification will inevitably follow.
- simantel 6mo ago
  Wow I had no idea ngrok had raised $50M, that's wild!

joaoh82 6mo ago

Btw, if anyone wants to test on our own servers just request an api key with github issues: https://github.com/joaoh82/rustunnel?tab=readme-ov-file#getting-an-auth-token https://github.com/joaoh82/rustunnel?tab=readme-ov-file#gett...

freedomben 6mo ago

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.

thegreatpeter 6mo ago
It should be monetized to support the long term commitment
- freedomben 6mo ago
  I have no problem with monetization. I do have a problem with rug-pulling, especially if it's a tool I'm adopting into my workflow. I ask about monetization strategy because it can be an indicator. If the answer is, "never thought about it" then rug pull is a strong possibility. If the answer is, "planning to offer paid hosting" then that can be a positive sign.
  - joaoh82 6mo ago
    Very good points. Including the AGPL, that is definitely a better license for this type of project. I am just used to starting with MIT when I start a new open source project, but you have a point. About monetization, that is definitely very important. For now, and not sure how long, could be days or weeks, I am offering api-keys at no charge, because I want the feedback of real users. But obviously that is not sustainable in the long term, servers cost money and monetization also help keep the project alive. At a second stage, I am planning to offer monthly or yearly plans with different limitations or unlimited also. But I am also planning on offering pay per use with short lives api-keys targeting agentic workflows, for example or people that dont really want to pay a monthly fee, but instead just cents for a short-lived tunnel. For the monthly plans, I am planning to keep as low cost as possible, just enough to maintain the infrastructure and development + some overhead.

abricq 6mo ago

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 ?

johnisgood 6mo ago
Hmm, how to monetize such projects?
- joaoh82 6mo ago
  About monetization, that is definitely very important. For now, and not sure how long, could be days or weeks, I am offering api-keys at no charge, because I want the feedback of real users. But obviously that is not sustainable in the long term, servers cost money and monetization also help keep the project alive. At a second stage, I am planning to offer monthly or yearly plans with different limitations or unlimited also. But I am also planning on offering pay per use with short lives api-keys targeting agentic workflows, for example or people that dont really want to pay a monthly fee, but instead just cents for a short-lived tunnel. For the monthly plans, I am planning to keep as low cost as possible, just enough to maintain the infrastructure and development + some overhead.

basedhusky46 6mo ago

[flagged]

dizhn 6mo ago
verbatim

ollybee 6mo ago

Add it to the list https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling

joaoh82 6mo ago
Nice! Will do!

mewrcreate 6mo ago

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.

joaoh82 6mo ago
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.

kwakubiney 6mo ago

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. [1]https://github.com/kwakubiney/outbound https://github.com/kwakubiney/outbound

joaoh82 6mo ago
Interesting! I'll take a look.

veverkap 6mo ago

Not trying to be a jerk but how is this different than the Rust solutions listed on https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling already? What makes your solution better or different?

joaoh82 6mo ago
[flagged]
- morgaesis 6mo ago
  We know what open source is. You failed to answer how your solution is _different_ from others on the list. Your readme won't answer that question.
rgilliotte 6mo ago
Fair point, and honestly at work I'd push back the same way: shipping a custom tunnel solution when mature ones exist? Why? But for personal projects I think the calculus is different. Rebuilding something is great to understand how it works
- lsharkey602 6mo ago
  I'm not experienced like some people posting here, but vouching for this comment that projects may have value for personal development and education.

Boulos00191 6mo ago

[flagged]

dizhn 6mo ago
verbatim

jockm 6mo ago

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)

loeg 6mo ago
This isn't responsive to the article. Please avoid generic tangents.
- jockm 6mo ago
  I disagree, it was a response to the article's title. I could have said it better, but it wasn't just a random rant
jamesreadsnews 6mo ago
I feel knowing the language is important when sharing an open source project. From the title, I know this is something I could edit/review/use.
- jockm 6mo ago
  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?

merb 6mo ago

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.

search_facility 6mo ago

Interesting! Can it be used in Google Colab to open temporary access to python server? NGROK can be attached this way in 6 lines of code

joaoh82 6mo ago
that is a very good use case. I am definitely adding this to the roadmap at least a maybe. Thanks for the question.

davidliu847386 6mo ago

[flagged]

DeepTradeX_83 6mo ago

[dead]

goatyishere25 6mo ago

[flagged]

ChrisLanca61570 6mo ago

[dead]

davidliu847386 6mo ago

[dead]

igor47 6mo ago

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 https://igor.moomers.org/posts/basic-tunnel