Pinggy vs localhost.run: Der Vergleich der Zero-Install SSH-Tunnel

Die meisten Tools für localhost-Tunneling — ngrok, LocalXpose, Localtonet — fordern zunächst den Download eines Binärdatei. Auf einem stark eingeschränkten Firmen-Laptop endet die Sache oft hier: EDR-Agents markieren nicht signierte Executables, und IT-Richtlinien blockieren Installationen komplett.

Es gibt eine Umgehung, die keinen Paketmanager berührt: reines ssh -R. Jeder moderne OS bringt einen SSH-Client mit, und einige Dienste — Pinggy und localhost.run vor allem — bieten öffentliche Tunneling-Endpunkte, die nur standardmäßiges SSH-Remote-Port-Forwarding sprechen. Kein Client-Install, kein Konto nötig für Grundfunktionen, nur ein Zeilenbefehl im bereits geöffneten Terminal.

Pinggy und localhost.run setzen diese Idee unterschiedlich um: Der eine bietet eine umfangreiche Feature-Palette, der andere bleibt bewusst minimalistisch. Hier ein Vergleich basierend auf der aktuellen Dokumentation der Anbieter.

Pinggy: SSH-Tunneling mit Debugger

Der Grundbefehl:

ssh -p 443 -R0:localhost:3000 a.pinggy.io

Allein ausgeführt, öffnet er eine interaktive Terminal-UI, die die öffentliche URL des Tunnels, Live-Statistiken und einen QR-Code für mobiles Testen anzeigt. Das ist das komplette Zero-Install-Erlebnis — nützlich, aber kein Request-Inspector an sich.

Der Web-Debugger ist optional, nicht automatisch aktiviert. Für Header/Payload-Inspektion, Request-Replay und ein Browser-Dashboard muss man den Debugger-Port explizit weiterleiten:

ssh -p 443 -R0:localhost:3000 -L4300:localhost:4300 a.pinggy.io

Das -L4300:localhost:4300-Flag leitet den Web-Debugger von Pinggy an http://localhost:4300 auf deinem Rechner, wo du Live-Anfragen inspizieren, zwischen Request/Response wechseln und Anfragen vor dem erneuten Senden modifizieren kannst. Funktioniert ohne Anmeldung, kein zusätzlicher Download nötig — aber nur, wenn du das Flag setzt. Ohne das Flag liefert der einfache SSH-Befehl nur die lighter Terminal-UI (URL, Stats, QR-Code). (Pinggy bietet auch eine separate offizielle Node.js CLI, npm install -g pinggy, die echtes Request-Inspektion im Terminal ermöglicht — aber die Installation eines npm-Pakets bedeutet, dass du den Zero-Install-Weg verlässt.)

Was die kostenlose Version tatsächlich umfasst:

• HTTP(S), TCP, TLS und UDP Tunnels — UDP ist nicht nur für Pro
• Unbegrenzte Bandbreite — gilt auch in der Free-Variante, nicht nur bei Bezahlversionen
• Keine Anmeldung für einen Basis-Tunnel
• Eine harte 60-Minuten-Session, danach schließt der Tunnel und es wird eine neue zufällige URL generiert

Was Pro hinzufügt (derzeit $2,50–$3/Monat, bei Jahresabrechnung günstiger): Wegfall der 60-Minuten-Grenze, persistent/benutzerdefinierte Subdomains, eigene Domains (inkl. Root-Domains), Wildcard-Domains, Team-Management und Remote-Tunnel-Verwaltung via Dashboard. Eine 7-tägige Testphase ohne Kreditkarte ist verfügbar.

AI-Agent-Integration ist real und ziemlich tief: Pinggy veröffentlicht einen MCP-Server, der MCP-kompatible Agents — Claude Code, Cursor, VS Code, Windsurf — starten, stoppen, inspizieren und Tunnels verwalten lässt, alles per natürliche Sprache statt Copy-Paste. Es gibt auch einen eigenständigen Agent Skill (npx skills add https://pinggy.io), der einem Agenten CLI-Syntax und Flags ohne Live-Tunnelsteuerung gibt. Wichtig: Tunnels, die so gestartet werden, laufen im MCP-Serverprozess, ein Neustart des Hosts (Claude Code, Desktop) beendet alle geöffneten Tunnels — es gibt keinen Hintergrund-Daemon.

Pinggy läuft auch als Docker-Image (pinggy/pinggy), was die einzige Möglichkeit ist, UDP-Tunnels ohne einen reinen SSH-Client zu nutzen.

localhost.run: minimalistisch by Design

Der Grundbefehl:

ssh -R 80:localhost:3000 nokey@localhost.run

Das war’s — keine Flags, kein Dashboard. Innerhalb von Sekunden erhält man eine stabile URL wie lhr.life oder lhr.rocks mit automatisch ausgestelltem TLS-Zertifikat. Es gibt keinen eingebauten Request-Inspector; du bringst deinen eigenen mit (oder beobachtest einfach die Logs deiner App).

Limitierungen in der Free-Variante sind bewusst so gesetzt: localhost.run limitiert und rotiert die Domains, um Phishing-Seiten auf lhr.life-Subdomains zu verhindern — der Anbieter macht das explizit in der Dokumentation. Wenn du einen SSH-Key zu einem (kostenlosen) Konto hinzufügst, bleibt die Domain zwischen Reconnects gleich, ist aber nicht sofort und dauerhaft. Standardmäßig ist sie es nicht.

Eigene Domains kosten mehr als in älteren Vergleichen angegeben: Ein Custom Domain-Abonnement kostet $9/Monat bei Jahresabrechnung — nicht die oft genannte $3,50/Monat. Diese $9 sichern dir eine stabile Domain (eigene oder ein fester lhr.rocks-Subdomain), automatisches TLS und eine Prioritätsbandbreite, die nicht durch die Limits der Free-Variante eingeschränkt ist.

Derzeit gibt es keine öffentlich dokumentierte AI-Agent- oder MCP-Integration bei localhost.run.

Gegenüberstellung

Feature	Pinggy	localhost.run
Hauptfokus	Feature-reiches Tunneling mit Request-Inspektion	Minimal, schnell, ohne Konfiguration
Grundbefehl	ssh -p 443 -R0:localhost:3000 a.pinggy.io	ssh -R 80:localhost:3000 nokey@localhost.run
Request-Inspektion	Web Debugger (optional mit -L4300:localhost:4300), oder separates npm CLI	Keine integrierte Lösung
Protokoll-Unterstützung	HTTP(S), TCP, TLS, UDP	HTTP(S), TCP; TLS passt durch auf Port 443
Dokumentierter firewall-freundlicher Port	443 (explizit unterstützt)	Standardport 22 in dokumentierten Befehlen
Bandbreite in Free-Variante	Unbegrenzt	Rate-begrenzt (Missbrauchsschutz)
Sitzungsdauer in Free-Variante	60 Minuten	Domain rotiert periodisch; kein fest dokumentierter Zeitlimit
Eigene Domains	Nur Pro, ab ~$2,50–$3/Monat	$9/Monat (bei Jahresabrechnung)
AI-Agenten / MCP	Ja — MCP-Server + Agent Skill	Keine bekannte Unterstützung
Docker-Unterstützung	Ja, offizielle Image	Nicht dokumentiert

Fazit: Wenn du Header inspizieren, Webhook-Payloads replayen, UDP-Traffic für einen Spieleserver tunneln oder die Steuerung an einen Coding-Agenten abgeben willst, rechtfertigt Pinggy mit seinen Features die etwas höhere Komplexität. Wenn du nur eine lokale App auf einer öffentlichen URL für zwei Minuten brauchst, ohne Konfiguration, ist localhost.run mit seinem Einzeiler kaum zu schlagen — rechne aber bei Bedarf mit $9/Monat für eine stabile eigene Domain.

SSH-Tunnels verantwortungsvoll gegen Firmenfirewalls nutzen

Der Grund für diese Kategorie: Eine outbound SSH-Verbindung zu a.pinggy.io:443 ist auf Paketebene nicht von normalem HTTPS zu unterscheiden. Die meisten Firmenfirewalls und DPI-Geräte, die Executables oder nicht-standardisierte Ports blockieren, lassen es durch, weil es nur SSH auf dem üblichen Port ist.

localhost.run nutzt standardmäßig Port 22, der in vielen Firmennetzwerken outbound blockiert ist — daher hat es nicht die gleiche Firewall-Umgehungsstrategie wie Pinggy mit Port 443, auch wenn die SSH-über-443-Technik grundsätzlich funktionieren würde.

Hier einige Hinweise, wenn du den Dienst im Firmen-Netzwerk nutzt:

• Prüfe zuerst die Firmenpolitik. Das Umgehen von Netzwerksperren ist nicht automatisch erlaubt.
• Teile keine sensiblen Daten. Sobald der Reverse-Tunnel aktiv ist, ist der lokale Dienst öffentlich erreichbar, solange der Tunnel offen ist.
• Nutze vorhandene Zugriffskontrollen. Beide Dienste unterstützen mindestens HTTP Basic Auth; Pinggy unterstützt zusätzlich Bearer-Token-Authentifizierung und IP-Whitelisting.
• Schließe Tunnels nach Gebrauch. Nicht über Nacht offen lassen.

Aus IT-Sicht ist dieses Muster genau der Grund, warum Netzwerkteams von “Blockiere bekannte Binärdateien” zu verhaltensbasiertem Monitoring und Zero Trust Network Access gewechselt haben — das Blockieren eines Dateinamens stoppt keine Technik, die nur einen vorinstallierten SSH-Client braucht.

Wo Zero-Install Tunnels tatsächlich genutzt werden

• IoT-Geräte hinter CGNAT oder Mobilfunk-NAT — ein Raspberry Pi kann beim Boot einen outbound Reverse-Tunnel öffnen, um den lokalen SSH-Daemon für Remote-Management zugänglich zu machen, ohne Firewall-Regeln zu berühren.
• Webhook-Entwicklung — Stripe, Twilio und GitHub benötigen eine öffentliche URL für Event-Delivery; ein einfacher SSH-Befehl ist schneller als Deployment auf Staging.
• Mobile Geräte-Tests — ein physisches iOS- oder Android-Gerät an eine lokale API anzuschließen, ist einfacher über eine öffentliche URL als über lokale IP-Routing.
• Schnelle Demo für Kunden — in-progress-Arbeiten teilen, ohne halbfertigen Code irgendwo zu deployen.

Fazit

Beide Dienste wollen nicht ngrok oder Cloudflare Tunnel komplett ersetzen — sie lösen ein spezielleres Problem: eine öffentliche URL aus einer eingeschränkten Maschine zu holen, nur mit dem bereits vorhandenen SSH-Client. Pinggy setzt auf UDP, einen echten (wenn auch optionalen) Debugger und einen MCP-Server für Agenten-Workflows. localhost.run bleibt bei der ursprünglichen Idee: Ein Befehl, eine URL, keine Konfiguration. Welche Lösung du wählst, hängt davon ab, ob du den Datenfluss inspizieren willst oder nur eine existierende URL brauchst.

---

Changelog

1. Überarbeitete Artefakte wie Python-Print-Statements, file-tag Marker und andere Skript-Reste aus dem Quell-Entwurf; als sauberes Markdown ohne Frontmatter geliefert.
2. Titel und Abschnittsüberschriften angepasst, um den Hausstil zu treffen — keine revolutionären Formulierungen, neutrale Sprache.
3. Korrektur der Preisangabe für localhost.run Custom Domains: Der Entwurf nannte $3,50/Monat. Laut aktueller Dokumentation (localhost.run/docs/custom-domains/) sind es $9/Monat bei Jahresabrechnung. Das ist eine wesentliche Änderung und die wichtigste Korrektur in diesem Durchlauf.
4. Korrektur zum Web Debugger: Der Entwurf suggerierte, dass der reine Pinggy SSH-Befehl automatisch eine Web-Debugging-Oberfläche weiterleitet. Laut Pinggy-Dokumentation erfordert das explizit das Hinzufügen von -L4300:localhost:4300. Ohne dieses Flag liefert der Zero-Install-Path nur die leichtere Terminal-UI (URL, Stats, QR-Code), nicht Header/Payload-Inspektion oder Replay. Ein Hinweis auf Pinggy’s separates npm CLI wurde ergänzt, da dies die tatsächliche in-terminal Inspektionsmöglichkeit ist, mit der Einschränkung, dass die Installation das Zero-Install-Property aufgibt.
5. Korrektur zu “Unbegrenzte Bandbreite (bezahlt)”: Die unbegrenzte Bandbreite gilt auch in Pinggy’s Free-Plan. Was Pro tatsächlich einschränkt, ist die Tunnel-Persistenz (keine 60-Minuten-Grenze), persistent/benutzerdefinierte Subdomains und Domains — nicht die Bandbreite.
6. Bestätigung, dass UDP-Tunnel auf Pinggy’s Free-Plan unterstützt werden, nicht nur Pro, basierend auf aktuellen Dokumenten und Drittanbieter-Preisschätzungen.
7. Hinzugefügt und verifiziert: Pinggy’s MCP-Server und Agent Skill (unterstützte Hosts: Claude Code, Cursor, VS Code, Windsurf), inklusive Hinweis, dass Tunnels im MCP-Serverprozess laufen und bei Host-Neustart beendet werden. Für localhost.run keine bekannte AI-Agent-Integration.
8. Hinweis auf Firewall-Umgehung: Pinggy dokumentiert explizit die Nutzung von Port 443; localhost.run’s Befehle defaulten auf Port 22, der in restriktiven Firmennetzwerken eher blockiert wird.
9. Vergleichstabelle neu aufgebaut (die ursprüngliche Tabelle war unleserlich); Zeilen für dokumentierten Port, Docker-Unterstützung und Bandbreiten-/Sitzungs-Verhalten ergänzt.
10. Docker-Hinweis für Pinggy: offizielles pinggy/pinggy-Image, der einzige Weg, UDP-Tunnels ohne reinen SSH-Client zu nutzen.
11. Kontext-Hinweis: Das Thema überschneidet sich mit zwei bestehenden Blogartikeln — “Letting AI Drive: Exposing Localhost via MCP Servers” und “Ditch the Web Dashboard: Debugging Webhooks Entirely in the Terminal” — beide bestätigen die Korrektur zum Web Debugger (Punkt 4). Ein Cross-Link ist sinnvoll, da die Debugger-Nuance bereits etabliert ist.