Überleben beim SaaS-Pivot: Warum AGPL-Open-Source-Tunnel gewinnen

Entwickler, die lokale Umgebungen ins Internet stellen, sehen sich einer anhaltenden Bedrohung gegenüber: kommerzielle Tunneling-Anbieter stellen kostenlose Tarife ein, beschränken Bandbreite und sperren Funktionen hinter Enterprise-Paywalls. Network Address Translation (NAT) und Carrier-Grade NAT (CGNAT), die heute bei den meisten Verbraucher- und Mobil-ISPs Standard sind, bedeuten, dass die meisten Entwickler keine öffentlich routbare IPv4-Adresse mehr besitzen. Reverse-Proxy-Tunnel sind daher eine unverzichtbare Schicht im modernen Entwicklungstack. Das Erstellen eines Webhook-Empfängers, einer Schnittstelle für KI-Agenten oder eines lokalen Multiplayer-Spiels erfordert fast immer einen Tunneling-Daemon, um die lokale Firewall zu durchbrechen und einen öffentlichen Endpunkt bereitzustellen.

Seit Jahren setzen die Branchenstandards auf proprietäre SaaS-Plattformen, um dieses Routing-Problem zu lösen. Mit der Reifung des Ökosystems und den Profitvorgaben, die diese Plattformen zu strengeren Nutzungsbedingungen zwingen, wandert die Open-Source-Community in Richtung “Vendor Pivot Insurance” — Tools, die strikt unter der GNU Affero General Public License (AGPL) lizenziert sind und es Entwicklern ermöglichen, die gleiche Infrastruktur selbst zu hosten, falls der kommerzielle Anbieter seine Bedingungen ändert oder verschwindet.

Warum die kostenlosen Tarife schrumpfen

Der Wandel weg von großzügigen Freemium-Tunneln wird durch echte, messbare Veränderungen bei den beiden beliebtesten Defaults angetrieben.

ngrok, lange das Standard-Entwickler-Tool für lokale Exposition, bietet jetzt einen wirklich begrenzten kostenlosen Plan: 5 US-Dollar Guthaben, bis zu 3 Online-Endpunkte, 1 GB Datenübertragung und 20.000 HTTP/S-Anfragen pro Monat. Nach Erreichen dieser Grenzen oder des Guthabens werden keine neuen Traffic-Anfragen mehr akzeptiert, bis der nächste Monat beginnt. Über den kostenlosen Tarif hinaus kostet das Hobbyist-Paket 10 USD/Monat (8 USD/Monat bei jährlicher Abrechnung) für 3 Endpunkte und 5 GB Bandbreite. Das Pay-as-you-go-Modell startet bei 20 USD/Monat plus 0,10 USD/GB und 1 USD pro 100.000 Requests bei Überziehung, mit unbegrenzten Endpunkten und Domain-Option.

Cloudflare Tunnel wird häufig als kostenlose Alternative angepriesen, was für HTTPS-Ingress größtenteils zutrifft — aber es enthält echte Einschränkungen, die aus den CDN-Nutzungsbedingungen von Cloudflare resultieren und oft übersehen werden. Hier zwei wichtige Punkte, die spezifischer sind als oft beschrieben:

• Video/große Dateien Beschränkung. Früher (und inzwischen veraltet) wurde dies als “Abschnitt 2.8” der Cloudflare-Bedingungen bezeichnet — dieser Abschnitt wurde im Mai 2023 entfernt, als Cloudflare die content-basierte Einschränkung aus dem allgemeinen Self-Serve-Abonnementvertrag in einen CDN-spezifischen Abschnitt der Service-Specific Terms verschob. Diese Beschränkung gilt nur für Cloudflare’s CDN — also für die Routen des Cloudflare Tunnel öffentlicher Hostname (die durch Cloudflares Edge proxyen), aber nicht für private Netzwerk-Routen, die über WARP zugänglich sind. Es ist auch keine generelle Streaming-Sperre: Videos und große Dateien sind heute auf dem CDN erlaubt, solange sie von einem Cloudflare-gehosteten Dienst wie Stream, Images oder R2 bereitgestellt werden. Die Einschränkung betrifft das Hosting außerhalb von Cloudflare. Ein selbst gehosteter Plex- oder Jellyfin-Server, der über einen öffentlichen Tunnel-Hostnamen zugänglich ist, fällt darunter; der gleiche Server, nur über private WARP-Zugriffe, nicht.
• Request-Body-Limit von 100MB. Kostenlose und Pro-Pläne beschränken die maximale HTTP-POST-Request-Größe auf 100MB — darüber hinaus gibt Cloudflare eine 413 “Request Entity Too Large”-Antwort zurück, anstatt die Daten stillschweigend zu verwerfen. Business-Pläne erhöhen das Limit auf 200MB, Enterprise auf 500MB. Das ist real und sollte bei großen Datei-Uploads oder Synchronisationstools berücksichtigt werden. Es handelt sich um eine Begrenzung der Body-Größe bei CDN-Proxy-Traffic, nicht um eine spezielle Chunk-Drop-Quirk bei Tunnel.

Wie das Vendor Pivot Insurance funktioniert

Vendor Lock-in im Tunneling-Bereich entsteht, wenn ein Entwickler CI-, Webhook-Tests oder Automatisierungs-Pipelines um eine proprietäre API oder einen Closed-Source-Relay baut. Wenn der Anbieter seine Preise ändert oder den Dienst einstellt, muss der Entwickler seine Netzwerkarchitektur komplett neu aufbauen. Vendor Pivot Insurance ist die architektonische Garantie, dass ein Entwickler die gleiche Infrastruktur auf eigener Hardware mit derselben Software selbst bereitstellen kann.

Diese Garantie ist durch die GNU Affero General Public License v3.0 (AGPLv3) kodifiziert. Im Gegensatz zu permissiven Lizenzen wie MIT oder Apache 2.0 schließt die AGPL die “SaaS-Lücke” in der GPL: Jede Organisation, die die Software modifiziert und als Netzwerkdienst betreibt, muss die modifizierte Quellcode-Version den Nutzern, die über das Netzwerk darauf zugreifen, zugänglich machen — nicht nur denjenigen, die eine kompilierte Binärdatei erhalten. Für einen Reverse-Proxy-Relay bedeutet das, dass der Kernserver nicht heimlich abgetrennt und proprietär gemacht werden darf. Wenn ein verwalteter AGPL-lizenzierter Tunneling-Dienst seine Preise ändert oder den Dienst einstellt, kann ein Entwickler eine kostengünstige VPS bereitstellen, denselben Relay-Code deployen und ohne Änderungen an der lokalen Client-Konfiguration weiterlaufen.

Bewertung der modernen Tunneling-Landschaft

Tool	Server-Lizenz	Hauptsprache	Unterstützte Protokolle	Anwendungsfall	Kostenprofil
ngrok	Proprietär	Go	HTTP, TCP, TLS	Legacy Webhook-Tests	Kostenlos (3 Endpunkte/1GB/20K req) → 10–20+ USD/Monat
rustunnel	AGPL v3.0	Rust	HTTP, TCP, UDP, P2P	AGPL Reverse-Proxy Self-Hosting	$0 selbst gehostet / $3+ PAYG
frp	Apache 2.0	Go	HTTP, HTTPS, TCP, UDP	Heavy Self-Hosting	VPS-Kosten (~$4/Monat)
Cloudflare Tunnel	Proprietär (Cloud)	Go (cloudflared)	HTTP, HTTPS via CDN; TCP/UDP via WARP	Webhooks, HTTPS kostenlos	Kostenlos (Domain erforderlich)
rathole	MIT	Rust	TCP, UDP (kein HTTP-Routing)	Port-Forwarding auf Low-Spec VPS	VPS-Kosten (~$4/Monat)
bore	MIT	Rust	TCP nur	Minimalistisches Port-Forwarding	Kostenloser öffentlicher Relay oder VPS (~$4/Monat)
Tailscale Funnel	Proprietär (Cloud)	Go	HTTPS/TCP ingress (nur Ports 443, 8443, 10000)	Service-Teilen außerhalb des Tailnets	Kostenlos (Personalplan)

Ein paar Korrekturen, die bei der Darstellung dieser Tabelle oft übersehen werden: rathole unterstützt kein HTTP-aware Routing — es ist ein generischer TCP/UDP-Port-Forwarder ohne Subdomain- oder Pfad-basiertes HTTP, anders als frp oder ngrok. Und Tailscale Funnel ist kein allgemeines L3-Mesh — das zugrunde liegende Tailscale-Netzwerk ist das private WireGuard-Mesh; Funnel ist die enge, explizite Funktion, die einen einzelnen Dienst aus diesem privaten Mesh auf das öffentliche Internet über HTTPS oder TCP auf eine kleine festgelegte Portgruppe ausgibt.

Das Rust-gestützte Ökosystem

Performance und Speichersicherheit sind entscheidend für Edge-Relays, die Millionen von multiplexierten WebSocket- und TCP-Verbindungen handhaben, und die Open-Source-Community bewegt sich zunehmend weg von Go und Node.js hin zu Rust für diese Schicht. rathole tauscht HTTP-Bewusstsein gegen rohe Durchsatzleistung und einen minimalen Fußabdruck — seine Binärdatei kann in einer entpackten Version nur etwa 500 KB groß sein, mit einer größeren, voll ausgestatteten Release-Binärdatei. Es authentifiziert und verschlüsselt mit dem Noise Protocol Framework, standardmäßig im server-authentifizierten Noise_NK-Muster (nicht das unauthentifizierte Noise_NN, das manchmal in Tutorials gezeigt wird), was das Generieren eines Keypairs mit rathole --genkey erfordert und die Konfiguration des Clients mit dem öffentlichen Schlüssel des Servers. bore geht noch einen Schritt weiter in Richtung Minimalismus: eine einzelne Rust-Binärdatei, nur TCP, mit einem kostenlosen Community-Relay bei bore.pub. Das --secret-Flag authentifiziert den Tunnel-Handshake, verschlüsselt den Tunnelverkehr aber standardmäßig nicht — TLS muss vom hinter dem Tunnel laufenden Dienst oder auf einer anderen Ebene gehandhabt werden.

In diesem rust-gestützten Feld ist rustunnel ein neuer, voll ausgestatteter Mitspieler, der direkt auf ngrok’s Anwendungsfall abzielt. Es ist unter AGPL lizenziert, stellt lokale HTTP-, TCP- und UDP-Dienste (plus native Peer-to-Peer-Tunnels mit Shared-Secret-Authentifizierung) über einen verwalteten Edge oder einen selbst gehosteten Relay bereit und hat derzeit etwa 600–650 Sterne auf GitHub mit stetiger Aktivität bis 2026.

• Architektur & Verschlüsselung: Client-Server-Verkehr läuft über TLS-terminierte, verschlüsselte WebSocket-Verbindungen, mit automatischer Let’s Encrypt-Provisionierung für generierte öffentliche Endpunkte.
• Hohe Verfügbarkeit: Mehrere Backends können hinter einer benutzerdefinierten Subdomain oder einem TCP-Port sitzen, die auf gesunde Mitglieder verteilt sind, mit konfigurierbaren TCP/HTTP-Gesundheitsprüfungen, sodass ein ausgefallenes Backend automatisch aus dem Betrieb genommen wird.
• Beobachtbarkeit: Ein Vollbild-Terminal-Dashboard zeigt den Live-Status der Sitzungen, Latenz pro Region und Request-per-Second-Zähler, sowie maschinenlesbare JSON-Ausgaben. Die eigenen Materialien des Projekts listen auch Prometheus-Metriken und Audit-Logging als Features auf — nützlich für Verbindungs- und Tunnel-Telemetrie (wer verbunden ist, wann, wie viel Daten bewegt wurden), nicht für die Inspektion des tatsächlichen Tunnel-Payloads, was mit rustunnel’s Datenschutzhaltung übereinstimmt.
• KI-Agenten-Integration: Es liefert einen nativen MCP-Server mit One-Click-Setup-Anleitungen für Cursor, Claude Code, Claude Desktop und Windsurf, verteilt als native Binärdatei, nicht als npm-Paket.
• Preise: Kostenloses Self-Hosting (unbegrenzte Tunnel, AGPL-Quelle), eine kostenlose gehostete Stufe (bis zu 3 Tunnel, kein benutzerdefiniertes Subdomain), und eine Pay-as-you-go-Hosting-Stufe ab 3 USD/Monat plus 0,10 USD/GB darüber hinaus — kein separates Uptime-Meter, also fallen bei Leerlauf-Tunneln keine Gebühren an. Das verwaltete Edge läuft derzeit in drei Regionen: Helsinki, Hillsboro (Oregon) und Singapur.

Wenn eine verwaltete Cloud-Stufe wie diese die Bedingungen ändert oder den Dienst einstellt, gilt dasselbe Argument wie beim AGPL: Der gleiche Server-Code steht kostenlos für Selbst-Hosting zur Verfügung.

Erkennen und Vermeiden von verwaisten Projekten

Vermeidung von Vendor Lock-in hilft nur, wenn die Open-Source-Alternative tatsächlich gepflegt wird. Die Anzahl der Sterne kann irreführend sein, da sie eher die historische Popularität als die aktuelle Aktivität widerspiegelt.

frp (Fast Reverse Proxy) ist das deutlichste Beispiel für langlebige, aktiv gepflegte Self-Hosting-Infrastruktur in diesem Bereich: Es ist unter Apache-2.0-Lizenz, in Go geschrieben und hat über 106.000 GitHub-Sterne mit kontinuierlicher Commit-Aktivität. Es bietet TCP-, UDP-, HTTP- und HTTPS-Weiterleitung mit vhost-basiertem Subdomain-Routing ohne Drittanbieter-Intermediär.

localtunnel ist im Vergleich eine Warnung wert, auch wenn es in Tutorials immer noch häufig auftaucht: Das Repository localtunnel/localtunnel hat etwa 22.000 GitHub-Sterne, aber die Aktivität bei Commits und Sternen ist seit Mitte 2026 nahezu eingefroren. Ein so ruhiges Projekt birgt echtes Risiko: ungepatchte Abhängigkeiten, Protokoll- und TLS-Divergenz sowie ein nicht gepflegter öffentlicher Relay-Server, der ohne Vorwarnung verschwinden könnte. Für eine kurze Demo ist das okay, aber es ist eine schlechte Basis für etwas, auf das man dauerhaft setzen möchte.

Deployment eines Open-Source-Relays

Der Wechsel von einem proprietären SaaS-Tunnel zu einem selbstgehosteten AGPL-Relay ist eine kurze Liste von Schritten, egal ob du rustunnel, frp oder rathole nutzt:

1. Einen Host bereitstellen. Ein kleiner Linux-VPS mit öffentlicher IP reicht aus — rechne mit etwa 4–6 USD/Monat; das günstigste Basic-Droplet bei DigitalOcean kostet derzeit ca. 4 USD/Monat.
2. DNS konfigurieren. Für HTTP-Routing-Tools (rustunnel, frp) erstelle einen Wildcard-A-Record (z.B. *.tunnel.deinedomain.com) auf die öffentliche IP des VPS, damit der Relay Subdomains dynamisch zuweisen kann. TCP-only-Tools wie rathole und bore benötigen das nicht — sie binden direkt an Ports.
3. Relay deployen. Die meisten dieser Projekte liefern Docker-Images und/oder systemd-Service-Dateien, sodass docker-compose up oder eine Paketinstallation den Server schnell in Betrieb nehmen.
4. Von deinem lokalen Rechner verbinden. Der Client stellt eine dauerhafte, verschlüsselte Verbindung zum VPS her, die eine lokale Adresse wie localhost:8080 mit einem öffentlichen Endpunkt auf deiner Domain verbindet.

Self-Hosting eliminiert willkürliche Bandbreitenbegrenzungen, umgeht CGNAT des ISPs vollständig und — weil der Relay-Code identisch ist — bedeutet eine Preisänderung oder das Einstellen durch einen Anbieter, dass keine Neuprogrammierung notwendig ist. Mit AGPL-geschützter Infrastruktur kontrolliert der Entwickler letztlich die Routing-Regeln.