Beyond the CLI: Zero Trust direkt in Ihre App-Code einbetten mit Zrok & OpenZiti

Für Jahre war die Standardantwort auf die Frage “Wie expose ich einen lokalen Dienst ins Internet” ein einzelner Terminalbefehl: Ein Tunneling-Tool auf einen Port zeigen lassen und eine öffentliche URL erhalten. Dieser Workflow ist schnell, basiert aber auf einem architektonischen Kompromiss, der leicht übersehen werden kann — ein standardmäßiger Reverse-Proxy-Tunnel bedeutet immer noch einen hörenden Endpunkt, der vom offenen Internet erreichbar ist, und von Scannern entdeckt werden kann, sobald er live geht.

Für einen Webhook-Empfänger oder eine Demo ist dieses Risiko akzeptabel. Für einen Dienst, der mit einer Produktionsdatenbank, einem internen Admin-Panel oder einem proprietären Model-Endpunkt spricht, ist es eine größere Angriffsfläche, als die meisten Teams bei einer einfacheren Alternative wählen würden.

Hier setzt das OpenZiti-Ökosystem — und das darauf aufbauende Sharing-Tool zrok — an. Anstatt “öffentliche URL” als die einzige Form eines Tunnels zu betrachten, erlaubt OpenZiti, Zero-Trust-Identität und Verschlüsselung in drei verschiedene Schichten zu pushen: das Netzwerk, den Host oder die Anwendung selbst. Dieser Beitrag erklärt, wie dieses Modell funktioniert, wie zrok’s öffentliche und private Sharing-Modi darauf abbilden, was sich in der kürzlichen Version 2.0 von zrok geändert hat und wohin dieses Ökosystem mit KI-Agenten und MCP-Infrastruktur im Jahr 2026 steuert.

Der Architektonische Wandel: Verschiebung der Vertrauensgrenze

OpenZiti ist eine Open-Source, Apache 2.0-lizenzierte Zero-Trust-Netzwerkplattform, entwickelt und gesponsert von NetFoundry. Ihr Grundprinzip ist einfach: Ein Netzwerkdienst sollte nicht nur erreichbar sein, weil ein Gerät zufällig im richtigen LAN sitzt oder eine VPN-Verbindung offen hat. In einem OpenZiti-Netzwerk benötigt jede Verbindung — Mensch, Microservice oder automatisierte Workload — eine eindeutige kryptografische Identität (gestützt durch x509-Zertifikate), die vor einer Verbindungsherstellung explizit überprüft wird.

Die Mechanik läuft über ein privates Overlay-Netzwerk — ein Mesh aus Edge-Routern:

• Edge-Router bilden die Einstiegspunkte und die verschlüsselte Datenebene des Overlays. Öffentlich zugängliche Router akzeptieren eingehende Verbindungen aus dem Internet; private Router können vollständig innerhalb einer vertrauenswürdigen Netzwerkzone sitzen.
• End-to-End-Verschlüsselung ist standardmäßig aktiv. OpenZiti’s SDKs verwenden gegenseitiges TLS für die Verbindung, ergänzt durch libsodium-basierte Verschlüsselung des tatsächlichen Payloads — so bleiben die Daten auch bei einem kompromittierten Router in der Mitte unlesbar.
• Intelligentes Routing berechnet Pfade im Mesh neu, wenn sich Bedingungen ändern, sodass das Netzwerk um einen degradierten oder überlasteten Router herum routen kann, anstatt sich auf einen festen Hop zu verlassen. (Ein Hinweis: Einige Marketingmaterialien formulieren dies als “BGP übertrumpfen”, aber die eigene Dokumentation von OpenZiti macht diese Behauptung nicht — der Pfadauswahl-Algorithmus arbeitet auf der Overlay-Ebene, über der bestehenden Internet-Routing-Infrastruktur, nicht im Wettbewerb damit.)

Die Drei Deployment-Ebenen

Die Dokumentation von OpenZiti ist explizit, dass es kein einzelnes Tool mit einem einzigen Integrationspfad ist — es ist eine Plattform, die schrittweise übernommen wird, und es nennt direkt drei Ebenen:

1. Zero Trust Network Access. Ein Edge-Router von OpenZiti sitzt an der Grenze einer vertrauenswürdigen Netzwerkzone; authentifizierter Traffic tritt in das Overlay ein und verlässt es in das private Netzwerk, in dem Legacy-Services laufen. Keine Code-Änderungen, keine Anwendungsänderungen — dieses Modell ist für Organisationen gedacht, die Zero-Trust-Zugriff ohne Änderungen an der bestehenden Infrastruktur wollen.

2. Zero Trust Host Access (Tunnelers). Ein leichter OpenZiti-Tunneler läuft auf demselben Host wie der Zielservice — verfügbar für Linux, Windows, macOS, iOS und Android. Der Tunneler interceptiert und verschlüsselt den Traffic transparent; der Service selbst muss nur Verbindungen von localhost akzeptieren. Keine Code-Änderungen notwendig, aber die Vertrauensgrenze verschiebt sich auf das Host-Betriebssystem statt auf das gesamte Netzwerk.

3. Application Access (SDKs). Die stärkste Position, und worum es in diesem Artikel vor allem geht. Sie integrieren ein OpenZiti-SDK direkt in Ihren Client- oder Server-Code. Die Anwendung selbst hält die kryptografische Identität und verschlüsselt in-process — es gibt keinen hörenden Port, nicht einmal auf Loopback. Der Service ist “dark”: nichts zu scannen, nichts zu prüfen, weil nichts hört.

SDKs sind für sieben Sprachen verfügbar: Go, C, Python, Node.js, Java/Kotlin, Swift und C#/.NET (bestätigt direkt anhand der openziti/ziti und der SDK-Repos pro Sprache). Es gibt auch ein JavaScript-SDK für den Browser (Teil des “browZer”-Projekts), um Zero-Trust-Web-Apps ohne Client-Installation zu bedienen — eine Kategorie, die das CLI-First-Design der meisten Tunneling-Tools nicht wirklich abdeckt.

Die meisten Teams starten mit Tunneln für bestehende Dienste — es ist in Minuten einsatzbereit, ohne Code-Änderungen — und wechseln zu anwendungseingebetteten SDKs für neue, hochsichere oder Greenfield-Projekte, bei denen der zusätzliche Integrationsaufwand eine deutlich kleinere Angriffsfläche bietet.

zrok: Die Sharing-Schicht auf OpenZiti

Das manuelle Einrichten von Identitäten und Edge-Routern ist echte Infrastrukturarbeit, die für die meisten Entwickler zu viel Friktion bedeutet, nur um einen lokalen Server mit einem Teamkollegen zu teilen. zrok existiert, um diese Friktion zu entfernen — es ist ein Open-Source, “ziti-native” Peer-to-Peer-Sharing-Tool, das eine identitätsbasierte Overlay-Provisionierung nutzt, anstatt nur einen Cloud-Relay, und trotzdem das Ein-Befehl-Erlebnis “bekomme eine öffentliche URL” bietet, das Nutzer von dieser Kategorie erwarten.

Feature-Vergleich

Feature	Traditioneller Cloud-Proxy (z.B. ngrok)	zrok (OpenZiti-Overlay)
Kernarchitektur	Zentraler HTTP/TCP-Relay	Verteiltes, identitätsbasiertes Zero-Trust-Overlay
Lizenz	Proprietär, Closed-Source	Open-Source (Apache 2.0), vollständig selbst hostbar
Eingehende Ports	Bietet einen Endpunkt über einen öffentlichen Listener	Nur ausgehende Verbindungen; kein eingehender Port auf Ihrer Maschine
Ressourcen-Sharing	Hauptsächlich HTTP-Endpunkte	HTTP/TCP/UDP, plus integrierte Datei- und Laufwerksfreigabe sowie WebDAV-Netzlaufwerke
Kostenloses Kontingent	Variiert je nach Anbieter und Plan	5 GB/Tag Datenübertragung, bis zu 25 Umgebungen, 50 Share-Backends, 50 private Zugangsfrontends
Erstbesuch-Hindernis	Anti-Phishing-Interstitial bei unüberprüften Gratis-Konten	Gleiches — zrok zeigt eine äquivalente Interstitial bei unüberprüften Gratis-Konten, entfernbar durch Verifizierung mit Karte ohne Kosten

Der letzte Punkt ist erwähnenswert: zrok ist nicht frei von der Friktion, die manche nur mit ngrok assoziieren. Beide Tools zeigen eine Warnseite beim ersten Besuch, um Phishing-Angriffe auf temporäre Free-Tier-URLs zu verhindern.

Öffentliche URLs vs. Private Peer-to-Peer-Sharing

zrok unterstützt den bekannten Workflow mit öffentlicher URL — zrok share public http://localhost:3000 liefert eine HTTPS-URL wie https://your-share.share.zrok.io, nützlich für Tests eines Stripe- oder GitHub-Webhooks oder für Demo-Zwecke bei einem nicht-technischen Kunden.

Der Unterschied liegt im privaten Sharing, das niemals eine öffentliche URL oder DNS-Eintrag erstellt:

1. Der Host führt zrok share private http://localhost:8080 aus und erhält einen einzigartigen, temporären Zugriffstoken — keinen URL.
2. Dieses Token wird out-of-band, über einen Kanal, den Sie bereits vertrauen (verschlüsselter Chat, Secrets-Manager), verschickt.
3. Der Empfänger führt zrok access private <Token> auf seinem eigenen Rechner aus.
4. zrok startet einen lokalen Proxy auf der Empfängerseite (z.B. http://localhost:9090), der zum Service des Hosts durch das identitätsüberprüfte Overlay tunnelt.

Da kein öffentliches Frontend oder DNS-Eintrag für ein privates Sharing erstellt wird, gibt es wirklich nichts, was Scanner oder Bots finden könnten — die Verbindung besteht nur zwischen zwei authentifizierten Endpunkten.

zrok bietet auch ein eigenes SDK, das auf dem OpenZiti Go SDK aufbaut, für Teams, die Sharing direkt in ihre eigenen Tools integrieren wollen, anstatt nur die CLI zu verwenden:

// lade eine aktivierte zrok-Umgebung
root, err := environment.LoadRoot()

// fordere ein privates Sharing für eine lokale Ressource an
shr, err := sdk.CreateShare(root, &sdk.ShareRequest{
    BackendMode: sdk.TcpTunnelBackendMode,
    ShareMode:   sdk.PrivateShareMode,
})

// akzeptiere Verbindungen für diese Ressource
listener, err := sdk.NewListener(shr.Token, root)

zrok v2.0: Was hat sich wirklich geändert

zrok veröffentlichte 2026 eine große Version 2.0, und da viele bestehende Tutorials und Skripte noch auf v1-Syntax verweisen, ist es wichtig, genau zu wissen, was anders ist:

• Der Binärname ist jetzt zrok2, nicht zrok. Das war eine bewusste Entscheidung, um v1 und v2 nebeneinander laufen zu lassen, ohne sich gegenseitig zu stören, anstatt eine Migration zu erzwingen. v2 verwendet sein eigenes Environment-Verzeichnis (~/.zrok2 statt ~/.zrok), sein eigenes Environment-Variable-Prefix (ZROK2_* statt ZROK_* — z.B. ZROK2_API_ENDPOINT, ZROK2_ADMIN_TOKEN) und separate Linux-Pakete sowie systemd-Einheiten (zrok2, zrok2-agent, Konfigurationsdateien bei /etc/zrok2). Sie können zrok2 enable ausführen, um eine frische v2-Umgebung zu aktivieren, ohne eine bestehende v1-Installation zu berühren.
• Reserviertes Sharing wurde durch ein Namespace/Namensmodell ersetzt. Die alten Befehle zrok reserve / zrok release / zrok share reserved sind weg. Stattdessen verwalten zrok2 create share und zrok2 delete share sowohl öffentliche als auch private Shares, und zrok2 modify name -r kann eine ephemeral Share auf Wunsch dauerhaft machen — es ist nicht mehr notwendig, einen Share zu zerstören, nur um seinen Namen dauerhaft zu machen.
• VPN-Backend-Modus wurde entfernt. Frühere Versionen von zrok (und einige Tutorials, inklusive des Entwurfs, auf dem dieser Text basiert) erwähnten eine Option --backend-mode vpn für host-to-host VPN-ähnliches Sharing. Diese Funktion wurde in v2 entfernt, weil die zugrunde liegenden TUN-Geräte-Bibliotheken Konflikte in der Abhängigkeit erzeugten. Wenn ein Workflow darauf basierte, ist dieser Weg in v2 momentan nicht mehr verfügbar.

Installation und Erste Schritte

Unter macOS und Linux ist die aktuelle Homebrew-Formel für die v2-Reihe:

brew install zrok2

(Das ursprüngliche v1-Paket zrok existiert weiterhin separat und funktioniert, falls benötigt.) Für Windows ist der zuverlässigste Weg, die aktuelle Version direkt von der zrok GitHub-Releases-Seite zu holen — eine offizielle, gepflegte Scoop-Quelle für die v2-Binärdatei konnten wir zum Zeitpunkt des Schreibens nicht verifizieren, daher verweisen wir auf die Releases-Seite.

Nach der Installation:

zrok2 invite      # registriert für den kostenlosen zrok.io-Service (kein separates Invite-Token erforderlich)
zrok2 enable       # bindet Ihr Gerät an Ihre zrok-Umgebung
zrok2 share public localhost:3000

Für Teams, die volle Datenhoheit benötigen — regulierte Umgebungen mit HIPAA, GDPR oder SOC 2 — ist zrok vollständig selbst hostbar. Der Self-Hosting-Docker-Compose-Stack ist mehr als nur ein Container: Er umfasst einen ziti-controller und ziti-router für das OpenZiti-Control/Data-Plane, postgresql für die zrok-Datenbank, rabbitmq für Frontend-Mapping-Updates, zrok2-controller und zrok2-frontend für die zrok-API und den öffentlichen Share-Proxy, sowie optional caddy (TLS-Termination) und influxdb-basierte Metrikdienste. Das ist deutlich mehr Infrastruktur als nur eine Binärdatei — das sollte man bei der Planung einer Self-Hosting-Deployment wissen.

Anwendungsbeispiele in der Praxis

Webhook-Automatisierung ohne eingehende Firewall-Regeln

Mit dem OpenZiti Node.js SDK haben Teams GitHub Actions-Workflows gebaut, bei denen eine CI/CD-Pipeline einen Build- oder Deployment-Script auf einem internen Server sicher auslösen kann — ohne dass das Netzwerkteam eine eingehende Portöffnung oder NAT-Regeln verwalten muss.

Peer-to-Peer-Datei- und Laufwerksfreigabe

Da zrok das “Wer hat die Adresse”-Problem genauso löst wie die Service-Sharing-Funktion, eignet es sich perfekt für ad-hoc-Dateifreigaben und das Mounten gemeinsamer Ordner als WebDAV-Netzlaufwerke direkt über das Overlay, ohne einen dedizierten Fileserver aufzubauen.

Zero-Trust-Infrastruktur für KI-Agenten und MCP

Dies ist der Bereich des Ökosystems, der am schnellsten voranschreitet, und wo viele ältere Beschreibungen (inklusive früherer Entwürfe dieses Blogs) bereits veraltet sind. Stand Mitte bis Ende 2026 hat NetFoundry eine kleine Cluster speziell entwickelter, Apache 2.0-lizenzierter Projekte hier gesponsert — und es ist wichtig, genau zu wissen, was jedes einzelne tatsächlich macht, weil ihre Anwendungsbereiche sich in übersichtlicher Weise überschneiden:

openziti/llm-gateway ist ein OpenAI-kompatibler API-Proxy. Seine eigene Dokumentation beschreibt native Routing-Fähigkeiten für OpenAI, Anthropic und beliebige OpenAI-kompatible Backends — Ollama, vLLM, llama-server, SGLang und ähnliche selbstgehostete Inferenz-Server. (Hier eine Korrektur: Frühere Berichte, inklusive einer früheren Version dieses Artikels, beschrieben es als native Unterstützung für AWS Bedrock und Google Vertex AI. Das eigene Repository des Projekts nennt nur native Unterstützung für OpenAI und Anthropic sowie beliebige OpenAI-kompatible Backends — keine ersten Partner-Integrationen für Bedrock, Vertex oder Azure OpenAI.) Es nutzt eine semantische Routing-Logik in einer Drei-Schichten-Kaskade — Schlüsselwortheuristiken, dann Embedding-Ähnlichkeit, dann einen LLM-Klassifikator als Fallback — um automatisch ein Modell auszuwählen, wenn ein Client keins angibt, plus gewichtetes Round-Robin-Load-Balancing mit Gesundheitschecks über eine Pool-Inferenz-Server. Es ist eine einzelne Go-Binärdatei ohne Datenbank oder Message-Queue, die optional über zrok erreichbar ist, damit ein Gateway hinter NAT oder in einem luftdichten Netzwerk erreichbar bleibt, ohne einen Port zu öffnen.

openziti/mcp-gateway ermöglicht KI-Assistenten Zero-Trust-Zugriff auf MCP-Tool-Server. Es besteht aus drei Komponenten (das Projekt nennt das “Trifecta”): mcp-tools verbindet einen MCP-Client mit einem entfernten zrok-Share oder einem Agora-Tunnel; mcp-gateway fasst mehrere Tool-Server-Backends zu einer Namespaced-Verbindung zusammen (damit erscheinen Tools von einem Dateisystem-Server und einem GitHub-Server als fs:read_file und github:create_issue auf derselben Endpunkt), und mcp-bridge exponiert einen einzelnen lokalen MCP-Server im Netzwerk. Backends können lokale stdio-Prozesse oder entfernte HTTP(S)/SSE MCP-Server sein, Shares können jetzt persistent sein (damit ein Gateway neu starten kann, ohne dass sich das Share-Token ändert), und es unterstützt sowohl stdio- als auch Streamable HTTP-Transport für Clients, die einen reinen HTTP-Endpunkt benötigen.

ziti-mcp-server ist ein anderes Projekt als mcp-gateway, trotz ähnlichem Namen — es kapselt die OpenZiti Management API selbst, und stellt rund 200 Tools bereit, die Identitäten, Dienste, Edge-Router und Policies als MCP-Tools abdecken. Das ist das Element, das einem Agenten in Claude Desktop, Cursor oder einem ähnlichen Client ermöglicht, Router konfiguriert und Netzwerk-Policies dialogbasiert verwaltet, anstatt andere MCP-Server zu aggregieren, wie es mcp-gateway tut.

openziti/agora ist die neueste Ergänzung in diesem Stack und war vor einigen Monaten noch nicht Teil des Bildes: ein separates, vor-1.0 Zero-Trust-Overlay, speziell für Agent-zu-Agent-Kommunikation, kompatibel mit dem A2A-Protokoll auf der Übertragungsebene, ergänzt durch OpenZiti’s Identitäts-, Discovery- und Policy-Schicht. mcp-gateway integriert es bereits als alternatives Transportmedium zu zrok, sodass ein Gateway Tools über Agora’s “Layer 1”-Tunnels bereitstellen und sich in einem Agora-Katalog für die Entdeckung veröffentlichen kann.

Was alle vier verbindet, ist das gleiche Argument, das dieser Artikel über Tunneling macht: Ein MCP-Endpunkt oder ein Inferenz-Gateway kann auf die gleiche Weise wie ein privater HTTP-Backend geteilt werden — authentifiziert, verschlüsselt, und ohne öffentlich hörenden Port, den Scanner finden könnten.

Das Fazit

Der Komfort, einen einzigen Befehl zu tippen und eine öffentliche URL zu erhalten, verschwindet nicht, und für einen großen Teil der täglichen Entwicklungsarbeit ist es immer noch das richtige Werkzeug. Aber “Komfort” und “offen im Internet” müssen kein Kompromiss sein. Das layered Modell von OpenZiti — Netzwerkzugang ohne Code-Änderungen, Host-Level-Tunneling ohne Code-Änderungen oder anwendungseingebettete SDKs für die stärkste Position — erlaubt es Teams, individuell zu entscheiden, wie viel sie von diesem Kompromiss wirklich eingehen wollen, serviceabhängig, anstatt eine Standardlösung für alles zu akzeptieren. zrok ist die Einstiegshürde, die die ersten beiden Ebenen in Minuten zugänglich macht; die SDKs sind für die Dienste gedacht, bei denen “dark by default” den zusätzlichen Integrationsaufwand rechtfertigt.

---

Changelog

Korrekturen: - Die vage Aussage “die kürzliche große Version 2.0 von zrok führte den zrok2-Binärdatei ein” wurde durch die tatsächlichen, belegten Änderungen in Version 2.0 ersetzt: Umbenennung des zrok2-Binärs/Umgebung/Umgebungsvariablen (~/.zrok2, ZROK2_*), das Namespace/Namensmodell anstelle reservierter Shares, und — der eigentliche Grund für die Aussage im Entwurf über “entfernte Legacy-VPN-Backend-Modi” — dass der VPN-Backend-Modus speziell wegen TUN-Geräte-Bibliotheksabhängigkeitskonflikten entfernt wurde, nicht nur, um auf Zero-Trust-Routing zu setzen. - Die Unterstützung für openziti/llm-gateway wurde korrigiert. Der Entwurf (und ein früherer Blogbeitrag) behauptete native Unterstützung für Anthropic, AWS Bedrock und Google Vertex AI. Das eigene Repository beschreibt native Unterstützung nur für OpenAI und Anthropic plus beliebige OpenAI-kompatible Backends — keine ersten Partner-Integrationen für Bedrock, Vertex oder Azure OpenAI. - Die Beschreibung von mcp-gateway wurde korrigiert und deutlich erweitert. Der Entwurf vermischte mcp-gateway und ziti-mcp-server in eine ungeordnete Fähigkeit. Sie sind separate Projekte: mcp-gateway besteht jetzt aus drei Komponenten (mcp-tools, mcp-gateway, mcp-bridge — die “Trifecta”), die MCP-Tool-Server aggregieren und exponieren, während ziti-mcp-server die rund 200-Tool-API selbst kapselt. - Die unbestätigte Behauptung, OpenZiti’s Smart Routing “umgeht Standard-BGP-Routing-Protokolle”, wurde abgeschwächt. Es gibt keine primäre Quelle, die diese spezielle Formulierung bestätigt; stattdessen wurde eine Beschreibung der Overlay-Ebene der Pfad-Neuberechnung eingefügt, die nicht zu hochmütig ist. - Die Windows-Anweisung scoop install zrok wurde durch einen Hinweis ersetzt, dass wir keinen gepflegten offiziellen Scoop-Bucket für die v2-Binärdatei verifizieren konnten, und stattdessen auf die GitHub-Releases-Seite verwiesen.

Hinzugefügt: - Die spezifischen, belegten Bezeichnungen, die OpenZiti in der eigenen Dokumentation für seine drei Deployment-Ebenen verwendet (Zero Trust Network Access / Zero Trust Host Access / Application Access), wurden anstelle der generischen “Netzwerkzugang / Hostzugang / Anwendungszugang”-Formulierung übernommen. - Ein neuer Abschnitt zu openziti/agora, einem separaten, vor-1.0 Zero-Trust-Overlay für Agent-zu-Agent-Kommunikation, das mcp-gateway jetzt als alternatives Transportmittel nutzen kann — nicht im ursprünglichen Entwurf erwähnt, und zum Zeitpunkt einer früheren Version dieses Artikels noch nicht live. - Persistente Shares und Streamable HTTP-Transport in mcp-gateway, beide nach den letzten Releases hinzugefügt. - Ein echtes, belegtes Code-Beispiel für das private Share-Muster des zrok Go SDK, das die reine Textbeschreibung im Entwurf ersetzt. - Eine konkrete Aufschlüsselung der Self-Hosting-Docker-Compose-Services (ziti-controller, ziti-router, postgresql, rabbitmq, zrok2-controller, zrok2-frontend, optional caddy/influxdb) anstelle der vagen Erwähnung “umfassende Dokumentation”. - Bestätigte und korrekte Zahlen aus dem Entwurf: zrok SDK-Sprachliste (Go, C, Python, Node.js, Java, Swift, C# — sieben Sprachen, bestätigt anhand openziti/ziti und der jeweiligen Repos), die libsodium/mTLS-Verschlüsselung, und die Limits des Managed-Free-Tiers (5 GB/Tag, 25 Umgebungen, 50 Share-Backends, 50 private Frontends), alle direkt geprüft anhand der aktuellen Projektquellen.

Entfernt: - Wiederholte keyword-gefüllte Phrasen (“erstklassige Open-Source-ngrok-Alternative für Zero Trust”, mehrfach als feste Phrase verwendet) zugunsten einer klaren, nicht-repetitiven Sprache, die mit früheren Artikeln auf diesem Blog konsistent ist.

Quellen geprüft: openziti/ziti GitHub-Repo und README; openziti/zrok GitHub-Repo, CHANGELOG und Release Notes (v2.0.0 und Release Candidates); OpenZiti Tech Blog (“Introducing zrok v2.0”, “Announcing the zrok Public Beta”); NetFoundry-Dokumentation (openziti.io, netfoundry.io/docs — OpenZiti-Übersicht, zrok-Migrationsleitfaden, zrok-Service-Limits); zrok-Preisseite (zrok.io/pricing); SDK-Repos pro Sprache (sdk-golang, ziti-sdk-c, ziti-sdk-py, ziti-sdk-jvm, ziti-sdk-swift, ziti-sdk-csharp, ziti-sdk-nodejs); openziti/llm-gateway, openziti/mcp-gateway (pkg.go.dev, v0.1.11), und openziti/agora GitHub-Repos; sowie der eigene, vorher überprüfte Blog-Artikel zu ngrok vs. zrok (instatunnel.substack.com, Juli 2026).