Das ist eigentlich kein Versus. Cloudflare Tunnel (cloudflared) und PortPreview wohnen in verschiedenen Räumen. Cloudflare Tunnel hält einen Dienst dauerhaft online hinter Cloudflares Edge — Zero Trust, Named Tunnels, Custom Domains. PortPreview ist für die nächsten zwanzig Minuten deiner Dev-Session — Webhook-Testing, Mobile-QA, eine Branch mit einer Designerin teilen. Die Wahl zwischen beiden hängt meist davon ab, welches Problem du tatsächlich hast.
Worin Cloudflare Tunnel gut ist
cloudflared wurde für eine Sache gebaut: einen Dienst ins Internet zu stellen, ohne einen einzigen eingehenden Port zu öffnen und ohne deine Origin-IP zu exponieren. Lass es auf einem Server laufen, hänge einen Named Tunnel an einen Hostnamen deiner Cloudflare-Domain, und Traffic fließt über Cloudflares Edge zu deinem Origin über eine ausgehende Verbindung, die deine Maschine initiiert hat.
Dinge, die es gut macht:
- Produktions-Routing. Das Named-Tunnel-Feature ist langlebig. Du kannst cloudflared als Dienst laufen lassen, und der Hostname funktioniert über Neustarts hinweg weiter.
- Zero-Trust-Zugriffsrichtlinien. Schütze den Tunnel hinter SSO, MFA oder IP-Allowlists für die Freigabe interner Tools.
- Custom Domains. Bring deine eigene Domain auf Cloudflare. Der Tunnel terminiert bei
deine-domain.com, nicht bei einer Anbieter-Subdomain. - WARP-Routing. Erreiche private Dienste von jedem Gerät im Cloudflare-Netz ohne VPN-Setup.
Nichts davon dreht sich um Webhook-Debugging.
Wo Cloudflare Tunnel fürs Dev umständlich wird
Der Quick-Tunnel-Modus (cloudflared tunnel --url localhost:3000) ist das Nächste, was cloudflared einem Dev-Tool kommt, und er funktioniert. Du bekommst eine *.trycloudflare.com-URL, die auf deinen lokalen Port zeigt. Aber:
- Die URL rotiert jede Session, wie die meisten Dev-Tunnel.
- Es gibt keinen eingebauten Request-Inspektor. Du siehst, was dein Dev-Server loggt, und nicht mehr. Eine Webhook-Payload zum späteren Replay zu erfassen erfordert das Anflanschen eines separaten Proxys oder Loggers.
- Das Setup für Named Tunnels (die Stable-URL-Version) erfordert einen Cloudflare-Account, DNS-Records und eine Config-Datei. Lohnt sich für einen langlebigen Dienst; übertrieben für eine Webhook-Iterationssession.
Wo PortPreview passt
PortPreview ist eine localhost-Tunneling-CLI für die Dev-Schleife. Ein Befehl, öffentliche HTTPS-URL, Request-Capture und -Replay eingebaut.
npx portpreview 3000Worauf wir optimieren, ist der Moment zwischen „Ich habe meinen Stripe-Webhook-Handler geändert" und „Ich weiß, ob er funktioniert". Dieser Moment sollte Sekunden dauern. Erfasse die Payload, fixe den Handler, replaye, bis es grün ist, alles ohne das Upstream-Event neu auszulösen.
Direkter Vergleich
| Bedarf | Cloudflare Tunnel | PortPreview |
|---|---|---|
| Schnelle Session für Webhook-Debugging | Möglich (Quick Tunnel) | Dafür gebaut |
| Request-Capture und -Replay | Nein | Ja |
| Stabiler Named-Hostname | Ja (mit Setup) | Nicht der Standard-Fokus |
| Custom Domain | Ja | Tunnel-Subdomain |
| Zero-Trust-Zugriffsrichtlinie | Ja | Nein |
| Setup-Komplexität | Niedrig für Quick, mittel für Named | Ein Befehl |
| Dauerhaft als Dienst laufen | Ja | Für Sessions konzipiert |
| Open-Source-Client | Ja (cloudflared) | Ja |
Wann welches nutzen
Nutze Cloudflare Tunnel, wenn
- Du einen Dienst 24/7 online brauchst, ohne Firewall-Ports zu öffnen.
- Du SSO-gesicherten Zugriff auf ein internes Dashboard oder Admin-Tool willst.
- Du eine stabile Custom-Domain-URL brauchst, gestützt auf ein echtes CA-Zertifikat und dein bestehendes Cloudflare-DNS.
- Du bereits auf Cloudflare bist und die marginalen Setup-Kosten gering sind.
Nutze PortPreview, wenn
- Du an einem Webhook-Handler iterierst und Ein-Klick-Replay willst.
- Du eine Branch zehn Minuten lang mit einer Designerin teilen willst.
- Du OAuth-Callbacks oder Mobile-Flows ohne DNS-Setup testest.
- Du keinen Cloudflare-Account verwalten willst, nur um ein Stripe-Event zu testen.
Sie koexistieren problemlos
Mehrere Teams, mit denen wir gesprochen haben, nutzen beide. Cloudflare Tunnel für das Always-on-Internal-Tool, das eine feste URL und SSO braucht. PortPreview für das tägliche Webhook-Debugging, das Replay und einen einzigen Befehl braucht. Sie kollidieren nicht — sie bedienen einfach unterschiedliche Teile des Dev-to-Prod-Bogens.
Wenn du auch ngrok oder localtunnel abwägst, sind diese Vergleiche womöglich direkter relevant. Tritt der PortPreview-Warteliste bei für die Dev-Loop-Seite.