ngrok vs Tunnelto: Die Open-Source Rust Reverse Proxy Rebellion

Es gibt einen echten Trend in der Entwicklergemeinschaft: eine stetige Abwanderung von kommerziellen SaaS-Tunneling-Proxies hin zu leichten, Open-Source-Tools in Rust. Vieles davon lässt sich auf “Free Tier Fatigue” zurückführen — Entwickler, die genug haben von Bandbreitenlimits, Endpoint-Beschränkungen und Zwischenwarnseiten, wenn sie nur einen Webhook testen wollen.

Ende Dezember 2025 erlebte das Open-Source-Tool Tunnelto einen echten viralen Moment auf GitHub, gewann 565 Sterne an einem Tag und landete auf Platz 3 der Trending-Seite. Dieser Anstieg war nicht inszeniert — er spiegelte echte Frustration bei Entwicklern wider, die nach einer leistungsfähigen, selbsthostbaren, kostenlosen Alternative zu ngrok suchten. Es ist auch ein guter Einstieg in einen breiteren Wandel hin zu privacy-bewusster, selbstgehosteter Entwickler-Tools.

In diesem Leitfaden: warum Entwickler auf Rust Reverse Proxies umsteigen, ein faktencheckter Tunnelto vs ngrok Vergleich, andere Open-Source-ngrok-Alternativen, die es wert sind, bekannt zu werden, und wie das Selbsthosting eines Rust-Tunnels in der Praxis funktioniert.

---

Das Kernproblem: Das Localhost-Dilemma

Jeder Webentwickler stößt irgendwann an die gleiche Wand. Du baust etwas, das mit einem Drittanbieterdienst sprechen muss — Stripe für Zahlungen, Twilio für SMS, Slack für Slash-Befehle. Diese Plattformen kommunizieren via Webhooks: HTTP-Anfragen, die an eine von dir angegebene URL gesendet werden, wenn ein Ereignis eintritt.

Das Problem: Stripe kann keinen Webhook an http://localhost:3000 senden. Dein Entwicklungsserver sitzt hinter NAT und Firewall deines Routers, unsichtbar für das Internet.

Die alten Lösungen

Bevor Tunneling-Tools Mainstream wurden, haben Entwickler das mit:

1. Deployment auf Staging — Commit, Push, auf CI/CD warten, dann den Webhook auslösen. Eine Feedback-Schleife von fünf Sekunden wird zu einer von fünf Minuten.
2. Router-Portweiterleitung — technisch möglich, aber mühsam und nicht das, was man im Heimnetz offen haben möchte.
3. Events mocken — einen Payload einmal erfassen und lokal wiederholen, aber das verpasst echte Edge-Cases.

Der Aufstieg der Localhost-Tunnels

Ein Tunneling-Client läuft auf deinem Rechner, öffnet eine ausgehende Verbindung zu einem öffentlichen Relay-Server und gibt dir eine öffentliche URL. Wenn Stripe diese URL trifft, leitet das Relay den Traffic durch den Tunnel an deinen lokalen Port weiter.

Jahre lang war ngrok die Standardlösung. Es wurde fast synonym für localhost-Tunneling. Doch mit der Weiterentwicklung des Unternehmens zu einer breiteren Sicherheits- und API-Plattform haben einige Entscheidungen im kostenlosen Bereich dazu geführt, dass Teile der Nutzerbasis nach Alternativen suchen.

---

Free Tier Fatigue: Was bei ngrok wirklich gilt

Hier wird viel “ngrok vs. die Welt”-Content online ungenau, daher lohnt es sich, genau zu sein, was ngrok im kostenlosen Tarif tatsächlich einschränkt, laut aktueller ngrok-Dokumentation.

Es gibt kein 2-Stunden-Session-Limit

Diese Behauptung kursiert ständig in Vergleichsartikeln, hält aber einer genauen Prüfung nicht stand — ngrok beschreibt den kostenlosen Plan als “kostenlos für immer” und nicht zeitlich begrenzt durch Session-Länge. Du wirst nicht einfach wegen zwei Stunden getrennt, nur weil die Session vorbei ist. Was Nutzer im kostenlosen Tarif tatsächlich erleben, ist eine Mischung aus:

• 1GB Bandbreite pro Monat, plus ein einmaliges Guthaben von 5$
• Bis zu 3 Online-Endpunkten gleichzeitig (dieses Limit wird nicht monatlich zurückgesetzt)
• ~20.000 HTTP-Anfragen pro Monat
• Zufällige, rotierende Subdomains bei jedem Neustart — das ist das eigentliche Problem für Webhook-Workflows, da du die URL bei Stripe oder anderen Diensten bei jedem Neustart neu registrieren musst.

Wenn dein Tunnel während der Session abbricht, liegt das eher an Netzwerkproblemen, einem Client-Neustart oder dem Erreichen des Bandbreiten- oder Anfrage-Limits, nicht an einem festen Timer. Es lohnt sich, diese “2-Stunden”-Behauptung zu korrigieren — sie ist eine der häufigsten Fehlinformationen in diesem Bereich.

Die Zwischenwarnseite ist echt

Zur Vermeidung von Phishing und Malware fügt ngrok bei URLs im kostenlosen Tarif eine HTML-Interstitielle (“Visit Site”)-Seite vor Browser-Traffic ein. ngrok bietet einen Header (ngrok-skip-browser-warning) an, um dies für API-Clients zu umgehen, aber viele Webhook-Anbieter erlauben keine benutzerdefinierten Header bei ausgehenden Requests — was bei automatisierten Webhook-Deliveries im kostenlosen Tarif tatsächlich Probleme verursachen kann.

Aktuelle ngrok-Preise (Stand Mitte 2026)

ngrok bietet vier Tarife: Free, Hobbyist, Pay-as-you-go, und Enterprise.

• Free — 0$/Monat, 5$ einmaliges Guthaben, 1GB Bandbreite, 3 Endpunkte, ~20k Requests/Monat
• Hobbyist — 10$/Monat (8$ bei Jahresabrechnung), 10$ monatliches Guthaben, 5GB Bandbreite, 3 Endpunkte, ~100k Requests/Monat
• Pay-as-you-go — 20$/Monat Grundgebühr (inklusive 20$ Nutzung), dann Abrechnung nach Verbrauch bei Daten, Requests und Endpoint-Stunden
• Enterprise — individuelle Preise, meist verhandelt pro Deployment

Das “8–29$/Monat”-Framing aus älteren Vergleichen ist ungefähr richtig für Hobbyist/Pay-as-you-go, aber die genauen Tarifnamen und Strukturen haben sich mehrfach geändert — es lohnt sich, die ngrok-Preisseite direkt zu prüfen, da sich das mehrmals im letzten Jahr geändert hat.

---

Die Rust-Rebellion: Tunnelto

Ende Dezember 2025 sorgte Tunnelto — ein in Rust geschriebenes Tunneling-Tool, entwickelt von Entwickler Alex Grinman (GitHub: agrinman/tunnelto) — für Aufsehen, landete auf Platz 3 der GitHub-Trending-Seite und gewann 565 Sterne in 24 Stunden. Zu diesem Zeitpunkt hatte es etwa 3.665 Sterne; wächst seitdem weiter und liegt jetzt bei rund 6.000–7.000 Sternen, mit über 500 Forks.

Ein Detail, das klar hervorgehoben werden sollte, weil es viele Vergleichsartikel verwirrt: Es gibt zwei Produkte, die “tunnelto” heißen.

• tunnelto.dev (agrinman/tunnelto auf GitHub) — das Open-Source-Projekt in Rust mit MIT-Lizenz, um das es in diesem Abschnitt geht. Die letzte Client-Version, v0.1.18, wurde im Mai 2021 veröffentlicht. Das Projekt ist nicht eingestellt — Issues werden gelegentlich bearbeitet, und die Demo-Instanz auf tunnelto.dev läuft noch auf Fly.io — aber es gibt seit Jahren keine neuen CLI-Features, und der selbstgehostete Server unterstützt keine benutzerdefinierten Domains oder integrierte Authentifizierung.
• tunnelto.me — ein komplett separates, aktiv gepflegtes kommerzielles Tunneling-Service mit ähnlichem Namen. Es bietet eine kostenlose Stufe (1 benutzerdefinierte Domain, 1GB Bandbreite/Monat, 1-Stunden-Tunnel-Sessions) und kostenpflichtige Pläne ab ca. 2$/Monat für persistent Domains.

Diese sind nicht derselbe Code, kein Team, kein Produkt — trotz der Darstellung in einigen “ngrok-Alternativen”-Listen, die tunnelto.me’s Preisseite zitieren, als würde sie das Open-Source-Projekt beschreiben.

Architektur von Tunnelto (tunnelto.dev)

Tunnelto basiert vollständig auf async-io auf Tokio, Rusts Standard-Async-Laufzeit. Es besteht aus zwei Komponenten:

1. Der Client — ein leichtgewichtiges Rust-Binary, das lokal läuft (tunnelto --port 8000), und eine ausgehende TCP-Verbindung zum Tunnelto-Server öffnet.
2. Der Server — eine Rust-Anwendung auf einem öffentlich zugänglichen Host, die eingehende HTTP/HTTPS-Anfragen beendet und sie an die richtige Client-Verbindung multiplexiert.

Da es in Rust mit einer Async-Laufzeit geschrieben ist, verarbeitet es viele gleichzeitige Verbindungen mit geringem Speicherverbrauch im Vergleich zu Node.js oder Python-Äquivalenten.

Warum hat es einen Anstieg erlebt?

Einige plausible, nicht-exklusive Erklärungen für den Anstieg im Dezember 2025:

1. Gesammelte Frustration mit ngrok’s Free-Tier-Beschränkungen (Bandbreitenlimits, Endpoint-Beschränkungen, Zwischenwarnseiten), die einen Kipppunkt für eine Gruppe von Entwicklern erreicht haben.
2. Ein Wunsch nach Ownership — die Möglichkeit, den Code zu lesen, zu forken und selbst zu hosten, anstatt auf einen Cloud-Dienst zu setzen.
3. Der allgemeine Halo-Effekt von Rust — Rust war in mehreren Jahren in Stack Overflow’s “Most Admired Language”-Umfrage führend, und der JetBrains Developer Ecosystem Report 2025 schätzte, dass etwa 2,27 Millionen Entwickler Rust in den letzten 12 Monaten genutzt haben. Tools in Rust genießen allein durch “schnell und sicher” einen Glaubwürdigkeits-Boost.

Nimm die Virality-Geschichte mit einer Prise Skepsis — die meisten Gründe für den Anstieg basieren auf einem einzigen Blogpost vom Tag des Trends, nicht auf Umfragedaten.

---

Tunnelto vs ngrok: Ein Vergleich

1. Preisgestaltung und Limits

• ngrok: Kostenloser Tarif wie oben beschrieben (1GB Bandbreite, 3 Endpunkte, zufällige URLs, Zwischenwarnseite). Hobbyist ab 10$/Monat (8$ bei Jahresabrechnung); Pay-as-you-go ab 20$/Monat plus Nutzung.
• tunnelto.dev (Open Source): Die Software selbst ist kostenlos und MIT-lizenziert — du kannst sie auf jedem VPS selbst hosten, das kostet dich nur den VPS-Preis (z.B. ein 5$-VPS). Es gibt keine integrierte Abrechnung oder Bezahlstufe für das Open-Source-Projekt, aber auch keine Unterstützung für benutzerdefinierte Domains oder Authentifizierung ohne eigene Reverse-Proxy-Lösung.
• (Wenn du eine gehostete, aktiv gepflegte kommerzielle Lösung mit benutzerdefinierten Domains im kostenlosen Tarif suchst, ist tunnelto.me — ein anderes Produkt —, das ab 0$ startet und bezahlte Pläne ab ca. 2$/Monat für persistent Domains anbietet. Nicht verwechseln!)

2. Entwickler-Erfahrung

• ngrok: Reife CLI, breite Framework-Integration, Dashboard mit HTTP-Traffic-Inspektion.
• tunnelto.dev: Ein einziger Befehl (tunnelto --port 3000) bringt dich schnell zu einer öffentlichen URL. Es ist bewusst minimalistisch — du verzichtest auf ngrok’s Traffic-Inspection-Tools zugunsten von Einfachheit und ohne zwangsweise Zwischenwarnseiten.

3. Hosting und Kontrolle

• ngrok: Closed Source, vollständig abhängig von ngrok’s Cloud. Bei Problemen in der Infrastruktur hat dein Tunnel auch Probleme.
• tunnelto.dev: MIT-Lizenz. Du kannst den Code lesen, forken und den Server selbst laufen lassen — das Projekt beschreibt den Deployment-Prozess via Docker und Umgebungsvariablen. Du bist für die Verfügbarkeit und Infrastruktur verantwortlich.

4. Custom Domains

• ngrok: Benutzerdefinierte/stabile Domains erfordern einen kostenpflichtigen Tarif.
• tunnelto.dev (self-hosted): Du kannst deine eigene Domain auf deinen Server zeigen, bist aber selbst für TLS-termination verantwortlich (z.B. via Nginx oder Caddy). Das wird nicht automatisch erledigt, wie bei einigen Mitbewerbern.

---

Das Ökosystem: Weitere Open-Source-ngrok-Alternativen

Tunnelto ist bei weitem nicht die einzige Option. Hier ein Überblick, basierend auf den Repos der jeweiligen Projekte.

1. rustunnel

Ein AGPL-lizenziertes Rust-Tunneling-Tool (joaoh82/rustunnel), das selbstgehostet oder als Managed-Service (Pay-as-you-go) genutzt werden kann. Herausragend ist die MCP-Server-Unterstützung für KI-Agenten, sowie UDP-Unterstützung, P2P-Tunnels und Load-Balancing-Gruppen mit Health Checks — echte Differenzierung gegenüber älteren Tools, die vor der aktuellen Welle an Agenten-Tools entstanden sind.

2. bore

Von Eric Zhang (ekzhang/bore) entwickelt, ist bore ein bewusst minimalistischer MIT-lizenzierter TCP-Tunnel — etwa 400 Zeilen async Rust. Es hat rund 11.100 Sterne. Es macht nur eins: einen lokalen TCP-Port zu einem entfernten Server weiterleiten. Kein HTTP-Parsing, kein TLS, kein Dashboard.

Wenn du es bewertest: Das optionale --secret-Flag fügt HMAC-basierte Authentifizierung hinzu, um wer einen Tunnel öffnen darf. Laut Dokumentation schützt das nur den Handshake — der tatsächliche Tunnelverkehr ist standardmäßig unverschlüsselt. Wenn du etwas weiterleitest, das kein eigenes TLS hat, ist der Traffic für Beobachter sichtbar. Das wird in vielen “bore vs. ngrok”-Vergleichen oft ausgelassen.

3. rathole

Als Hochleistungsalternative zu frp (rathole-org/rathole) positioniert, unterstützt rathole TCP und UDP, ist für Embedded-Systeme und Router optimiert (Binary ca. 500 KB) und unterstützt Hot-Reload des Konfigs ohne Neustart.

4. frp (Fast Reverse Proxy)

In Go geschrieben, aber der unbestrittene Heavyweight — fatedier/frp hat ca. 108.000 GitHub-Sterne und 15.000 Forks. Es unterstützt HTTP, HTTPS, TCP, UDP, WebSockets, konfiguriert via TOML, und ist die Standardlösung für komplexe, produktive, selbstgehostete Deployments.

5. Cloudflare Tunnel (cloudflared)

Nicht Open Source (Server-Seite bei Cloudflare), aber der cloudflared-Client ist open source, der Dienst selbst kostenlos bei Cloudflare. Ab 2026 nutzt Cloudflare Tunnel standardmäßig QUIC (HTTP/3) und ist Teil der “Cloudflare One” Zero Trust Plattform — du kannst eine Access-Policy (SSO, E-Mail OTP, Drittanbieter-Identitäten) vor einen Tunnel setzen, ohne eigene Auth-Implementierung. Für benannte Tunnels braucht es DNS bei Cloudflare, aber schnelle Tunnel (cloudflared tunnel --url) funktionieren auch ohne Domain, ähnlich ngrok im kostenlosen Tarif.

---

Warum Rust dafür passt

Es ist kein Zufall, dass viele aktuelle Tunneling-Tools (Tunnelto, bore, rathole, rustunnel) in Rust geschrieben sind:

1. Hohe Parallelität, geringer Speicherverbrauch — ein Tunnel-Server kann Tausende von Idle-Verbindungen offen halten. Rusts async-Model schafft das mit deutlich weniger Speicher als eine Garbage-Collection-basierte Laufzeit.
2. Vorhersehbare Latenz — kein GC-Pause, keine unvorhersehbaren Mikrostörungen, wichtig bei Echtzeit-Anwendungen wie WebSockets.
3. Speichersicherheit — netzwerknahe Proxies sind häufig Ziel von Speicherfehlern in C/C++. Rusts Compiler verhindert ganze Klassen davon bereits beim Kompilieren.
4. Plattformübergreifende statische Binärdateien — Rust cross-kompiliert problemlos, du bekommst eine einzelne Binärdatei ohne Laufzeitabhängigkeiten.

---

Selbsthosting eines Rust-Localhost-Tunnels: Was wirklich dazugehört

Wenn du deinen eigenen Tunnel-Server laufen lassen willst, hier eine realistische Übersicht — anhand von Tunnelto’s dokumentiertem Self-Hosting-Ansatz, nicht einer idealisierten Version.

Voraussetzungen

• Ein VPS mit öffentlicher IP (DigitalOcean, Linode, AWS EC2 etc.)
• Eine Domain, die auf den VPS zeigt, falls du eine eigene willst
• Erfahrung mit SSH, Docker und Reverse-Proxy-Konfiguration

Schritt 1: Rust-Toolchain installieren (bei Build aus Source)

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

Schritt 2: Server starten

Das Tunnelto-Server-Setup ist in Docker dokumentiert, kompiliert für musl, konfiguriert via Umgebungsvariablen — kein einzelner CLI-Flag für benutzerdefinierte Domains. Klone das Repo und baue es entweder aus Source oder ziehe das veröffentlichte Image:

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

Realistischerweise solltest du das hinter Nginx oder Caddy für TLS-termination laufen lassen — der selbstgehostete Server unterstützt kein automatisches HTTPS oder benutzerdefinierte Domains out-of-the-box wie die Demo auf tunnelto.dev.

Schritt 3: Mit dem Client verbinden

cargo install tunnelto
tunnelto --port 3000

Standardmäßig verbindet sich der Client mit dem gehosteten tunnelto.dev. Für den eigenen Server musst du die Adresse im Client konfigurieren — siehe tunnelto --help für die Flags, da ältere Anleitungen oft nicht mehr aktuell sind.

Hinweis: Die Dokumentation erwähnt, dass Multi-Server-Hosting nicht ohne weiteres unterstützt wird, da es auf zentralem Zustand basiert. Für Einzelpersonen oder kleine Teams geeignet, aber kein vollwertiger Ersatz für ngrok in der Produktion ohne zusätzliche Anpassungen.

---

Der größere Trend: Ownership der Entwickler-Erfahrung

Der Anstieg bei Tunnelto ist Teil eines größeren Musters: Früher haben Entwickler alles an SaaS-Dienste ausgelagert — das macht auch Sinn bei Managed Databases oder globalen CDNs. Für einfache Utilities wie localhost-Tunneling entscheiden sich immer mehr Entwickler, das selbst zu machen, um wieder Kontrolle zu haben.

Selbsthosting eines dauerhaften, eigenen Domains-Tunnels auf einem 5$/Monat VPS — gemeinsam im Team — macht die Kosten eines 20$/Monat-Produkts deutlich schwerer zu rechtfertigen, wenn man keine erweiterten Features wie Traffic-Inspektion oder SSO braucht.

Fazit

Die “Rust Tunneling Rebellion” ist eine echte, wenn auch bescheidene Kurskorrektur, kein vollständiger Ersatz für kommerzielle Lösungen. ngrok’s kostenloser Tarif ist heute restriktiver — Bandbreitenlimits, Endpoint-Beschränkungen, Zwischenwarnseiten — aber die Behauptung eines “2-Stunden-Limits” ist in der aktuellen ngrok-Dokumentation schlicht falsch und sollte korrigiert werden.

Tools wie Tunnelto, bore, rathole und rustunnel bieten echte, kostenlose, selbsthostbare Alternativen, die oft schneller sind, wenn man keine Enterprise-Features braucht. Achte bei Vergleichen auf die Unterscheidung zwischen tunnelto.dev und tunnelto.me — sie sind unterschiedlich. Ob du einen kostenlosen Dienst nutzt oder deinen eigenen Rust-Tunnel aufsetzt, das Angebot ist heute deutlich breiter und günstiger als vor zwei Jahren.

---

Changelog

• Entfernt die falsche “2-Stunden ngrok Free-Tier-Session”-Behauptung und ersetzt sie durch die tatsächlichen Limits: 1GB Bandbreite/Monat, 3 Endpunkte, ~20k Requests, rotierende Subdomains, Zwischenwarnseite.
• Korrigiert die aktuellen Preise und Pläne von ngrok: Free (0$), Hobbyist (10$/Monat, 8$ jährlich), Pay-as-you-go (20$/Monat + Nutzung), Enterprise (individuell).
• Korrigiert die Verwechslung zwischen tunnelto.dev (Open-Source in Rust) und tunnelto.me (kommerzieller Dienst). Beide sind unabhängig.
• Aktualisiert die GitHub-Statistiken für Tunnelto: von 3.665 Sternen (Dez 2025) auf ca. 6.000–7.000 heute; letzter Client-Release im Mai 2021; der selbstgehostete Server unterstützt keine automatische TLS- oder Domain-Konfiguration.
• Angepasst die Anleitung zum Self-Hosting: entfernt unbestätigte Befehle, basiert jetzt auf der offiziellen Docker- und Umgebungsvarianten-Dokumentation, Hinweis auf Multi-Server-Hosting ist noch relevant.
• Ergänzt die Statistiken für das Ökosystem: bore (~11.100 Sterne, Eric Zhang), frp (~108.000 Sterne), rathole (TCP/UDP, Embedded-Fokus), rustunnel (AGPL, MCP für KI-Agenten, GitHub: joaoh82/rustunnel).
• Entfernt unbelegte Behauptungen zu rustunnel in Bezug auf Umfragen 2026.
• Aktualisiert Cloudflare Tunnel-Details: QUIC/HTTP3, Zero Trust, bis 50 Nutzer, automatische Policies.
• Bestätigt die Rust-Adoptionszahl (~2,27 Mio. Entwickler in den letzten 12 Monaten) laut JetBrains 2025.
• Entfernt Inline-Zitate und Referenzliste, Quellen sind in den Text integriert.