Surviving the SaaS Pivot: Why AGPL Open-Source Tunnels Win

Developers exposing local environments to the internet face a persistent threat: commercial tunneling providers deprecating free tiers, restricting bandwidth, and locking features behind enterprise paywalls. Network address translation (NAT) and carrier-grade NAT (CGNAT), now standard across most consumer and mobile ISPs, mean most developers no longer possess a publicly routable IPv4 address, making reverse-proxy tunnels a mandatory layer of the modern development stack. Building a webhook receiver, an AI agent interface, or a local multiplayer game server almost always means relying on a tunneling daemon to punch through the local firewall and expose a public endpoint.

For years the industry defaulted to proprietary SaaS platforms to solve this routing problem. As the ecosystem matures and profit mandates force those platforms to tighten terms, the open-source community has been migrating toward “vendor pivot insurance” — tools licensed strictly under the GNU Affero General Public License (AGPL) that let developers self-host the exact same infrastructure if the commercial provider changes its terms or disappears.

Why the Free Tiers Are Shrinking

The shift away from generous freemium tunneling is driven by real, measurable changes in the two most popular defaults.

ngrok, long the default developer tool for local exposure, now runs a genuinely capped free plan: a one-time $5 usage credit, up to 3 online endpoints, 1GB of data transfer, and 20,000 HTTP/S requests per month. Once that credit or those limits are hit, endpoints stop accepting new traffic until the next monthly reset. Beyond free, ngrok’s Hobbyist tier is $10/month ($8/month billed annually) for 3 endpoints and 5GB of bandwidth, and Pay-as-you-go starts at $20/month plus $0.10/GB and $1 per 100,000 requests in overages, with unlimited endpoints and a bring-your-own-domain option.

Cloudflare Tunnel is frequently held up as the zero-cost alternative, and for HTTPS ingress it largely is — but it inherits real restrictions from Cloudflare’s CDN terms that catch people off guard. Two matter here, and both are more specific than they’re often described:

• The video/large-file restriction. This is commonly (and now outdatedly) cited as “Section 2.8” of Cloudflare’s terms — but that section was retired back in May 2023, when Cloudflare moved the content-based restriction out of its general Self-Serve Subscription Agreement and into a CDN-specific section of its Service-Specific Terms. The restriction only applies to Cloudflare’s CDN — meaning it applies to a Cloudflare Tunnel’s public hostname routes (which proxy through Cloudflare’s edge), but explicitly not to Tunnel’s private-network routes accessed over WARP. It’s also narrower than a blanket streaming ban: video and other large files are fine on the CDN today as long as they’re served from a Cloudflare-hosted service like Stream, Images, or R2 — the restriction is on serving large files hosted outside Cloudflare through the CDN. A self-hosted Plex or Jellyfin server exposed via a public Tunnel hostname still runs into this; the same server reached only over private WARP-routed access does not.
• The 100MB request-body cap. Free and Pro plans cap the maximum HTTP request (POST) body size proxied through the CDN at 100MB — above that, Cloudflare returns a 413 “Request Entity Too Large” rather than silently dropping data. Business raises the cap to 200MB and Enterprise to 500MB. This is real and worth planning around for large file uploads or sync tools, but it’s a body-size ceiling on CDN-proxied traffic, not a chunk-dropping quirk specific to Tunnel.

The Mechanics of Vendor Pivot Insurance

Vendor lock-in in the tunneling space happens when a developer builds CI, webhook testing, or automation pipelines around a proprietary API or a closed-source relay. If the company hosting that relay changes its pricing or shuts down, the developer has to rewrite their network architecture from scratch. Vendor pivot insurance is the architectural guarantee that a developer can stand up identical infrastructure on their own hardware, using the exact same software.

This insurance is codified by the GNU Affero General Public License v3.0 (AGPLv3). Unlike permissive licenses like MIT or Apache 2.0, the AGPL closes the “SaaS loophole” in the regular GPL: any entity that modifies the software and runs it as a network service must make that modified source available to users interacting with it over the network — not just to people who receive a compiled binary. For a reverse-proxy relay, that means the core server can’t quietly be forked and taken proprietary by a commercial operator. If a managed AGPL-licensed tunneling service degrades or changes its pricing, a developer can provision a low-cost VPS, deploy the same relay code, and keep running with no changes to their local client configuration.

Evaluating the Modern Tunneling Landscape

Tool	Server License	Primary Language	Protocols Supported	Ideal Use Case	Cost Profile
ngrok	Proprietary	Go	HTTP, TCP, TLS	Legacy webhook testing	Free (3 endpoints/1GB/20K req) → $10–20+/mo
rustunnel	AGPL v3.0	Rust	HTTP, TCP, UDP, P2P	AGPL reverse-proxy self-hosting	$0 self-hosted / $3/mo+ PAYG
frp	Apache 2.0	Go	HTTP, HTTPS, TCP, UDP	Heavy self-hosted homelabs	VPS cost (~$4/mo)
Cloudflare Tunnel	Proprietary cloud	Go (cloudflared)	HTTP, HTTPS via CDN; raw TCP/UDP via WARP	Stateless webhooks, zero-cost HTTPS	Free (domain required)
rathole	MIT	Rust	TCP, UDP (no HTTP routing)	Low-spec VPS port-forwarding	VPS cost (~$4/mo)
bore	MIT	Rust	TCP only	Minimalist port forwarding	Free public relay or ~$4/mo VPS
Tailscale Funnel	Proprietary cloud	Go	HTTPS/TCP ingress (ports 443, 8443, 10000 only)	Sharing one service outside your tailnet	Free (Personal plan)

A couple of corrections worth flagging against how this table is often drawn up elsewhere: rathole doesn’t do HTTP-aware routing — it’s a generic TCP/UDP port-forwarder with no subdomain- or path-based HTTP layer, unlike frp or ngrok. And Tailscale Funnel isn’t a general-purpose L3 mesh — the underlying Tailscale network is the private WireGuard mesh; Funnel is the narrow, explicit feature that punches a single service out of that private mesh onto the public internet over HTTPS or raw TCP on a small set of fixed ports.

The Rust-Powered Ecosystem

Performance and memory safety matter for edge relays handling millions of multiplexed WebSocket and TCP connections, and the open-source community has increasingly moved from Go and Node.js to Rust for this layer. rathole trades HTTP awareness for raw throughput and a minimal footprint — its binary can run as small as roughly 500KB in a stripped build, with a larger full-featured release binary. It authenticates and encrypts with the Noise Protocol Framework, defaulting to the server-authenticated Noise_NK pattern (not the unauthenticated Noise_NN pattern sometimes shown in tutorials), which requires generating a keypair with rathole --genkey and configuring the client with the server’s public key. bore goes even further toward minimalism: a single Rust binary, TCP-only, with a free community relay at bore.pub. Its --secret flag authenticates the tunnel handshake, but doesn’t encrypt the tunneled traffic itself by default — TLS still needs to be handled by whatever’s behind the tunnel, or added at another layer.

Within this Rust-heavy field, rustunnel is a newer, more full-featured entrant that directly targets ngrok’s use case. It’s AGPL-licensed, exposes local HTTP, TCP, and UDP services (plus native peer-to-peer tunnels with shared-secret auth) through a managed edge or a self-hosted relay, and currently sits around 600–650 stars on GitHub with steady commit activity through 2026.

• Architecture & encryption: client-server traffic runs over TLS-terminated, encrypted WebSocket connections, with automatic Let’s Encrypt provisioning for generated public endpoints.
• High availability: multiple backends can sit behind one custom subdomain or TCP port, load-balanced across healthy members with configurable TCP/HTTP health probes, so a dead backend gets pulled out of rotation automatically.
• Observability: a full-screen terminal dashboard shows live session status, per-region latency, and request-per-second traffic counters, alongside machine-readable JSON output. The project’s own materials also list Prometheus metrics and audit logging as features — worth reading as connection- and tunnel-level telemetry (who connected, when, how much data moved) rather than inspection of the actual tunneled payload content, which is consistent with rustunnel’s stated privacy stance of not reading application-layer traffic.
• AI agent integration: it ships a native MCP server with one-click setup guides for Cursor, Claude Code, Claude Desktop, and Windsurf, distributed as a native binary rather than an npm package.
• Pricing: free self-hosting (unlimited tunnels, AGPL source), a free hosted tier (up to 3 tunnels, no custom subdomains), and a pay-as-you-go hosted tier at a $3/month minimum plus $0.10/GB beyond that — no separate per-hour uptime meter, so idle tunnels don’t accrue charges beyond the flat minimum. The managed edge currently runs three regions: Helsinki, Hillsboro (Oregon), and Singapore.

If a managed cloud tier like this changes terms or shuts down, the pitch is the same as the AGPL argument above: the exact same server code is available to self-host for free.

Identifying and Avoiding Abandonware

Avoiding vendor lock-in only helps if the open-source alternative is actually maintained. Star counts alone can be misleading, since they reflect historical popularity more than current activity.

frp (Fast Reverse Proxy) is the clearest example of durable, actively maintained self-hosting infrastructure in this space: it’s Apache-2.0 licensed, written in Go, and has passed 106,000 GitHub stars with ongoing commit activity, offering TCP, UDP, HTTP, and HTTPS forwarding with vhost-based subdomain routing and no third-party intermediary in the traffic path.

localtunnel, by contrast, is a cautionary tale worth flagging even though it still shows up in tutorials constantly: the localtunnel/localtunnel repository has about 22,000 GitHub stars, but its commit and star activity has flatlined — essentially no new commits or stars week over week through mid-2026. A project this quiet carries real risk: unpatched dependencies, TLS/protocol drift, and an unmaintained public relay server that could disappear without notice. It’s a reasonable one-off for a five-minute demo; it’s a poor foundation for anything you plan to keep relying on.

Deploying an Open-Source Relay

Moving from a proprietary SaaS tunnel to a self-hosted AGPL relay is a short list of steps, and it’s the same shape whether you land on rustunnel, frp, or rathole:

1. ホストを準備する。 パブリックIPを持つ小さなLinux VPSで十分です — 予算は月約$4〜6程度。DigitalOceanの最安のBasic Dropletは現在月額約$4から始まります。
2. DNSを設定する。 HTTPルーティングツール（rustunnel、frp）の場合、ワイルドカードAレコード（例：*.tunnel.yourdomain.com）を作成し、VPSのパブリックIPを指すようにします。ratholeやboreのようなTCP専用ツールはこれを必要としません — 直接ポートにバインドします。
3. リレーを展開する。 これらのプロジェクトの多くはDockerイメージやsystemdサービスファイルを提供しているため、docker-compose upやパッケージマネージャー経由のインストールですぐにサーバーを稼働させられます。
4. ローカルマシンから接続する。 クライアントはパブリックエンドポイントに向けて永続的な暗号化された接続を確立し、localhost:8080などをブリッジします。

自己ホスティングは任意の帯域制限を排除し、ISP側のCGNATを完全に回避し、— そしてリレーコードはどちらの場合も同じため — 商用プロバイダーの料金変更やサービス停止による書き換えの必要がありません。AGPLライセンスのインフラを使えば、最終的にルーティングルールは開発者が制御します。