ngrok vs. zrok: Die Open-Source-Alternative mit Zero-Trust für modernes Ingress-Tunneling

Seit fast einem Jahrzehnt tippten Entwickler, wenn sie eine lokale Anwendung oder einen internen Webhook sofort öffentlich zugänglich machen wollten, einen einzigen Befehl in ihr Terminal: ngrok http 8080.

Das reichte jahrelang aus. Doch die moderne DevOps- und Sicherheitslandschaft hat sich gewandelt. Mit zunehmendem Fokus auf Datenhoheit, Compliance und Perimeter-Schutz in Unternehmen wird das Routing sensibler interner APIs, lokaler Datensätze oder Microservices durch einen zentralen Cloud-Proxy zunehmend zu einem Compliance-Thema für regulierte Teams. Hinzu kommen die Preis- und Quotenänderungen bei ngrok im Februar 2026 — die den kostenlosen Tarif deutlich einschränkten — und es überrascht nicht, dass Entwickler verstärkt nach Alternativen suchen.

Hier kommt zrok ins Spiel. Basierend auf dem Open-Source-Framework OpenZiti von NetFoundry ist zrok eine Peer-to-Peer (P2P) Sharing- und Zero-Trust-Tunneling-Plattform. Es unterstützt vollständig den klassischen “public URL”-Workflow, bietet aber auch das Ingress-Paradigma um, indem es private, Peer-to-Peer-Tunnel bereitstellt, die niemals das öffentliche Internet berühren.

Dieser Leitfaden erklärt die architektonischen, finanziellen und philosophischen Unterschiede zwischen ngrok und zrok — und aktualisiert einige Behauptungen, die 2026 nicht mehr gelten.

Die Kernarchitektur: Unterschiedliche Ansätze

Traditionelles Cloud-Proxying (ngrok)

Traditionelles Tunneling basiert auf einem zentralisierten Client-Server-Relaismodell. Beim Start einer Sitzung wird eine dauerhafte ausgehende Verbindung zu einem öffentlichen Relay-Node hergestellt. Der Anbieter stellt eine öffentlich zugängliche Domain bereit, und eingehender Traffic an diese URL landet auf den Cloud-Servern des Anbieters, wird dort inspiziert und weitergeleitet und schließlich an dein Gerät gesendet.

Diese Architektur hat drei bekannte Nachteile:

• Datenhoheit: Dein Payload — eine Authentifizierungsanfrage, eine rohe Datenbankabfrage, proprietäre Kundendaten — passiert einen Drittanbieter-Relais.
• Zentraler Ausfallpunkt: Fällt die Cloud-Region des Anbieters aus, sind deine externen Endpunkte betroffen, unabhängig von deiner eigenen Verfügbarkeit.
• Latenz: Der Traffic macht mehrere Hops zu einem zentralen Gateway und zurück.

Zero-Trust, Overlay Mesh Networking (zrok)

zrok ist eine “ziti-native” Anwendung — es richtet ein overlay-basiertes Netzwerk mit Identitätsprüfung mittels OpenZiti ein, anstatt nur ein Relais-Tunnel zu verwenden. Jeder Dienst, Endpunkt und jedes Gerät benötigt eine verifizierte, kryptografisch signierte Identität, bevor eine Verbindung hergestellt werden kann. Standardmäßig eliminiert zrok eingehende Ports auf deinem lokalen Rechner, indem es nur ausgehende Verbindungen nutzt, um Knoten zu verknüpfen.

Öffentliches Teilen vs. Private Peer-to-Peer-Tunnel

Das öffentliche Paradigma (beide Tools)

Beide Tools erlauben es, eine öffentliche URL zu erstellen, um localhost mit dem Internet zu teilen. Mit zrok share public http://localhost:8080 wird eine öffentliche URL durch den zrok-Frontdoor-Proxy bereitgestellt, inklusive automatischem TLS und Schutz vor oversized Payloads sowie SQL-Injection.

Hier eine Korrektur: zrok ist nicht immun gegen die Friktionen, für die ngrok oft kritisiert wird. Unverifizierte kostenlose zrok-Konten sehen beim ersten Besuch einer öffentlichen Freigabe ebenfalls eine Anti-Phishing-Interstitialseite — genau wie ngrok. Die Verifizierung deines zrok-Kontos mit einer Kreditkarte (kostenlos) entfernt diese Hürde, genauso wie ein Upgrade des ngrok-Plans.

Das private Peer-to-Peer-Paradigma (exklusiv bei zrok)

Für sensible Unternehmens-Microservices, interne Staging-Datenbanken oder vertrauliche KI-Trainingsdaten ist die Veröffentlichung eines authentifizierten öffentlichen URLs oft ein unakzeptables Risiko. Hier ändert zrok das Spiel — es erstellt einen verschlüsselten Tunnel, der niemals das öffentliche Internet berührt oder registriert.

+-----------------------+                    +-----------------------+
|  Host (Dein Rechner)  |                    | Gast (Dein Peer)      |
|                       |                    |                       |
|  [Lokale App: 8080]   |                    |  [Lokaler Proxy: 9090]|
|          ^            |                    |          ^            |
|          |            |                    |          |            |
|   (zrok share private)|                    |   (zrok access private|
+----------+------------+                    +----------+------------+
           |                                            |
           v                                            v
     [OpenZiti Identity] <====================> [OpenZiti Identity]
                         End-to-End verschlüsselter Tunnel

Workflow:

1. Private Ressource hosten — der Host führt zrok share private http://localhost:8080 aus. Statt einer öffentlichen URL liefert zrok einen einzigartigen, temporären Zugriffstoken.
2. Token out-of-band senden — z.B. verschlüsselt im Chat oder über einen internen Secrets-Manager, niemals über den öffentlichen Freigabekanal.
3. Client binden — der Empfänger führt zrok access private <token> aus.
4. Zugriff via Loopback — zrok startet einen lokalen Proxy auf dem Rechner des Empfängers, z.B. http://localhost:9090.

Da kein öffentlicher DNS-Eintrag oder Edge-Routing-Knoten erstellt wird, bleibt der Datenstrom für Scanner und Bots unsichtbar.

Detaillierter Feature-Vergleich

Feature	ngrok	zrok
Lizenzmodell	Proprietär / kommerziell, geschlossen	Open-Source (Apache 2.0), basiert auf OpenZiti
Kernarchitektur	Zentralisiertes HTTP/TCP-Cloud-Relais	Verteiltes, identitätsbasiertes Zero-Trust-Overlay
Selbsthosting	Nicht möglich — nur ngrok-Cloud	Voll unterstützt — Docker, Linux-Binärdatei, “Raspberry Pi bis Unternehmensgröße”
Private Freigabe	Nicht verfügbar — alle Endpunkte sind öffentlich	Native P2P-Private-Sharing, kein öffentlicher Endpunkt
Persistente kostenlose URL	Ja, seit 2023 — jeder kostenlose Account erhält eine statische “Dev-Domain”	Ja, via reservierte/named Shares
Free-Tier-Limits	1 GB/Monat Daten, 3 Online-Endpunkte, 20.000 Requests/Monat, 5.000 TCP-Verbindungen	5 GB/Tag Daten, 25 Umgebungen, 50 Share-Backends, 50 Private-Access-Frontends
First-Visit-Interstitial	Ja	Ja
Zusätzliche Utilities	Webhook-Inspektion, Request-Replay, OAuth	Integrierter Datei-/Laufwerks-Sharing, HTTP/TCP/UDP-Tunnel, WebDAV-Laufwerke

Preisgestaltung, Bandbreite und eine Korrektur zum ngrok-Free-Tier

Der ursprüngliche Entwurf wiederholte alte Mythen über ngrok — dass Tunnel “häufig Zeitüberschreitungen” hätten und URLs “bei jedem Start rotieren”. Beides ist nicht mehr korrekt, und es ist wichtig, präzise zu sein, was sich tatsächlich geändert hat.

Was nicht mehr stimmt: ngrok-Dokumentation bestätigt explizit, dass das Free-Tier “keine Endpoint-Timeouts hat” — du kannst einen kostenlosen Endpoint unbegrenzt im Hintergrund laufen lassen. Seit der Einführung der kostenlosen statischen “Dev-Domains” (2023) erhält jeder kostenlose Account eine dauerhafte Subdomain wie dein-name.ngrok-free.dev, die beim Neustart des Agents gleich bleibt. Das klassische Problem, dass Webhook-URLs bei jedem Neustart von ngrok brechen, ist damit beseitigt.

Was aber weiterhin gilt und 2026 zum Problem wird: ngrok hat im Februar 2026 die Quoten im Free-Tier deutlich verschärft. Das aktuelle Free-Plan-Limit sind 1 GB Daten pro Monat, 20.000 HTTP-Requests, 5.000 TCP-Verbindungen und nur 3 gleichzeitige Online-Endpunkte — ohne Wildcard- oder benutzerdefinierte Domains, und keine TLS-Endpunkte im Free-Tarif. Für einen Solo-Entwickler, der gelegentlich Webhook-Tests macht, reicht das aus; bei höherem Traffic greifen Teams eher zu Hobby- oder Pay-as-you-go-Tarifen.

Die Open-Source-Freiheit von zrok

Da zrok (und das darunterliegende OpenZiti) unter Apache 2.0 lizenziert ist, behalten Entwickler die volle Kontrolle über ihren Ingress-Pfad. NetFoundrys Managed-Free-Tier bei zrok.io umfasst aktuell:

• 5 GB tägliche Datenübertragung
• Bis zu 25 Umgebungen (Benutzer oder Dienste auf einem Gerät)
• 50 Share-Backends (ephemeral oder reserviert)
• 50 Private-Access-Frontends
• Die First-Visit-Interstitial-Seite entfällt nach Verifizierung per Kreditkarte (kostenlos)

Für regulierte Umgebungen — HIPAA, GDPR, SOC 2 Typ II — kann das gesamte Control-Plane auf eigener VPS oder privater Cloud laufen, da zrok nur eine einzelne Binärdatei ist, die Eigentum an Übertragungswegen, Metriken und Identitätsdaten behält.

zrok v2.0: Was hat sich im März 2026 geändert?

Im März 2026 wurde eine bedeutende Version 2.0 veröffentlicht. Viele Tutorials (inklusive der ursprünglichen Vorlage dieses Artikels) beziehen sich noch auf v1. Hier die wichtigsten Änderungen:

• Der Binärname ist jetzt zrok2, nicht mehr zrok. Beide können parallel auf derselben Maschine laufen — v2 nutzt sein eigenes Verzeichnis (~/.zrok2), eigene Umgebungsvariablen (ZROK2_*) und eigene systemd-Einheiten, sodass Upgrades bestehende v1-Setups nicht stören.
• Reserviertes Sharing wurde durch ein Namespace/Namen-Modell ersetzt. Die alten Befehle zrok reserve, zrok release, zrok share reserved sind weg; zrok2 create share und zrok2 delete share verwalten nun sowohl öffentliche als auch private Shares, und zrok2 modify name -r kann ein ephemeres Share auf Wunsch dauerhaft machen, ohne es zu zerstören.
• Der VPN-Backend-Modus wurde entfernt. Die Funktionalität für Host-zu-Host VPN, die in älteren Dokumentationen erwähnt wurde, wurde in v2 entfernt, weil die zugrunde liegenden TUN-Bibliotheken Konflikte verursachten. Falls dein Workflow zrok share private --backend-mode vpn nutzte, ist dieser Pfad momentan nicht mehr verfügbar — das Migrationshandbuch von zrok bietet Alternativen.

Neu in 2026: Zero-Trust-Infrastruktur für KI-Agenten

Besonders für Teams, die MCP-Traffic und agentenbasierte Infrastruktur planen, ist das relevant:

• openziti/mcp-gateway fasst mehrere MCP-Backends zusammen — lokale stdio-Server und entfernte zrok-Sharing-Instanzen — in eine einzige, namespaced Verbindung für KI-Clients, mit Filterregeln pro Tool und isolierten Sessions.
• ziti-mcp-server kapselt die gesamte Ziti Management API — 209 Tools für Identitäten, Dienste, Edge-Router, Policies und Fabric-Operationen — als MCP-Server, sodass ein Agent in z.B. Claude Desktop oder Cursor die OpenZiti-Netzwerke interaktiv verwalten kann.
• openziti/llm-gateway ist ein OpenAI-kompatibler Proxy, der semantisches Routing für OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI und Ollama bietet, wobei der Traffic über das Zero-Trust-Overlay läuft.

Alle drei sind Open-Source und werden von NetFoundry unterstützt. Sie nutzen die gleichen privaten Sharing-Primitives wie oben beschrieben — ein MCP-Tool-Endpunkt kann genau wie ein privater HTTP-Backend geteilt werden, ohne Listening-Port oder öffentliche URL, was das “Dark by default”-Prinzip dieses Artikels unterstreicht.

Fazit: Wann welches Tool verwenden?

Wähle ngrok, wenn: - Du ein schnelles, nicht-sensitives Hobby-Projekt aufsetzt und eine etablierte, gut dokumentierte Plattform suchst. - Dein Workflow bereits auf ngrok-Dashboard, Traffic-Inspection oder Request-Replay setzt. - Dein Nutzungsvolumen innerhalb von 1 GB/Monat und 20.000 Requests/Monat liegt oder du bereit bist, bei Bedarf auf Hobby- oder Pay-as-you-go-Tarife umzusteigen.

Wähle zrok, wenn: - Sicherheit und Privatsphäre höchste Priorität haben — du willst interne APIs oder Metriken teilen, ohne jemals einen öffentlichen Endpunkt zu erstellen. - Datenhoheit wichtig ist — ein Open-Source-Tool, das du vollständig in einer privaten VPC selbst hosten kannst. - Du eine wirklich großzügige Free-Tier möchtest — 5 GB/Tag, keine Zeitlimits. - Du integrierte Datei-/Laufwerksfreigaben brauchst oder mit Zero-Trust MCP/Agent-Infrastruktur experimentierst.

Durch den Wechsel von zentralen Cloud-Proxies zu identitätsgeprüften, Zero-Trust-Tunneln bietet zrok Teams eine selbst-hostbare, compliance-freundliche Lösung für Ingress-Konnektivität — mit dem Vorbehalt, dass sich, wie bei jedem aktiven Open-Source-Projekt, Command-Interface und Features (z.B. VPN-Entfernung in v2.0) weiterentwickeln können.

---

Changelog

Korrekturen: - Entfernt die Behauptung, dass ngrok-Free-Tunnel “häufig Zeitüberschreitungen” haben — ngrok-Dokumentation bestätigt, dass der Free-Tarif keine Endpoint-Timeouts hat. - Entfernt die Behauptung, dass ngrok-URLs “bei jedem Start rotieren” — seit 2023 hat jeder ngrok-Account eine statische, persistent “Dev-Domain”; das war veraltete Mythen, nicht mehr aktuell. - Aktualisiert die Limits im Free-Tarif auf die tatsächlichen Werte (1 GB/Monat, 3 Endpunkte, 20.000 Requests, 5.000 TCP-Verbindungen), basierend auf ngrok-Dokumentation. - Hinweis, dass zrok ebenfalls eine First-Visit-Interstitial-Seite bei unverified Free-Accounts zeigt — das wurde im ursprünglichen Entwurf impliziert, ist aber auch bei ngrok üblich. - Notiert, dass das VPN-Backend in v2.0 entfernt wurde, weil die Abhängigkeiten Konflikte verursachten.

Hinzugefügt: - Abschnitt “zrok v2.0” mit Details zum zrok2-Binary, Namespace/Namen-Modell und VPN-Entfernung. - Abschnitt zu 2026 Zero-Trust-Infrastruktur für KI-Agenten: openziti/mcp-gateway, ziti-mcp-server (209 Ziti Management API-Tools), openziti/llm-gateway. - Bestätigung der aktuellen zrok-Free-Tier-Zahlen (5 GB/Tag, 25 Umgebungen, 50 Share-Backends, 50 Private-Frontends) anhand der zrok-Preisseite.

Entfernt: - Übertriebene Marketing-Formulierungen (“ultimativ”, “Enter zrok”) wurden entschärft. - Formatierungsartefakte aus dem Originaltext.

Quellen: ngrok Preis- und Limits-Dokumentation, ngrok Blog zu static Domains, zrok Preisseite, OpenZiti Tech Blog, zrok CHANGELOG, GitHub-Releases, openziti/mcp-gateway, ziti-mcp-server, Better Stack Community Guide.