The Minimalist Edge: Rust and Go Micro-Proxies
IT
Quick answer
Lightweight ngrok Alternatives: Rust & Go Micro-Proxies: 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.
In the rapidly evolving landscape of edge computing, home-labbing, and Internet of Things (IoT) development, exposing local services to the public internet securely has always been a central challenge. For years, developers have relied on commercial, centralized services to punch holes through Network Address Translation (NAT) firewalls. However, as the ecosystem matures in 2026, a niche but incredibly passionate trend is emerging: developers are replacing heavy, commercial proxy services with ultra-minimalist tools written in Rust and Go.
These micro-proxies are not trying to be enterprise platforms. They are unapologetically small, blindingly fast, and completely open-source. For IoT hobbyists and edge network architects running applications on low-memory devices, finding a lightweight ngrok alternative has become less of a luxury and more of a necessity.
This article explores the rise of these specialized networking tools, diving deep into the architectures and practical applications of tools like Bore, Rathole, and Chisel. We will examine why developers are making the switch, how to set up a robust Raspberry Pi localhost tunnel, and finally settle the debate of bore vs rathole for your next embedded project.
The Bloat of Modern Tunneling
Before we dive into the minimalist alternatives, it is important to understand what drove this shift. Exposing a local development server, a home assistant dashboard, or a remote IoT sensor requires bypassing NAT and strict firewalls.
Historically, this was achieved via complex SSH reverse port forwarding (ssh -R). While effective, it was prone to connection drops and required a dedicated VPS with specific sshd_config modifications. Then came the era of SaaS tunnel providers. These services offered a magical developer experience: a single command that instantly provided a public, HTTPS-secured URL pointing to a local machine.
However, as these platforms grew, they transformed from simple developer tools into massive edge-delivery networks. This evolution brought enterprise features—authentication layers, traffic inspection, load balancing, and WAFs—but it also introduced friction:
- Resource Overhead: The client daemons for full-scale edge platforms can be resource-intensive. While negligible on an M3 MacBook, this overhead is noticeable on a Raspberry Pi Zero or a constrained embedded Linux device at the edge.
- Bandwidth and Connection Limits: Free tiers on commercial platforms have become increasingly restrictive, capping bandwidth, the number of active tunnels, or rotating domain names randomly, which breaks automated workflows.
- Closed Ecosystems: Many modern tunneling clients are closed-source. For security-conscious home-labbers routing personal infrastructure (like security cameras or private NAS data), running closed-source network daemons is a dealbreaker.
The response to these constraints has been a renaissance of open-source micro-proxies. Built on modern, systems-level languages like Rust and Go, these tools offer single-binary deployments, memory-safe execution, and virtually zero runtime dependencies.
Chisel: The Swiss Army Knife of Go Proxies
When discussing modern networking tools, Go (Golang) is usually the first language that comes to mind, owing to its exceptional concurrency model and robust standard library. In the realm of minimalist tunneling, the chisel reverse proxy reigns supreme as the ultimate Swiss Army knife.
What is Chisel?
Chisel is a fast TCP/UDP tunnel transported over HTTP and secured via SSH. Created by Jaime Pillora and released under the MIT license, it is written entirely in Go and bundles both client and server into a single executable. As of mid-2026, the project sits at roughly 16,500 GitHub stars and 1,600 forks, with the latest release (v1.11.8) built against Go 1.27.0 — evidence this is still an actively maintained project rather than a stagnant weekend hack.
How Chisel Actually Works
The “over HTTP” framing is a little more specific than it sounds: Chisel opens a single WebSocket connection over an HTTP(S) request and then multiplexes an SSH-authenticated session — complete with its own encrypted channels — across that one connection. Because the initial handshake looks like an ordinary HTTP request with an Upgrade header, Chisel can pass through most corporate proxies and CDNs. It’s confirmed to work behind Cloudflare (with WebSockets enabled) and Heroku, for example. The catch is that any intermediary which strips the Upgrade header — some strict corporate proxies do this — will block Chisel entirely, so it isn’t a universal DPI-bypass tool in every environment.
Encryption is mandatory, not optional: on startup, the server generates an in-memory ECDSA keypair and prints its fingerprint. Clients can pin that fingerprint with --fingerprint to detect man-in-the-middle attempts, which is the recommended way to run it outside a trusted network.
Key features, verified against the current README:
- Single Executable: No need to install separate server and client packages.
- Transport over HTTP (via WebSocket upgrade): Works through most firewalls and CDNs that support WebSockets; blocked by ones that strip the
Upgradeheader. - Built-in SOCKS5: The server can act as a fully functional SOCKS5 proxy, letting a client route entire browser sessions or system traffic through the tunnel.
- Reverse Port Forwarding: The server can expose a port that maps back to the client’s local service, enabled with
--reverseon the server side. - Automatic Reconnection: The client auto-reconnects using exponential backoff.
Security in 2026: Even Minimalist Tools Need Patching
Being open-source doesn’t make a tool immune to bugs, and Chisel had a notable year on that front. Two high-severity advisories were published against it in 2026: an authfile ACL bypass reachable via a post-handshake SSH channel “ExtraData” injection (GHSA-24fp-5v3p-rvpw, May 2026), and a related bypass where a restricted, authenticated client could reach arbitrary server-internal TCP services through the SOCKS5 channel because SOCKS5 access wasn’t checked against the authfile at all (GHSA-397r-r4gr-x5pg, June 2026).
The fix, enforced from v1.11.7 onward, is a breaking change worth knowing about before you upgrade: SOCKS5 access is now gated by a socks token in the users.json authfile. If you’re running --socks5 together with --authfile, any user who should keep SOCKS access needs an explicit entry matching socks (a wildcard "" entry still works). The subsequent v1.11.8 release (July 2026) also bumped the underlying golang.org/x/crypto/ssh dependency to v0.55.0, which the project’s release notes tie to fixing an SSH-library vulnerability tracked as GO-2026-6303. If you’re running an older Chisel binary in production, this is a good prompt to update.
Use Case: The Penetration Tester and the Edge Developer
The chisel reverse proxy is highly favored in the cybersecurity community — for the same reason it’s useful to home-labbers: it tunnels quietly over ordinary web ports. That popularity cuts both ways. Chisel shows up on “living-off-the-tunnels” catalogs of binaries attackers use for network pivoting, and its Windows binaries are periodically flagged by Microsoft Defender as a generic trojan — not because the code is malicious, but because the same one-binary simplicity that home-labbers love makes it an attractive off-the-shelf pivoting tool for intruders. If you’re a defender, it’s worth knowing Chisel’s traffic signature (WebSocket handshake to an unfamiliar host on 80⁄443, followed by long-lived connections) as much as it’s worth knowing it as a builder.
For the edge developer, Chisel is well suited to remote management. If you deploy a fleet of smart vending machines, you can run a Chisel client on each machine. They phone home to your central server over HTTP, providing you with on-demand, encrypted reverse-SSH access to each unit without exposing any ports on the vending machines themselves.
Starting a Chisel server on your VPS:
chisel server -p 8080 --reverse
Connecting from your local edge device:
chisel client vps-ip:8080 R:80:localhost:3000
This maps port 80 on your VPS to port 3000 on your local edge device (the R: prefix and remote-port:local-host:local-port ordering are Chisel’s actual reverse-remote syntax).
The Rust Heavyweights: Bore vs. Rathole
While Go handles concurrency beautifully, Rust offers unparalleled control over memory and CPU usage. For the absolute lowest resource footprint, developers are turning to Rust-based tunnels. In the Rust ecosystem, two tools frequently dominate the conversation: Bore and Rathole.
Choosing between the two often comes down to a debate of simplicity versus power. Let’s break down the bore vs rathole comparison.
Bore: The Epitome of Simplicity
Bore, created by Eric Zhang and released under the MIT license, is designed to do one thing and do it perfectly: expose a local TCP port to the internet. It’s currently at version 0.6.0 and, true to its philosophy, the entire tool is around 400 lines of async Rust built on Tokio.
The Philosophy: Bore operates on a zero-friction philosophy. It doesn’t ask you to write configuration files, set up complex routing rules, or manage certificates. It is meant to be an instantaneous drop-in replacement for the basic functionality of commercial tunneling services.
Key Features of Bore: * Zero-Config CLI: You can start tunneling immediately with intuitive command-line arguments. * Raw TCP: It handles raw TCP traffic, meaning it is protocol-agnostic. Whether you are tunneling HTTP, SSH, MySQL, or Minecraft server traffic, Bore handles it transparently. * Public Community Server: By default, if you just want to test a webhook, you can point at the maintainer’s community server at bore.pub without needing your own VPS. (Older write-ups sometimes reference bore.digital — that’s not the current community server; bore.pub is the one in the official docs.)
A security caveat worth flagging: Bore’s optional --secret flag only authenticates the initial handshake via HMAC challenge-response — it does not encrypt the tunneled traffic itself. Unless the service you’re exposing already speaks TLS (HTTPS, for instance), the bytes flowing through a self-hosted Bore server are plaintext on the wire. For anything sensitive, put Bore behind a TLS-terminating reverse proxy, or run it over an already-encrypted transport like a WireGuard link. This is a genuine trade-off for its simplicity, not an oversight — but it’s a different security posture than Chisel or Rathole, both of which encrypt the tunnel by default.
Like Chisel, Bore’s minimalism has a dual-use downside: it’s cataloged as a tool abused for firewall-bypassing pivots in offensive-security tradecraft, precisely because a single small, legitimate-looking binary is easy to drop on a compromised host.
When to use Bore: If you are developing a web application locally and need a webhook URL for Stripe or GitHub, Bore is your best friend. It requires zero mental overhead.
Starting a self-hosted Bore server:
bore server
Exposing a local port using your self-hosted server:
bore local 8000 --to myserver.com
Rathole: The Secure, High-Performance Workhorse
If Bore is a scooter, Rathole is a highly tuned sports car. Rathole is a lightweight and high-performance reverse proxy for NAT traversal, explicitly positioned as an alternative to tools like frp and ngrok. It was originally authored by Yujia Qiao (rapiz1); the project has since moved to a community-run rathole-org GitHub organization, where it remains actively maintained — around 14,000 stars and commits as recently as this month — and is licensed under Apache-2.0.
The Philosophy: Rathole is built for permanence and security. It is designed to be set up once via a configuration file and left running indefinitely on edge devices, routers, and NAS systems.
Key Features of Rathole: * Noise Protocol Encryption: Rathole integrates the Noise Protocol framework as an alternative to TLS. Its default handshake pattern is Noise_NK_25519_ChaChaPoly_BLAKE2s, which authenticates the server to the client using a static keypair — conceptually similar to SSH host-key pinning — without the overhead of issuing and managing X.509 certificates. (An earlier draft of this piece cited the NN pattern, which provides encryption but no server authentication and is vulnerable to MITM; NK is what Rathole actually ships by default.) * Token-Based Authentication: Services are strictly authenticated. The server dictates what services are allowed, and clients must authenticate with per-service tokens. * Higher Throughput than frp: The project’s own benchmarks show meaningfully higher throughput and better stability under load than frp, a popular Go-based alternative. * Small Footprint: A minimal Rathole build with unneeded features stripped out can get down to roughly 500 KB; a full-featured release binary (with TLS, Noise, and WebSocket transport compiled in) lands in the low single-digit megabytes. Either way, it’s a fraction of the footprint of a JVM-based alternative, and comfortably fits embedded routers like OpenWrt devices. * WebSocket Transport: A more recent addition lets Rathole tunnel over WebSockets as well as raw TCP/TLS/Noise, which helps it traverse the same restrictive proxies that give Chisel its edge.
The Verdict: Bore vs Rathole The bore vs rathole decision is straightforward. If you need a temporary, frictionless, encryption-optional tunnel for local development or quick testing, use Bore. Its CLI is intuitive, and it gets out of your way.
If you are setting up permanent infrastructure — such as securely exposing a self-hosted Nextcloud instance, managing remote IoT nodes, or replacing a full-time VPN — choose Rathole. The configuration file requires a few minutes of initial setup (including generating a Noise keypair), but the performance, stability, and cryptographic authentication it provides by default make it the sturdier choice for production environments.
Deploying a Raspberry Pi Localhost Tunnel
To contextualize the power of these micro-proxies, let’s look at a highly practical scenario: setting up a Raspberry Pi localhost tunnel.
Millions of developers use Raspberry Pis as home servers. They run home automation (Home Assistant), network-wide ad blockers (Pi-hole), and private media servers. However, accessing these services when you are away from your home Wi-Fi is notoriously difficult because home ISPs change your IP address (Dynamic IP) and place you behind strict NAT routers.
Rather than opening ports on your home router (which exposes your entire network to automated internet scanners), you can use a micro-proxy to create a secure, outbound-only connection from your Pi to a cheap $5/month cloud VPS.
The Setup: Using Rathole for a Permanent Pi Tunnel
For a permanent home lab setup, Rathole is the ideal candidate. Here is how you architect this solution, using Rathole’s actual Noise-transport configuration syntax (which requires a generated keypair, unlike the placeholder config in earlier drafts of this piece).
1. Generate a keypair on the VPS
./rathole --genkey
# Private Key: cQ/vwIqNPJZmuM/OikglzBo/+jlYGrOt9i0k5h5vn1Q=
# Public Key: GQYTKSbWLBUSZiGfdWPSgek9yoOuaiwGD/GIX8Z1kkE=
Keep the private key on the VPS; you’ll paste the public key into the Pi’s config in step 3.
2. The Cloud VPS (The Public Gateway)
You rent a tiny, low-cost virtual private server (e.g., DigitalOcean, Linode, or Hetzner) with a static public IP, and install the Rathole binary there.
Create server.toml:
[server]
bind_addr = "0.0.0.0:2333" # Port where Rathole listens for the Pi
[server.transport]
type = "noise"
[server.transport.noise]
local_private_key = "cQ/vwIqNPJZmuM/OikglzBo/+jlYGrOt9i0k5h5vn1Q=" # from --genkey above
[server.services.home_assistant]
token = "super_secure_random_string"
bind_addr = "0.0.0.0:8123" # The public port you will access via web browser
Run the server: ./rathole --server server.toml
3. The Raspberry Pi (The Edge Device)
Back at your home lab, you download the Rathole binary onto your Raspberry Pi. The Pi will reach out to the VPS and establish an encrypted, server-authenticated connection.
Create client.toml:
[client]
remote_addr = "YOUR_VPS_IP:2333"
[client.transport]
type = "noise"
[client.transport.noise]
remote_public_key = "GQYTKSbWLBUSZiGfdWPSgek9yoOuaiwGD/GIX8Z1kkE=" # the Public Key printed in step 1
[client.services.home_assistant]
token = "super_secure_random_string" # Must match the server token
local_addr = "127.0.0.1:8123" # The port Home Assistant runs on locally
Run the client: ./rathole --client client.toml
The Result: Your Raspberry Pi has successfully created a highly secure, encrypted, server-authenticated tunnel from your living room to the cloud. You can now access your Home Assistant dashboard from anywhere in the world by navigating to http://YOUR_VPS_IP:8123.
Crucially, because this is a lightweight ngrok alternative, the Rathole daemon on your Raspberry Pi will consume only a few megabytes of RAM and virtually 0% CPU while idle. Your Pi’s resources are preserved for running actual applications, not network overhead. Furthermore, because this connection originates from the Pi out to the VPS, your home router’s firewall never has an inbound rule to worry about, keeping your home network safe from unsolicited inbound attacks.
The Broader Implications for IoT and Edge Networking
The shift toward these micro-proxies represents a broader trend in software engineering: a return to Unix philosophy. Instead of monolithic tools that try to manage everything from tunneling to identity verification, developers are preferring modular, high-performance utilities that do exactly one thing.
In the IoT and industrial edge sectors, this is particularly impactful. Imagine a network of thousands of solar-powered environmental sensors deployed across a forest. These devices run on tiny microcontrollers or stripped-down Linux boards. They have intermittent 4G/LTE connectivity, strict power constraints, and zero incoming network routing capabilities.
Deploying a commercial tunneling agent on these devices is often impractical given binary size limitations and memory overhead. A statically compiled Rust binary like Rathole — well under a few megabytes, and closer to 500 KB in a minimal build — can be baked directly into the device’s firmware. When an engineer needs to pull diagnostic data, the device can temporarily spin up a Noise-encrypted tunnel, transmit the data, and shut the tunnel down to conserve battery.
Security Posture at the Edge
One of the most critical aspects of using these open-source tools is the control it hands back to the user regarding security. With closed-source proxies, you must implicitly trust that the provider is not logging your plaintext traffic (especially if the SSL termination happens on their servers).
By self-hosting a lightweight ngrok alternative using a tool like Chisel or Rathole, you control both ends of the pipe. But “open-source” and “self-hosted” are not synonyms for “automatically secure” — Chisel’s two 2026 authfile-bypass advisories are a useful reminder that these tools carry the same patching responsibilities as any other network-facing service. The upside of open-source, minimalist tooling isn’t that it’s invulnerable; it’s that vulnerabilities get disclosed, fixed, and shipped in a small, auditable codebase rather than sitting behind a vendor’s opaque release notes. In a world where data privacy is paramount, eliminating the man-in-the-middle — even a benevolent SaaS provider — is a real security upgrade, provided you also keep the binary itself up to date.
Conclusion: Crafting Your Minimalist Toolbelt
The era of defaulting to heavy, enterprise tunneling platforms for simple port forwarding is ending. The developer community’s push toward efficient, secure, and fully open-source infrastructure has resulted in a golden age of networking tools.
Whether you are a web developer looking for the instantaneous simplicity of Bore, a home-lab enthusiast configuring a rock-solid Raspberry Pi localhost tunnel with Rathole, or a security researcher (or defender) tracking a chisel reverse proxy across a network, there is a tool specifically tailored to your needs.
Rust and Go have proven to be the perfect languages for this networking revolution. They have empowered developers to build software that is not only exceptionally fast but also remarkably light. As edge computing continues to push processing power out of centralized data centers and into our homes, our vehicles, and our embedded devices, these micro-proxies will serve as the crucial, invisible threads tying the decentralized web together.
Ditch the bloat. Reclaim your RAM. Keep the binaries patched. Embrace the minimalist edge.
Editorial Changelog
This draft was fact-checked against each project’s official GitHub repository, README, and (for Chisel) its security advisories, then extended with newly verified 2026 developments. Changes from the original draft:
Corrections - Bore’s community server is bore.pub, not bore.digital — corrected everywhere it’s referenced. - Rathole’s default Noise pattern is Noise_NK_25519_ChaChaPoly_BLAKE2s (server-authenticated), not Noise_NN_25519_ChaChaPoly_BLAKE2s (unauthenticated, MITM-vulnerable) as the original draft’s config example used. - Rathole’s Raspberry Pi config example was incomplete: Noise transport requires a generated keypair (local_private_key on the server, remote_public_key on the client, produced via rathole --genkey). The original client.toml/server.toml examples omitted this entirely and wouldn’t have worked as written. Replaced with a working, correctly keyed example. - Chisel’s transport mechanism was described as wrapping SSH traffic “inside standard HTTP(S) requests”; corrected to specify it’s a WebSocket upgrade over HTTP(S), and added the caveat that proxies stripping the Upgrade header block Chisel entirely (it isn’t a universal DPI-bypass tool). - Softened the IoT-firmware section’s flat “3MB statically compiled Rust binary” claim for Rathole to reflect the actual range (~500 KB minimal build up to low single-digit MB fully featured), per the project’s own documentation.
Additions (new, sourced content) - Chisel: current project stats (author Jaime Pillora, MIT license, ~16.5k stars, latest release v1.11.8 on Go 1.27.0). - Chisel: two 2026 high-severity security advisories (GHSA-24fp-5v3p-rvpw, May 2026; GHSA-397r-r4gr-x5pg, June 2026) covering authfile/SOCKS5 ACL bypasses, the breaking authfile change enforced from v1.11.7 onward (SOCKS5 access now requires a socks token entry), and the v1.11.8 x/crypto/ssh bump addressing GO-2026-6303. - Bore: explicit security caveat that the --secret flag authenticates the handshake only and does not encrypt tunneled traffic by default — a meaningful difference from Chisel and Rathole that the original draft didn’t mention. - Both Bore and Chisel: noted as tools that appear on “living-off-the-land” tunnel catalogs and get flagged by endpoint security software, since their legitimate simplicity is equally attractive to attackers for pivoting — relevant context for a security-aware readership. - Rathole: noted the project’s move from rapiz1/rathole to the community-maintained rathole-org organization, current star count (~14k), Apache-2.0 license, and the newer WebSocket transport option. - New framing in “Security Posture at the Edge” clarifying that open-source/self-hosted doesn’t mean automatically secure — it means vulnerabilities are disclosed and patchable, which only helps if you actually update.
Verified as accurate (no change needed) - Chisel’s CLI examples (chisel server -p 8080 --reverse / chisel client vps-ip:8080 R:80:localhost:3000) and their described effect. - Bore’s CLI examples and its ~400-line, async-Rust, Tokio-based implementation. - Rathole’s core value proposition (higher throughput than frp, low resource use, token-based per-service auth).
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Comments
Post a Comment