ngrok vs. sish (Das selbstgehostete Serveo): So bauen Sie Ihren eigenen privaten ngrok mit sish und einem $5 VPS

In der modernen Softwareentwicklung ist das öffentliche Zugänglichmachen Ihrer lokalen Entwicklungsumgebung im Internet eine tägliche Notwendigkeit. Ob Sie Webhooks testen, eine laufende Arbeit einem Kunden präsentieren oder eine komplexe API-Integration debuggen – Sie benötigen einen zuverlässigen Tunnel. Seit Jahren greifen Entwickler auf Drittanbieter-Tools wie ngrok oder Serveo zurück. Mit wachsendem Team und steigenden Sicherheitsanforderungen können jedoch Managed-Tunneling-Dienste Engpässe, Kosten und Sicherheitsprobleme verursachen.

Wenn Sie sich jemals über ngrok’s kostenlose Begrenzungen, Ratenbegrenzungen oder die unvorhersehbare Verfügbarkeit kostenloser Alternativen wie Serveo geärgert haben, ist es vielleicht Zeit, Ihre Infrastruktur selbst in die Hand zu nehmen. Hier kommt sish ins Spiel – ein Open-Source-Projekt, das aktiv gepflegt wird und es Ihnen ermöglicht, Ihre eigene private Version von localhost.run oder Serveo zu erstellen – oder, seit diesem Jahr, den offiziellen Managed-Service zu nutzen, anstatt alles selbst zu hosten.

In diesem Leitfaden durchlaufen wir den aktuellen Stand des SSH-Tunnelings, vergleichen ngrok und sish anhand der jeweiligen Dokumentation und geben eine Schritt-für-Schritt-Anleitung, um Ihren eigenen privaten ngrok mit sish und einem $5 VPS aufzubauen.

---

Die Entwicklung des Localhost-Tunnelings

Die Herrschaft von ngrok

Wenn Entwickler an localhost-Tunneling denken, ist ngrok meist der erste Name, der fällt. Es revolutionierte die Art und Weise, wie lokale Server exponiert werden. Mit einem einfachen Befehl (ngrok http 8080) erhalten Sie sofort eine öffentliche HTTPS-URL, die den Traffic an Ihre lokale Maschine weiterleitet.

Der kostenlose Tarif von ngrok ist tatsächlich limitiert, aber nicht so, wie es die meisten Vergleichsartikel beschreiben. Laut ngrok’s aktueller Preis- und Begrenzungsdokumentation umfasst der kostenlose Plan:

• Ein einmaliges Nutzungskredit von $5
• Bis zu 3 Online-Endpunkte und 3 gleichzeitige Agenten
• 1 GB Datenübertragung pro Monat
• 20.000 HTTP/S-Anfragen pro Monat, etwa 4.000 Anfragen/Minute
• 5.000 TCP/TLS-Verbindungen pro Monat
• Einen automatisch zugewiesenen “Dev-Domain” (z.B. dein-name.ngrok-free.app)
• Eine Warnseite für Browserbesucher bei kostenlosen HTTP/S-Endpunkten (umgehbar durch Senden eines ngrok-skip-browser-warning Headers oder eines nicht-standardmäßigen User-Agent — kein Upgrade erforderlich)

Ein häufiges Missverständnis: Viele “ngrok-Alternativen”-Blogs behaupten, dass die kostenlose Version jetzt eine harte 2-Stunden-Sitzungszeitüberschreitung erzwingt. Die offizielle ngrok-Dokumentation widerspricht dem direkt – kostenlose Endpunkte haben keine Timeout und können unbegrenzt im Hintergrund laufen. Die tatsächlichen Beschränkungen sind die monatlichen Daten-, Anfrage- und Verbindungsgrenzen sowie die Nichtverfügbarkeit eines benutzerdefinierten Domains und die Warnseite. Skeptisch sein bei Artikeln, die eine “2-Stunden-Grenze” angeben.

Die bezahlten Tarife wurden ebenfalls umstrukturiert. Das aktuelle Angebot (laut ngrok’s Preis- und Begrenzungsseiten) ist:

Plan	Preis	Datenübertragung	Anfragen	Endpunkte
Kostenlos	$0	1 GB/Monat	20.000/Monat	3
Hobbyist	$8/Monat (Jahresabo) oder $10/Monat	5 GB/Monat	100.000/Monat	3
Bezahle nach Nutzung	$20/Monat Grundpreis (inkl. $20 Nutzungskredit)	Abgerechnet nach Verbrauch ($0,10/GB)	Abgerechnet nach Verbrauch ($1/100k)	Unbegrenzt
Enterprise	Individuell / Angebot	Individuell	Individuell	Individuell

Neben den Kosten beschränken einige Firmennetze auch ngrok-Verkehr standardmäßig, da seine geteilten Domains in der Vergangenheit für Phishing und Malware-Kommandos und -Kontrolle missbraucht wurden – ein Sicherheitsproblem unabhängig von den Preisen.

Der Aufstieg und Fall von Serveo

Als Alternative zum proprietären ngrok-Agenten strömten Entwickler zu Serveo. Serveo war bemerkenswert, weil keine Installation erforderlich war – es nutzte den standardmäßigen SSH-Client, der auf fast jedem Entwicklerrechner installiert ist. Mit ssh -R 80:localhost:8080 serveo.net wurde sofort eine öffentliche URL zurückgegeben.

Serveo wurde zum Favoriten für kostenloses SSH-Tunneling, doch seine offene, unautorisierte Natur machte es zum Magnet für Phishing und Malware-Missbrauch. Das führte zu Blacklisting und Ausfällen. Die Verfügbarkeit von Serveo ist heute noch inkonsistent – Drittanbieter-Monitoring zeigt, dass es je nach Region und Zeit zwischen “online” und “offline” schwankt, was auf einen wenig gepflegten kostenlosen Dienst hindeutet. Es ist noch intermittierend erreichbar, aber kein zuverlässiger Dienst für produktionsnahe Anwendungen.

Einführung von sish: Der Open-Source-Nachfolger

sish, entwickelt von Antonio Mika, ist die Antwort der Open-Source-Community auf die Lücke, die Serveo hinterlassen hat. Es ist ein aktiv gepflegtes Projekt – aktuell in Version v2.23.0 (Juni 2026), mit etwa 4.600 GitHub-Sternen, 329 Forks und 64 Versionen – und wird jetzt von pico.sh gesponsert, dem Projekt für SSH-basierte Entwickler-Tools, das Mika ebenfalls pflegt.

Im Gegensatz zu Serveo, das nur als öffentlicher Dienst existierte, ist sish explizit dafür konzipiert, auf Ihrer eigenen Infrastruktur selbst gehostet zu werden. Es läuft als SSH-Server, der den Traffic an die verbundenen Clients weiterleitet.

Ein wichtiger Update seit den frühen Tagen von sish: Sie müssen es nicht mehr selbst hosten, wenn Sie das nicht möchten. Das Projekt bietet jetzt einen offiziellen Managed-Service bei tuns.sh an, betrieben vom selben Team, als schnellste Möglichkeit, sish ohne VPS zu testen:

ssh -R 80:localhost:8080 tuns.sh

Dies erstellt sofort eine öffentliche URL für eine Anwendung, die auf Port 8080 läuft – ohne Anmeldung, ohne Client-Installation. Selbsthosting bleibt die bessere Option für Teams, die benutzerdefinierte Domains, private Tunnel oder vollständige Kontrolle über Datenresidenz benötigen, was im restlichen Leitfaden behandelt wird.

Das Superpower von sish

Was macht sish in der Vielzahl der Tunneling-Tools besonders?

1. Protokollunterstützung: sish unterstützt HTTP, HTTPS, TCP, WS (WebSockets) und WSS, sowie SNI-basiertes TLS-Routing, ohne die TLS-Verbindung selbst zu terminieren.
2. Kein Client-Install erforderlich: Genau wie Serveo nutzt sish den nativen SSH-Client (ssh -R). Ihr Team braucht keine proprietären CLI-Tools oder Agents.
3. TLS-Zertifikate: sish kann HTTPS entweder mit eigenen Zertifikaten bereitstellen oder auf Anfrage Zertifikate von Let’s Encrypt (--https-ondemand-certificate) anfordern. Bei der offiziellen Docker-Compose-Deployment ist auch vollautomatisierte Wildcard-Zertifizierung via DNS-01-Challenges mit dem integrierten dnsrobocert-Container möglich.
4. Multiplexing: sish unterstützt Wildcard-Subdomains, sodass mehrere Entwickler ihre eigenen Subdomains on-the-fly anfordern können (z.B. dev1.ihredomain.com, api-test.ihredomain.com).
5. Sicherheit und Authentifizierung, standardmäßig aktiviert: Seit der aktuellen Version erfordert sish SSH-Authentifizierung (öffentlicher Schlüssel oder Passwort) – es ist kein “offen, später sichern”-Tool mehr. Sie konfigurieren, wer Zugriff hat, bevor jemand einen Tunnel öffnet.
6. Private TCP-Aliases und Lastverteilung: Über öffentliche Tunnel hinaus unterstützt sish interne TCP-Aliases (nur über authentifizierten SSH-Jump-Host erreichbar) sowie optionale Load-Balancing-Modi, damit mehrere Clients denselben HTTP-, TCP- oder SNI-Endpunkt teilen können.
7. Traffic-Inspektion: Ein optionales Admin-Console und Service-Console für jeden Tunnel erlauben die Überwachung der weitergeleiteten Anfragen – eine Lücke zu ngrok’s Traffic-Inspector, ohne den Traffic durch Dritte zu schicken.

---

ngrok vs. sish: Welches ist das Richtige für Sie?

Feature	ngrok (SaaS)	sish (Selbstgehostet oder Managed)
Architektur	Managed-Dienst eines Drittanbieters	Selbstgehostet auf Ihrer Infrastruktur oder Nutzung des offiziellen tuns.sh-Services
Client-Software	Benötigt den ngrok-CLI-Agent	Nutzt native SSH (ssh-Befehl)
Benutzerdefinierte Domains	Ab Hobbyist-Plan oder höher	Kostenlos bei Selbsthosting; eigene Domain mitbringen
Kosten	Kostenlos (limitiert) bis ca. $20/Monat	Ca. $5/Monat VPS + Domain oder kostenlos mit tuns.sh für schnelle Tests
Datenschutz	Traffic läuft durch ngrok-Cloud	Traffic läuft durch Ihren eigenen VPS (selbstgehostet)
Ratenbegrenzungen	1GB/20k Anfragen (kostenlos), 5GB/100k (Hobbyist), darüber hinaus abgerechnet	Keine inhärenten Begrenzungen bei sish, nur durch Ihre VPS-Bandbreite
Endpoint-Timeout	Keine (ein Mythos sagt etwas anderes)	Keine
Standard-Authentifizierung	Kontenbasiert (SaaS)	SSH-Key/Passwort-Authentifizierung seit aktuellen Releases erforderlich
Einrichtungszeit	Sofort	Sofort mit tuns.sh; ca. 15–30 Minuten für VPS-Setup
Wartung	Keine (für Sie verwaltet)	Minimal (OS- und Container-Updates) bei Selbsthosting; keine bei tuns.sh

Wann ngrok wählen: Sie wünschen eine polierte, vollständig verwaltete Lösung mit integrierter Traffic-Inspektion und stören sich nicht an den Daten-/Anfrage-Limits der kostenlosen Version oder benötigen Enterprise-Features wie SSO und Audit-Logs.

Wann sish wählen: Sie haben ein Team, das persistent benutzerdefinierte Subdomains ohne SaaS-Gebühren möchte, Sie mit sensiblen Daten arbeiten, die nicht durch Dritte laufen sollen, oder Sie unmetered Bandwidth nur durch Ihren VPS begrenzt haben wollen.

---

So bauen Sie Ihren eigenen privaten ngrok mit sish und einem $5 VPS

Voraussetzungen

1. Ein Cloud-VPS: Ein einfacher $5/Monat-Server von DigitalOcean, Linode, Vultr oder Hetzner reicht aus. Wählen Sie Ubuntu 22.04 LTS oder 24.04 LTS.
2. Einen Domainnamen (z.B. meine-tunnel.de), um den Traffic an Ihren VPS zu leiten.
3. Grundlegende Terminalkenntnisse mit SSH und der Kommandozeile.
4. Den SSH-Öffentlichen Schlüssel Ihres lokalen Rechners (meist ~/.ssh/id_ed25519.pub) – den benötigen Sie von Anfang an, da sish jetzt Authentifizierung voraussetzt.

Schritt 1: DNS-Einträge konfigurieren

Damit sish den Traffic dynamisch auf verschiedene Subdomains routen kann, richten Sie einen Wildcard-DNS-Eintrag ein. In der DNS-Verwaltung Ihres Domain-Providers erstellen Sie zwei A-Records, die auf die öffentliche IP Ihres VPS zeigen:

1. Primärer Eintrag: Host meine-tunnel.de (oder @) → Ihre VPS-IP
2. Wildcard: Host *.meine-tunnel.de → Ihre VPS-IP

DNS-Propagation kann einige Minuten bis Stunden dauern.

Schritt 2: VPS vorbereiten (Docker installieren)

SSH in Ihren VPS:

ssh root@your_vps_ip

Pakete aktualisieren:

sudo apt update && sudo apt upgrade -y

Docker über das offizielle Script installieren:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
docker --version

Schritt 3: sish bereitstellen, von Anfang an gesichert

Frühere sish-Anleitungen hatten Sie dazu gebracht, es ohne Authentifizierung zu deployen und später zu sichern. Das ist nicht mehr der empfohlene Ablauf – neuere sish-Versionen erfordern standardmäßig SSH-Authentifizierung, daher ist die sichere Einrichtung und der produktive Einsatz jetzt derselbe Schritt.

Erstellen Sie die benötigten Verzeichnisse und kopieren Sie Ihren öffentlichen Schlüssel vor dem Start des Containers:

mkdir -p ~/sish/ssl ~/sish/keys ~/sish/pubkeys
cp ~/.ssh/id_ed25519.pub ~/sish/pubkeys/

Laden Sie das aktuelle Image herunter und starten Sie es, wobei Sie Ihren eigenen Domainnamen anpassen:

docker pull antoniomika/sish:latest

docker run -itd --name sish \
  --restart always \
  -v ~/sish/ssl:/ssl \
  -v ~/sish/keys:/keys \
  -v ~/sish/pubkeys:/pubkeys \
  --net=host antoniomika/sish:latest \
  --ssh-address=:2222 \
  --http-address=:80 \
  --https-address=:443 \
  --https=true \
  --https-certificate-directory=/ssl \
  --authentication-keys-directory=/pubkeys \
  --private-keys-directory=/keys \
  --bind-random-ports=false \
  --domain=meine-tunnel.de

Einige Hinweise zu diesen Flags: * --net=host bindet den Container direkt an die Netzwerkschnittstellen des Hosts für genaue Client-IP-Logs. * --ssh-address=:2222 vermeidet Konflikte mit dem eigenen SSH-Daemon des VPS auf Port 22. * --authentication-keys-directory=/pubkeys zeigt sish, wo es die autorisierten Schlüssel überwachen soll; es lädt automatisch neu, wenn Sie Dateien hinzufügen oder entfernen, kein Neustart nötig. * --bind-random-ports=false erlaubt es Clients, spezifische TCP-Ports anzufragen, anstatt immer einen zufälligen zu erhalten. * Dieser Basis-Setup setzt voraus, dass Zertifikate bereits in /ssl vorhanden sind (z.B. via certbot). Wenn sish die Let’s Encrypt-Zertifikate on-demand selbst holen soll, fügen Sie --https-ondemand-certificate --https-ondemand-certificate-accept-terms hinzu. Für vollautomatisierte Wildcard-Zertifikate via DNS-01-Challenge verwenden Sie die offizielle Docker-Compose-Deployment, die den dnsrobocert-Container integriert.

Überprüfen Sie die Logs, um sicherzustellen, dass alles sauber gestartet ist:

docker logs -f sish

Schritt 4: Testen Sie Ihren neuen privaten ngrok

Von Ihrem lokalen Rechner – nicht vom VPS – mit einem lokalen Server auf Port 3000:

ssh -p 2222 -R 80:localhost:3000 meine-tunnel.de

Da Ihr öffentlicher Schlüssel bereits vertraut ist, verbindet sich die Verbindung sofort und gibt eine HTTPS-URL zurück, z.B.:

Drücken Sie Ctrl-C, um die Sitzung zu beenden.
Weiterleitung zu:
https://zufallsstring.meine-tunnel.de

Einen benutzerdefinierten Subdomain anfordern

ssh -p 2222 -R benutzername:80:localhost:3000 meine-tunnel.de

Dies versucht, https://benutzername.meine-tunnel.de zu binden, solange diese Subdomain noch nicht von einem anderen Nutzer auf Ihrem Server beansprucht wird.

Entwicklerzugang verwalten

Da das pubkeys-Verzeichnis kontinuierlich überwacht wird, ist das Hinzufügen oder Entfernen eines Teammitglieds nur eine Dateioperation – kein Neustart erforderlich:

nano ~/sish/pubkeys/neuer_teamkollege.pub
# öffentlichen Schlüssel einfügen, speichern

Ein praktischer Shortcut für die Onboarding mit GitHub-gehosteten Schlüsseln:

curl https://github.com/dein-github-benutzername.keys > ~/sish/pubkeys/dein-github-benutzername

---

Erweiterte sish-Anwendungsfälle

1. Firewalls mit TCP-Tunneln umgehen

sish ist nicht auf HTTP/HTTPS beschränkt. Um eine lokale MySQL-Instanz (Port 3306) für einen entfernten Client freizugeben:

ssh -p 2222 -R 3306:localhost:3306 meine-tunnel.de

Der entfernte Client verbindet sich zu meine-tunnel.de:3306 und der Traffic wird sicher an Ihre lokale Datenbank weitergeleitet.

2. Private TCP-Aliases (keine öffentliche Exposition)

Für Zugriffsarten, die nicht öffentlich im Internet sichtbar sein sollen, auch hinter Authentifizierung, unterstützt sish TCP-Aliases, die nur über einen authentifizierten SSH-Jump-Host erreichbar sind – nichts ist öffentlich gebunden:

ssh -p 2222 -R meinlaptop:22:localhost:22 meine-tunnel.de

Ein Teammitglied mit Zugriff kann dann so darauf zugreifen:

ssh -J meine-tunnel.de meinlaptop

3. Teamweite Integration

Standardisieren Sie den Tunnel-Befehl in der package.json oder im Makefile Ihres Teams:

"scripts": {
  "start": "react-scripts start",
  "tunnel": "ssh -p 2222 -R $(whoami)-dev:80:localhost:3000 meine-tunnel.de"
}

Wenn Alice npm run tunnel ausführt, erhält sie alice-dev.meine-tunnel.de; Bob erhält bob-dev.meine-tunnel.de.

4. CI/CD Pipeline-Tests

Da sish nur einen standardmäßigen SSH-Client benötigt, lässt es sich leicht in GitHub Actions oder GitLab CI integrieren – starten Sie eine temporäre App-Instanz, tunneln Sie sie durch Ihren sish-Server und führen Sie End-to-End-Tests gegen die öffentliche URL durch, bevor Sie sie wieder abbauen.

5. Lastverteilung und SNI-Routing

Wenn Ihr Anwendungsfall über einen einzelnen Entwickler-Tunnel hinausgeht, ermöglichen die optionalen Load-Balancer-Modi (--http-load-balancer, --tcp-load-balancer, --sni-load-balancer) von sish, dass mehrere Clients denselben Domain-, Port- oder SNI-Hostnamen teilen – nützlich für einfache Multi-Instance-Failover ohne separaten Load-Balancer.

---

Zusammenfassung

ngrok’s Politur und Traffic-Inspektions-Tools bleiben nützlich, und der kostenlose Tarif – begrenzt auf Daten und Anfragen, nicht auf Sitzungsdauer – ist eine gute Möglichkeit, sich einen Eindruck zu verschaffen. Für Teams, die Kontrolle, Datenschutz und vorhersehbare Kosten wollen, ist Self-Hosting einfacher denn je: sish ist jetzt standardmäßig sicher, bietet eine Managed-Option bei tuns.sh für Null-Setup-Tests und hat Funktionen (TCP-Aliases, SNI-Proxy, Load-Balancing, Traffic-Console), die die Lücke zu kommerziellen Tunneling-Plattformen schließen.

Mit etwa $5 pro Monat und 20 Minuten Setup können Sie einen privaten, benutzerdefinierten Tunneling-Server betreiben, den Ihr gesamtes Team kontrolliert.

---

Changelog

Dieser Artikel wurde am 18. Juli 2026 aus einem eingereichten Entwurf neu geschrieben und anhand der primären Quellen überprüft.

Korrekturen: 1. Der Mythos um die 2-Stunden-Timeout im kostenlosen ngrok-Tarif wurde vollständig entfernt und eine klare Korrektur hinzugefügt. Laut ngrok’s eigener Limits-Dokumentation haben kostenlose Endpunkte kein Timeout und können unbegrenzt im Hintergrund laufen; die tatsächlichen Beschränkungen sind die monatlichen Daten-, Anfrage- und Verbindungsgrenzen. Quelle: ngrok.com/docs/pricing-limits/free-plan-limits. 2. Das Preismodell von ngrok wurde aktualisiert. Die ursprüngliche Version beschrieb nur die allgemeinen Tarife. Aktuelle Stufen laut ngrok’s eigener Preis- und Limits-Dokumentation: Kostenlos ($0, $5 einmaliger Kredit, 3 Endpunkte, 1GB/20k Anfragen monatlich), Hobbyist ($8/Monat jährlich oder $10/Monat, 5GB/100k Anfragen, 3-Endpunkt-Limit), Pay-as-you-go ($20/Monat Grundpreis inkl. $20 Nutzungskredit, unbegrenzte Endpunkte, Abrechnung nach Verbrauch), Enterprise (individuell / Angebot). Quelle: ngrok.com/docs/pricing-limits. 3. Der Deploy-Flow von sish wurde korrigiert. Die ursprüngliche Empfehlung, es ohne Authentifizierung zu deployen und später zu sichern, entspricht nicht mehr der aktuellen Praxis: --authentication ist jetzt standardmäßig aktiviert, sodass sish sofort eine SSH-Authentifizierung erfordert. Das Tutorial wurde umstrukturiert, um den öffentlichen Schlüssel vor dem ersten Start in ~/sish/pubkeys zu platzieren. 4. Der Docker-Run-Befehl wurde aktualisiert, um die aktuellen offiziellen Beispiele widerzuspiegeln, inklusive --private-keys-directory=/keys und --bind-random-ports=false Flags. 5. Die Automatisierung von Let’s Encrypt wurde korrigiert. Das einfache docker run-Deployment stellt keine automatischen Zertifikate bereit – es erwartet, dass Zertifikate bereits im /ssl-Verzeichnis vorhanden sind, es sei denn, Sie fügen die Flags --https-ondemand-certificate hinzu oder verwenden das offizielle Docker-Compose-Deployment, das den dnsrobocert-Container für automatische Wildcard-Zertifikate integriert.

Zusätzliche Hinweise: 6. Das offizielle Managed-Produkt tuns.sh wurde als Null-Setup-Option für das Testen von sish ohne VPS hinzugefügt. 7. Die Projektstatistiken: sish ist in Version v2.23.0 (Juni 2026), mit ca. 4.600 GitHub-Sternen, 329 Forks, 64 Releases, und wird von pico.sh gesponsert. 8. Die Funktionen für private TCP-Aliases (SSH Jump-Host ohne öffentliche Bindung) und die optionalen Load-Balancer-Modi (HTTP, TCP, SNI) wurden ergänzt. 9. Das Traffic-Inspection-Feature (Admin-Console) wurde hinzugefügt, um die weitergeleiteten Anfragen zu überwachen. 10. Die Aussage zu Serveo’s Verfügbarkeit wurde abgeschwächt, um die gemischte Erreichbarkeit anhand externer Monitoring-Tools widerzuspiegeln.

Hinweis: Die Quellen sind die offiziellen Dokumentationen docs.ssi.sh und das GitHub-Repo github.com/antoniomika/sish.