Why Developers Are Replacing ngrok with Rust-Based Tunnels
IT
Current comparison
Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.
Open the InstaTunnel ngrok alternative guideQuick answer
Why Developers Are Replacing ngrok with 2MB Rust Binaries: localhost tunnel answer
A localhost tunnel gives your local app a public HTTPS URL without opening router ports, which is useful for demos, QA, mobile testing, and provider callbacks.
How do I expose localhost without opening ports?
Use a reverse HTTPS tunnel. Your machine connects outbound to the tunnel service, and the public URL forwards requests back to your local app.
When should I use a localhost tunnel?
Use one for webhook testing, OAuth callbacks, client demos, QA previews, mobile device checks, and short-lived development reviews.
If you’ve spent any time developing webhooks, testing APIs, or trying to reach a home lab server remotely, you know the standard playbook: install ngrok, run a command, get a public URL that forwards to your localhost. For years this was the default choice for NAT traversal and local tunneling.
But a shift is underway, especially among edge-computing engineers, IoT hobbyists, and home-labbers. As commercial tunneling SaaS products add more enterprise features (and enterprise pricing), developers are increasingly weighing open-source, minimalist alternatives — many of them written in Rust.
Go-based frp (Fast Reverse Proxy) has long been the dominant open-source option, and it remains the largest project in this space by a wide margin. Alongside it, a smaller set of Rust tools — rathole, bore, and the hosted service tunnelto — have built real followings by trading frp’s feature breadth for a smaller footprint and, in rathole’s case, specifically better behavior under load on constrained hardware.
Here’s an honest look at what these tools actually do well, where the “Rust beats Go” narrative holds up, and where it’s overstated.
The Free-Tier Question: What ngrok’s Free Plan Actually Gives You
A lot of the “switch to X” content around ngrok repeats a claim that hasn’t been accurate for a few years: that free-tier users get a random subdomain that changes every time the tunnel reconnects. That was true in ngrok’s earlier years, but ngrok has assigned each free account a persistent dev domain (like your-assigned-name.ngrok-free.app) tied to the account since 2023 — it stays the same across restarts, and ngrok’s own documentation confirms free endpoints have no session timeout and can run indefinitely as a background service.
What the free plan doesn’t include is the ability to pick your own subdomain name or bring your own domain — that’s genuinely gated behind paid plans (Hobbyist for a custom *.ngrok.app name, Pay-as-you-go for your own domain). So the real friction isn’t rotating URLs; it’s that you can’t brand or reuse a specific name without paying, and TCP endpoints need a verified credit card even on the free tier.
That distinction matters, because it’s the actual reason developers reach for alternatives — not a myth about 2-hour sessions or constantly-changing URLs.
The Case for Rust at the Edge
Go’s garbage collector introduces non-deterministic pause behavior. This is rarely noticeable on a cloud VM, but under sustained high connection volume on constrained hardware — an OpenWrt router, an early Raspberry Pi — GC pauses and buffer growth can push memory usage high enough to trigger the Linux OOM killer.
Rust achieves memory safety without a garbage collector, so there are no GC pauses, and memory usage tends to stay flat even under connection spikes. Combined with tokio’s async runtime, this lets Rust tunnels ship small, dependency-light binaries with predictable latency.
That’s the theory. Here’s how it plays out for each tool.
1. rathole: The Leaner frp Alternative
Originally built by GitHub user rapiz1 and now maintained under the rathole-org organization, rathole sits at 14,000 GitHub stars and 800 forks as of this writing, licensed Apache-2.0.
What it strips out
rathole intentionally drops frp’s web dashboard, load balancer, and plugin system, focusing on TCP/UDP forwarding with a client/server TOML config.
The benchmark claim, with context
rathole’s README states it achieves similar latency to frp but handles more connections with less memory. The specific numbers come from rathole’s own docs/benchmark.md: at QPS levels from 1 to 3,000, rathole and frp showed nearly identical latency; at 4,000 QPS, frp began reporting errors with latency climbing into the seconds, while rathole’s latency stayed flat. Under a sustained 30-second load test, frp’s memory usage grew substantially while rathole’s stayed close to flat.
Two things worth knowing before you treat this as settled: the benchmark was run once, on a single machine (an Arch Linux box with a dual Xeon E5-2620), dated December 2021, and it compared an early rathole build against frp v0.38.0 — a version now roughly 30 releases behind frp’s current v0.70.x line. It’s also a loopback test, which the rathole docs themselves note reflects CPU-bound performance rather than real network conditions. The directional finding (lower, flatter memory use under load) is plausible given the GC-vs-no-GC architectural difference, but there’s no independent, current benchmark confirming the exact numbers still hold against modern frp.
Standout features
- The Noise Protocol: rathole can optionally use the Noise Protocol framework for transport encryption instead of managing self-signed TLS certificates. Noise is also what secures WireGuard’s handshake, and it secures WhatsApp’s client-to-server transport layer specifically — WhatsApp’s actual end-to-end message encryption is a separate system, the Signal Protocol. So the WireGuard comparison is precise; the WhatsApp comparison is accurate but narrower than “the same encryption WhatsApp uses for your messages.”
- Small binary: rathole’s own build guide gets a minimal x86_64 build down to 574 KiB, versus roughly 10 MiB for frpc built the same way.
- Mandatory per-service tokens: every service requires its own token, a deny-by-default posture.
- Hot-reloadable config: services can be added or removed without restarting.
Maintenance status
This is the most important correction to make: rathole’s last tagged release, v0.5.0, shipped October 1, 2023 — just under three years ago. That’s accurate to what’s often claimed. But it isn’t abandoned: the repository has an active dev branch with automated builds (most recently in early 2026), and issues/PRs were still being opened and merged into 2025 and 2026. It’s more accurate to call rathole “stable and lightly maintained without new stable tags” than either “actively evolving” or “dead.”
2. bore: The Minimal TCP Tunnel
Created by Eric Zhang and MIT-licensed, bore sits at 11,100 GitHub stars and 493 forks, with its most recent release (v0.6.0) shipping in June 2025.
The codebase
bore’s entire client and server implementation is about 400 lines of async Rust on top of tokio — small enough to read in one sitting.
How it works
bore local 8000 --to bore.pub
This exposes local port 8000 at bore.pub:<random_port> using the maintainer’s public server. To self-host:
bore server
A security detail worth knowing
bore supports an optional --secret flag (or BORE_SECRET env var) that requires clients to prove possession of a shared secret via HMAC challenge before a tunnel is accepted. That’s real authentication for who can open a tunnel through your server. But per bore’s own documentation, that secret only covers the initial handshake — the proxied traffic itself is not encrypted by default. If you’re tunneling anything other than a service that’s already doing its own TLS (an HTTPS dev server, for instance), that’s worth knowing before you point it at something sensitive. This nuance is absent from most “bore vs. ngrok” comparisons circulating online.
3. tunnelto: Two Different Projects Sharing a Name
This is the section that needed the most correction. “tunnelto” actually refers to two separate, unrelated projects, and conflating them (as is common in comparison articles) produces a misleading picture.
tunnelto.dev (agrinman/tunnelto on GitHub) is the open-source, MIT-licensed Rust project. Its last release shipped in 2021, and by its own successor’s account, it hasn’t been updated since — it also lacks custom-domain, endpoint-auth, and static-hosting features.
tunnelto.me is a separate, actively maintained hosted service that happens to share the name. Per tunnelto.me’s own site (checked June 2026), it is not built on the abandoned tunnelto.dev codebase — its own comparison table explicitly marks tunnelto.dev as “not actively maintained since 2021.” The tunnelto.me pricing is:
| Plan | Price | Custom domain | Tunnel persistence |
|---|---|---|---|
| Free | $0 | 1, included | 1-hour tunnels only — must recreate |
| Hobbyist | $2/mo | 1 | Persistent (survives reboots) |
| Plus | $10/mo | 3 | Persistent |
| Pro | $20/mo | 5 | Persistent |
The genuinely notable thing here — and it’s real — is that a custom domain is included on the free plan at all, which most competitors (including ngrok and bore) gate behind a paid tier. But the free plan’s tunnels expire after one hour and have to be re-created, which is its own version of a session limit, just a different shape than ngrok’s. If you want a tunnel that survives overnight or a reboot, that’s the $2/month Hobbyist tier, not the free one. Tunnel authentication (Bearer/Basic) is also a paid-tier feature, not included free.
Comparison Summary
| Feature | ngrok | frp | rathole | bore | tunnelto.me |
|---|---|---|---|---|---|
| Language | Go | Go | Rust | Rust | Not publicly specified |
| GitHub stars | — (closed source) | ~107k | 14.0k | 11.1k | — (hosted, closed source) |
| Primary focus | Commercial SaaS | Self-hosted, feature-rich | Self-hosted, low-resource | Self-hosted, minimal TCP | Hosted SaaS, custom domains |
| Custom domain, free tier | No (persistent dev domain only) | Yes (self-hosted) | Yes (self-hosted) | N/A (port-based) | Yes, but 1-hour tunnel limit |
| Binary/agent size | Proprietary agent | ~10 MiB (frpc) | ~574 KiB (minimal build) | Small, ~400 LOC | Native binary (language unconfirmed) |
| Traffic encryption by default | Yes (HTTPS) | TLS optional | TLS or Noise optional | No — only handshake auth is optional | Yes (HTTPS by default) |
| Last release | Continuous | Actively releasing (v0.70.x, 2026) | v0.5.0, Oct 2023 (dev branch active) | v0.6.0, June 2025 | Actively maintained (2026) |
| Setup complexity | Very low | High (many config options) | Medium (client/server TOML) | Zero (single command) | Very low |
frp: Worth a Fair Word
Any “Rust replaces Go” narrative should acknowledge that frp is not a stagnant, bloated legacy project. It currently sits at roughly 107,000 stars and 15,000 forks, and it ships new minor releases on a roughly monthly cadence — v0.68 through v0.70 all shipped in the first half of 2026, with active security patching (a moderate-severity auth-bypass advisory was published and fixed in April 2026). If your requirements go beyond simple TCP/UDP forwarding — plugins, a web dashboard, SSH tunnel gateways, broader protocol support — frp remains the most feature-complete open-source option, and “GC pauses under extreme load” is a real but narrow tradeoff, not evidence the project is falling behind.
How to Set Up a Low-RAM Localhost Tunnel (rathole on Raspberry Pi)
If you have a Raspberry Pi at home and a cheap VPS in the cloud, a rathole tunnel takes about ten minutes to set up.
Step 1 — Configure the VPS. Download the rathole binary for your VPS architecture from the releases page. Create server.toml:
[server]
bind_addr = "0.0.0.0:2333"
[server.services.my_pi_ssh]
token = "use_a_secret_that_only_you_know"
bind_addr = "0.0.0.0:5202"
Start it:
./rathole server.toml
Step 2 — Configure the Raspberry Pi. Download the ARM/AArch64 binary. Create client.toml:
[client]
remote_addr = "YOUR_VPS_IP:2333"
[client.services.my_pi_ssh]
token = "use_a_secret_that_only_you_know"
local_addr = "127.0.0.1:22"
Start it:
./rathole client.toml
Step 3 — Connect. From anywhere:
ssh pi@YOUR_VPS_IP -p 5202
For production use, wrap both commands in systemd service files (rathole’s repo includes example unit files) so they restart automatically on boot or crash. If you want transport encryption without managing certificates, add a [client.transport.noise] / [server.transport.noise] block using the Noise protocol instead of the token-only setup above — the token alone authenticates the service but doesn’t encrypt the tunnel.
Bottom Line
- Need a stable URL for webhook testing with the least setup? tunnelto.me’s free custom domain is genuinely useful — just budget for the $2/month tier if you need it to outlive an hour.
- Need to share a TCP port with a teammate with zero config, and you’re comfortable that the pipe itself isn’t encrypted unless your upstream service handles that? bore.
- Running a fleet of low-RAM edge devices and want the smallest footprint with real (if dated) evidence of stability under load? rathole — just don’t expect a new stable release soon.
- Need plugins, a dashboard, broad protocol support, or you’re already comfortable with Go tooling? frp is still the most complete option and remains actively developed.
- Need enterprise features — SSO, traffic policy, audit logs, a managed edge network — and don’t mind paying for them? That’s what ngrok is actually for at this point; its free tier is more usable than its reputation suggests, but it’s not competing on the same axis as these self-hosted tools.
Changelog
- Removed all embedded SEO/affiliate metadata: inline source-name footnotes (e.g. “InstaTunnel”, “tunnelto.me +1”), stock-photo attribution captions, and the parenthetical subtitle in the original headline.
- Corrected the central claim about ngrok’s free tier: free accounts have used a persistent per-account dev domain (not a randomly rotating one) since 2023, and free endpoints have no session timeout per ngrok’s current documentation. The real free-tier limitation is the inability to choose a custom name/domain, not URL rotation. (Source: ngrok docs, “Free Plan Limits” and “Static dev domains” blog post.)
- Verified and updated GitHub star/fork counts as of today: frp ~107k stars/15k forks (draft’s “106,000+” was accurate but is now updated); rathole 14.0k stars/800 forks (draft’s “~14,000” holds up); bore 11,100 stars/493 forks (draft said “nearly 10,000,” now higher).
- Verified rathole’s QPS/latency benchmark numbers (3,000 vs. 4,000 QPS threshold) directly against rathole’s own
docs/benchmark.md, and added the missing methodology context: single-machine loopback test from December 2021, run by rathole’s own maintainers against frp v0.38.0 (now ~30 releases out of date), not an independent or current comparison. - Corrected rathole’s minimum binary size claim: the project’s own build guide documents a 574 KiB minimal build (vs. the ~500 KiB figure in the draft, which was directionally right but not the documented number), compared against a ~10 MiB frpc build.
- Corrected/nuanced the Noise Protocol claim: Noise does secure WireGuard’s handshake and WhatsApp’s client-to-server transport, but WhatsApp’s end-to-end message encryption specifically uses the separate Signal Protocol — the original phrasing implied Noise secures WhatsApp messages directly.
- Corrected rathole’s maintenance status: confirmed v0.5.0 (Oct 1, 2023) is the last tagged release, but added that the project has an active dev branch and ongoing issue/PR activity into 2025–2026, rather than reading as fully abandoned.
- Added a fairness correction on frp: it is actively developed (monthly-cadence releases through 2026, recent security patching), not the stagnant/bloated project implied by the “Rust dethrones frp” framing.
- Added a previously missing security fact for bore: its optional
--secretflag authenticates the tunnel handshake via HMAC but does not encrypt the proxied traffic itself by default — a meaningful caveat for anything beyond already-TLS’d upstream services. - Corrected a significant conflation: the draft treated “tunnelto” as one project with an open-source core (tunnelto.dev) and a hosted layer. These are two separate, unrelated projects with similar names. tunnelto.dev (agrinman, MIT, Rust) has been inactive since 2021. tunnelto.me is a separate, actively maintained commercial service; its implementation language isn’t publicly documented, so the “written in Rust” claim was removed for that product specifically.
- Corrected tunnelto.me’s free-tier custom domain claim: confirmed via tunnelto.me’s own pricing page that free-tier tunnels are capped at 1-hour sessions and must be recreated; only the $2/month Hobbyist tier and above get persistent tunnels. The original draft implied the free custom domain had no such limitation.
- Extended the comparison table with GitHub stars, encryption-by-default status, and last-release dates for each tool, all sourced from primary repos/docs as of today.
- Extended with a “fair word for frp” section and clarified bottom-line recommendations reflecting the corrected facts above.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Comments
Post a Comment