[HN Gopher] A ngrok-style secure tunnel server written in Rust a...
___________________________________________________________________
A ngrok-style secure tunnel server written in Rust and Open Source
Author : joaoh82
Score : 70 points
Date : 2026-03-18 14:00 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| joaoh82 wrote:
| 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 wrote:
| nice - i will check this out! but to be honest ngrok is working
| well for me. tell me why i should change?
| joaoh82 wrote:
| 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 wrote:
| 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 wrote:
| Once a business takes on VC and/or goes public,
| enshittification will inevitably follow.
| simantel wrote:
| Wow I had no idea ngrok had raised $50M, that's wild!
| joaoh82 wrote:
| 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#gett...
| freedomben wrote:
| 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 wrote:
| It should be monetized to support the long term commitment
| freedomben wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Hmm, how to monetize such projects?
| joaoh82 wrote:
| 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.
| ollybee wrote:
| Add it to the list https://github.com/anderspitman/awesome-
| tunneling
| joaoh82 wrote:
| Nice! Will do!
| mewrcreate wrote:
| 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 wrote:
| 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 wrote:
| 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
| joaoh82 wrote:
| Interesting! I'll take a look.
| veverkap wrote:
| Not trying to be a jerk but how is this different than the Rust
| solutions listed on https://github.com/anderspitman/awesome-
| tunneling already?
|
| What makes your solution better or different?
| joaoh82 wrote:
| Its not mine, its ours. That is what Open Source is about.
|
| All I know is that I try to build a fast, low latency solution,
| that I can provide for low cost or people can just self-host
| themselves. I am trying to keep the docs pretty good.
| jockm wrote:
| 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 wrote:
| This isn't responsive to the article. Please avoid generic
| tangents.
| jockm wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| that is a very good use case. I am definitely adding this to
| the roadmap at least a maybe.
|
| Thanks for the question.
| davidliu847386 wrote:
| this is the kind of thing i wish existed 2 years ago when i was
| debugging that mess
___________________________________________________________________
(page generated 2026-03-18 23:00 UTC)