The Rust Tunneling Rebellion: Why Tools Like Tunnelto Are Surging on GitHub

There’s a real trend in the developer community: a steady migration away from commercial SaaS tunneling proxies toward lightweight, open-source tools written in Rust. Much of it comes down to “free tier fatigue” — developers who are tired of bandwidth caps, endpoint limits, and interstitial warning pages when all they want to do is test a webhook.

In late December 2025, the open-source tool Tunnelto had a genuine viral moment on GitHub, gaining 565 stars in a single day and hitting #3 on GitHub’s trending page. That spike wasn’t manufactured — it reflected real frustration among developers looking for a capable, self-hostable, free alternative to ngrok. It’s also a useful entry point into a broader shift toward privacy-conscious, self-hosted developer tooling.

In this guide: why developers are turning to Rust reverse proxies, a fact-checked Tunnelto vs ngrok comparison, other open source ngrok alternatives worth knowing, and how self-hosting a Rust tunnel actually works in practice.

---

The Core Problem: The Localhost Dilemma

Every web developer hits the same wall eventually. You’re building something that needs to talk to a third-party service — Stripe for payments, Twilio for SMS, Slack for slash commands. These platforms communicate via webhooks: HTTP requests sent to a URL you specify when an event happens.

The problem: Stripe can’t send a webhook to http://localhost:3000. Your dev server sits behind your router’s NAT and firewall, invisible to the outside internet.

The Old Solutions

Before tunneling tools were mainstream, developers worked around this with:

1. Deploying to staging — commit, push, wait for CI/CD, then trigger the webhook. A five-second feedback loop turns into a five-minute one.
2. Router port forwarding — technically possible, tedious, and not something you want open on your home network.
3. Mocking events — capture a payload once and replay it locally, but this misses real-world edge cases.

The Rise of Localhost Tunnels

A tunneling client runs on your machine, opens an outbound connection to a public relay server, and hands you a public URL. When Stripe hits that URL, the relay forwards the traffic down the tunnel to your local port.

For years, ngrok was the default. It became nearly synonymous with localhost tunneling. But as the company matured into a broader security and API platform, some of its free-tier decisions pushed part of its user base to look elsewhere.

---

Free Tier Fatigue: What’s Actually True About ngrok’s Free Tier

This is where a lot of “ngrok vs. the world” content online gets sloppy, so it’s worth being precise about what ngrok’s free tier actually restricts, per ngrok’s own current documentation.

There is no 2-hour session limit

This claim circulates constantly in comparison posts, but it doesn’t hold up against ngrok’s published pricing and limits documentation. ngrok’s free plan is described as free-forever and is not time-boxed by session length — you won’t get disconnected purely because two hours have passed. What free-tier users actually run into is a mix of:

• 1GB of bandwidth per month, plus a one-time $5 usage credit
• Up to 3 online endpoints at a time (this cap doesn’t reset monthly)
• ~20,000 HTTP requests per month
• Random, rotating subdomains on every reconnect — this is the thing that actually breaks a webhook workflow, since you have to re-register the URL with Stripe or wherever every time you restart

If your tunnel is dropping mid-session, it’s more likely a network hiccup, a client restart, or hitting the bandwidth/request cap than a hard-coded timer. Worth correcting in your own head if you’ve seen this “2-hour limit” claim elsewhere — it’s one of the most repeated inaccuracies in this space.

The interstitial warning page is real

To cut down on phishing and malware abuse, ngrok does inject an HTML interstitial (“Visit Site”) page in front of browser traffic on free-tier URLs. ngrok provides a header (ngrok-skip-browser-warning) to bypass it for API clients, but many webhook providers don’t let you inject custom headers into their outbound requests — so this genuinely does break some automated webhook delivery on the free tier.

Current ngrok pricing (as of mid-2026)

ngrok runs four tiers: Free, Hobbyist, Pay-as-you-go, and Enterprise.

• Free — $0/month, $5 one-time usage credit, 1GB bandwidth, 3 online endpoints, ~20k requests/month
• Hobbyist — $10/month ($8/month billed annually), $10 monthly usage credit, 5GB bandwidth, 3 endpoints, ~100k requests/month
• Pay-as-you-go — $20/month base fee (includes $20 of usage), then metered billing on data transfer, requests, and endpoint hours beyond that
• Enterprise — custom pricing, typically negotiated per-deployment

So the “$8–$29/month” framing from older comparison posts is roughly the right ballpark for Hobbyist/Pay-as-you-go, but the actual tier names and structure have shifted a few times — worth re-checking ngrok’s pricing page directly before quoting numbers, since this has changed more than once in the past year.

---

The Rust Rebellion: Enter Tunnelto

In late December 2025, Tunnelto — a Rust tunneling tool created by developer Alex Grinman (GitHub: agrinman/tunnelto) — spiked to #3 on GitHub’s trending page, gaining 565 stars in 24 hours. At the time it sat around 3,665 stars; it’s continued growing since and is now in the 6,000–7,000 star range, with roughly 500+ forks.

A detail worth flagging clearly, because it trips up a lot of comparison articles: there are two unrelated products that both go by “tunnelto.”

• tunnelto.dev (agrinman/tunnelto on GitHub) — the open-source, MIT-licensed Rust project this section is about. Its most recent client release, v0.1.18, shipped in May 2021. The project isn’t abandoned — issues get occasional attention and the hosted demo instance at tunnelto.dev still runs on Fly.io — but no new CLI features have shipped in years, and the self-hosted server doesn’t support custom domains or built-in authentication out of the box.
• tunnelto.me — a completely separate, actively maintained commercial tunneling service that happens to share a similar name. It has its own free tier (1 custom domain, 1GB bandwidth/month, 1-hour tunnel sessions) and paid plans starting around $2/month for persistent domains.

These are not the same codebase, the same team, or the same product — despite what several “ngrok alternatives” roundups imply by citing tunnelto.me’s pricing page as if it describes the open-source tunnelto.dev project.

The Architecture of Tunnelto (tunnelto.dev)

Tunnelto is built entirely on async-io on top of Tokio, Rust’s standard async runtime. The system has two pieces:

1. The client — a lightweight Rust binary you run locally (tunnelto --port 8000), which opens an outbound TCP connection to the Tunnelto server.
2. The server — a Rust application on a public-facing host that terminates incoming HTTP/HTTPS requests and multiplexes them down the correct client connection.

Because it’s Rust with an async runtime, it handles many concurrent connections with a small memory footprint compared to a Node.js or Python equivalent doing the same job.

Why did it spike?

A few plausible, non-exclusive explanations for the December 2025 surge:

1. Accumulated friction with ngrok’s free-tier constraints (bandwidth caps, endpoint limits, interstitial pages) reaching a tipping point for a chunk of developers.
2. A preference for ownership — being able to read, fork, and self-host the code rather than depend on someone else’s cloud service.
3. Rust’s general halo effect — Rust has topped Stack Overflow’s “most admired language” survey for multiple years running, and JetBrains’ 2025 State of Developer Ecosystem report put the number of developers who’d used Rust in the past 12 months at roughly 2.27 million. Tools written in Rust tend to get a credibility bump on “fast and safe” grounds alone.

Take the virality narrative with a little skepticism, though — most of the specific “why it surged” framing traces back to a single blog post from the day it trended, not any kind of survey data.

---

Tunnelto vs ngrok: A Comparison

1. Pricing and limits

• ngrok: Free tier as described above (1GB bandwidth, 3 endpoints, random URLs, interstitial page). Hobbyist starts at $10/month ($8 annually); Pay-as-you-go starts at $20/month base plus usage.
• tunnelto.dev (open source): The software itself is free and MIT-licensed — you can self-host it on any VPS at whatever that VPS costs you (a $5/month droplet is plenty). There’s no built-in metering or paid tier for the open-source project itself, but there’s also no custom-domain or auth support without adding your own reverse proxy in front of it.
• (If what you actually want is a hosted, actively maintained commercial tunnel with custom domains on the free tier, that’s tunnelto.me — a different product, priced from $0 with paid plans from roughly $2/month for persistent domains. Don’t conflate the two when comparing costs.)

2. Developer experience

• ngrok: Mature CLI, wide framework integration, and a dashboard with real HTTP traffic inspection.
• tunnelto.dev: A single command (tunnelto --port 3000) gets you a public URL fast. It’s intentionally minimal — you’re trading ngrok’s traffic-inspection tooling for simplicity and the absence of forced interstitials.

3. Hosting and control

• ngrok: Closed source, fully dependent on ngrok’s cloud. If their infrastructure has issues, your tunnel does too.
• tunnelto.dev: MIT-licensed. You can read the code, fork it, and run the server yourself — the project documents deploying the server binary (compiled for the musl target) via Docker with configuration through environment variables. You own the uptime and the infrastructure.

4. Custom domains

• ngrok: Custom/stable domains require a paid tier.
• tunnelto.dev (self-hosted): You can point your own domain at your own server, but you’re responsible for TLS termination yourself (typically via Nginx or Caddy in front of the tunnel server) — this isn’t handled automatically the way it is on some competitors.

---

Exploring the Ecosystem: Other Open Source ngrok Alternatives

Tunnelto is far from the only option. Here’s where the rest of the field actually stands, fact-checked against each project’s own repo.

1. rustunnel

An AGPL-licensed Rust tunneling tool (GitHub: joaoh82/rustunnel) that’s self-hostable or available as a managed pay-as-you-go service. Its standout feature relative to the rest of this list is a first-class MCP server for AI agents, alongside UDP support, P2P tunnels, and load-balancing groups with health checks — genuinely differentiated from the older tools here, which predate the current wave of agent tooling.

2. bore

Created by Eric Zhang (ekzhang/bore), bore is a deliberately minimal MIT-licensed TCP tunnel — about 400 lines of async Rust. It sits around 11,100 stars. It does one thing: forward a local TCP port to a remote server. No HTTP parsing, no TLS termination, no dashboard.

Worth knowing if you’re evaluating it: bore’s optional --secret flag adds HMAC-based authentication for who can open a tunnel, but per its own docs, that only covers the handshake — the actual tunneled traffic isn’t encrypted by default. If you’re forwarding something that isn’t already doing its own TLS, that traffic is visible to anyone positioned to observe it in transit. This nuance gets left out of a lot of “bore vs. ngrok” comparisons.

3. rathole

Positioned as a higher-performance alternative to frp (GitHub: rathole-org/rathole), rathole supports both TCP and UDP, targets resource-constrained environments like embedded devices and routers (the binary can be as small as ~500KB), and supports hot-reloading its config without restarting.

4. frp (Fast Reverse Proxy)

Written in Go, not Rust, but the undisputed heavyweight of this category — fatedier/frp sits at roughly 108,000 GitHub stars and 15,000 forks, making it larger than every Rust alternative on this list combined by a wide margin. It supports HTTP, HTTPS, TCP, UDP, and WebSockets, configured via TOML, and remains the default choice for complex production self-hosted deployments.

5. Cloudflare Tunnel (cloudflared)

Not open-source end-to-end (the server side is Cloudflare’s), but the cloudflared client is open source and the service itself is free with any Cloudflare account. As of 2026, Cloudflare Tunnel defaults to QUIC (HTTP/3) transport and sits inside the broader “Cloudflare One” Zero Trust platform — meaning you can put an Access policy (SSO, email OTP, or third-party identity providers) in front of a tunneled service at no cost, for up to 50 users, without writing any auth code yourself. It requires Cloudflare-managed DNS for named tunnels with custom hostnames, though quick tunnels (cloudflared tunnel --url) work without a domain, similar to ngrok’s free tier.

---

Why Rust Fits This Job

It’s not a coincidence that so many current tunneling tools (Tunnelto, bore, rathole, rustunnel) are written in Rust:

1. High concurrency, low memory — a tunnel server can hold thousands of idle connections open. Rust’s async model handles that with a much smaller memory footprint than a garbage-collected runtime managing the same load.
2. Predictable latency — no GC pauses means no unpredictable micro-stutters, which matters for anything real-time like WebSockets.
3. Memory safety — network-facing proxies are a common target for memory-corruption bugs in C/C++. Rust’s compiler eliminates whole classes of these at compile time.
4. Cross-platform static binaries — Rust cross-compiles cleanly, so you get a single binary with no runtime dependencies to install.

---

Self-Hosting a Rust Localhost Tunnel: What’s Actually Involved

If you want to run your own tunnel server instead of relying on someone else’s, here’s a realistic picture of what that takes — using Tunnelto’s own documented self-hosting path as the example, rather than an idealized version of it.

Prerequisites

• A VPS with a public IP (DigitalOcean, Linode, AWS EC2, etc.)
• A domain pointed at that VPS, if you want a custom domain
• Comfort with SSH, Docker, and basic reverse-proxy configuration

Step 1: Install the Rust toolchain (if building from source)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env

Step 2: Get the server running

Tunnelto’s server is documented as a Docker deployment, compiled for the musl target, configured through environment variables — not a single interactive CLI flag for setting a custom domain. Clone the repo and either build from source or pull the published image:

git clone https://github.com/agrinman/tunnelto.git
cd tunnelto/tunnelto_server
cargo build --release

Realistically, plan on running this behind Nginx or Caddy for TLS termination — the self-hosted server doesn’t handle automatic HTTPS or custom-domain routing on its own the way the hosted tunnelto.dev demo instance does.

Step 3: Connect with the client

cargo install tunnelto
tunnelto --port 3000

By default this points at the hosted tunnelto.dev service. Pointing the client at your own self-hosted server requires configuring the client to use your server’s address — check the current CLI help (tunnelto --help) for the exact flag on the version you’ve installed, since this is one of the areas where undocumented forks and older tutorials tend to drift from what the current binary actually supports.

One honest caveat: the project’s own documentation notes that the self-hosted version doesn’t cleanly support running multiple server instances without extra coordination work, since it relies on centralized state. Fine for a single personal or small-team deployment; not a drop-in replacement for ngrok’s production-grade managed infrastructure without additional engineering on your end.

---

The Broader Trend: Owning the Developer Experience

The pattern behind Tunnelto’s spike is bigger than one repo. For years, the default move was to outsource every piece of infrastructure to a specialized SaaS provider. That still makes sense for things like managed databases or global CDNs — but for a comparatively simple utility like localhost tunneling, more developers are deciding it doesn’t need to sit behind a recurring subscription.

Self-hosting a permanent, custom-domain tunnel on a $5/month VPS — shared across a whole team — makes the economics of a $20+/month per-user commercial plan a much harder sell for teams that don’t need ngrok’s traffic inspection, enterprise SSO, or SLA guarantees.

Conclusion

The “Rust Tunneling Rebellion” is a real, if modest, course correction rather than a wholesale replacement of commercial tunneling. ngrok’s free tier is more restrictive than it once was — bandwidth caps, endpoint limits, and forced interstitials are real constraints — but the “2-hour session limit” claim that circulates in a lot of comparison content simply isn’t accurate as of ngrok’s current documentation, and it’s worth correcting whenever you see it repeated.

Tools like Tunnelto, bore, rathole, and rustunnel genuinely do offer free, self-hostable, often faster alternatives for developers who don’t need ngrok’s enterprise feature set. Just watch for the tunnelto.dev/tunnelto.me naming collision when you’re comparing pricing — they’re unrelated products, and a lot of “ngrok alternative” roundups get this wrong. Whether you’re picking a hosted free tier from one of the newer entrants or spinning up your own self-hosted Rust tunnel, the option space here is genuinely wider — and cheaper — than it was two years ago.

---

Changelog

• Removed the false “2-hour ngrok free-tier session limit” claim (repeated across multiple sections of the original draft) and replaced it with ngrok’s actual documented free-tier constraints: 1GB bandwidth/month, 3 online endpoints, ~20k requests/month, random rotating subdomains, and the interstitial warning page.
• Corrected ngrok’s current plan structure and pricing: Free ($0), Hobbyist ($10/mo, $8/mo annual), Pay-as-you-go ($20/mo base + usage), Enterprise (custom) — replacing the vaguer “$8–$29/month” framing.
• Major correction: identified and fixed a conflation running through the original draft’s pricing and custom-domain sections — tunnelto.dev (the open-source agrinman/tunnelto Rust project) and tunnelto.me (an unrelated commercial hosted tunneling service) are different products with no connection to each other. The original draft attributed tunnelto.me’s custom-domain-on-free-tier and $2/month pricing to the open-source project.
• Updated Tunnelto (tunnelto.dev) GitHub stats: grew from 3,665 stars (Dec 27, 2025, the day it trended) to roughly 6,000–7,000 stars currently; noted its most recent client release (v0.1.18) shipped in May 2021 and that the self-hosted server lacks built-in custom-domain/TLS automation.
• Corrected the self-hosting walkthrough: removed an unverified tunnelto set-host command that doesn’t appear in the project’s current documentation, and replaced it with the project’s actual documented Docker/environment-variable-based self-hosting path, including the caveat that multi-server self-hosting isn’t cleanly supported out of the box.
• Added verified current stats for the ecosystem section: bore (~11,100 stars, created by Eric Zhang, MIT-licensed, plus a security caveat that its --secret flag authenticates handshakes but doesn’t encrypt tunneled traffic by default); frp (~108,000 stars — updated from “100,000+”); rathole (confirmed TCP/UDP support and embedded-device focus); rustunnel (confirmed AGPL license, GitHub repo joaoh82/rustunnel, and MCP-for-AI-agents feature).
• Removed an unsubstantiated claim that rustunnel is “ranked highly in recent 2026 developer surveys” — no independent survey data supporting this was found; the only source was rustunnel’s own marketing site.
• Updated Cloudflare Tunnel section with 2026-current details: QUIC/HTTP3 as the default transport, the “Cloudflare One” Zero Trust rebrand, and free Zero Trust Access policies for up to 50 users.
• Verified the Rust adoption figure (~2.27 million developers in the past 12 months) against JetBrains’ 2025 State of Developer Ecosystem report, replacing the original’s unsourced “2.26 million” figure with a cited one.
• Removed inline citation brackets and the numbered references list from the original draft for readability; sourcing is now woven into the prose directly.