portless: Portnummern durch benannte lokale URLs ersetzen

Projektkern und README-Grenzen · vercel labs portless

Portless ersetzt Portnummern in lokalen Entwicklungs-URLs durch stabile, benannte Adressen. Statt sich zu merken, dass Ihre App auf http://localhost:3000 läuft, erhalten Sie https://myapp.localhost. Das Projekt beschreibt sich selbst als für Menschen und Agenten funktionierend, was bedeutet, dass die benannten URLs für Menschen leichter einzugeben und für automatisierte Werkzeuge leichter zu referenzieren sind. Die README zeigt eine typische Änderung: next dev wird zu portless run next dev, und die Ausgabe-URL basiert auf dem von Ihnen angegebenen App-Namen.

Im Abschnitt Projektkern und README-Grenzen lässt sich portless an konkreten Repository-Spuren prüfen: vercel-labs/portless, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Konkreter Einstieg im Repository · vercel labs portless

Installieren Sie portless global mit npm install -g portless oder als Projekt-Dev-Abhängigkeit mit npm install -D portless. Die README weist darauf hin, dass das Projekt pre-1.0 ist, sodass projektweise Installationen dazu führen können, dass verschiedene Mitwirkende unterschiedliche Versionen ausführen, und sich das Format des Statusverzeichnisses zwischen Versionen ändern kann, was ein erneutes Ausführen von portless trust erforderlich machen kann. Die angegebenen Anforderungen sind Node.js 24+ und macOS, Linux oder Windows. Tailscale- und ngrok-CLIs sind optional und nur für die Freigabefunktionen erforderlich.

Im Abschnitt Konkreter Einstieg im Repository lässt sich portless an konkreten Repository-Spuren prüfen: vercel-labs/portless, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Architektur und Datenfluss · vercel labs portless

Bloßes portless führt das dev-Skript aus package.json über den Proxy aus und leitet den App-Namen aus dem Paketnamen, dem Git-Root oder dem Verzeichnis ab. Sie können den Namen mit einer portless.json-Datei überschreiben, die ein name-Feld enthält. Das Skript standardmäßig auf dev. Für Monorepos deckt eine portless.json im Repository-Root alle Workspace-Pakete ab, die aus pnpm-workspace.yaml oder dem workspaces-Feld in package.json ermittelt werden. Die apps-Zuordnung ermöglicht Paket-übergreifende Namensüberschreibungen, und Hostnamen folgen einer <package>.<project>.localhost-Konvention, es sei denn, ein Paket entspricht dem Projektnamen. Alternativ kann ein "portless"-Schlüssel in package.json den Namen oder Optionen pro App festlegen, wobei er Vorrang vor portless.json-Einträgen hat, aber von CLI-Flags überschrieben wird.

Im Abschnitt Architektur und Datenfluss lässt sich portless an konkreten Repository-Spuren prüfen: vercel-labs/portless, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Konfiguration, Laufzeit und Abhängigkeiten · vercel labs portless

Portless weist jeder App einen freien Port im Bereich 4000-4999 zu und registriert ihn beim Proxy. Sie können einen Namen und einen Befehl angeben, z. B. portless api.myapp pnpm start, um https://api.myapp.localhost zu erhalten. Standardmäßig werden nur explizit registrierte Subdomains geroutet; --wildcard erlaubt es jeder Subdomain, auf die übergeordnete App zurückzufallen. Git-Worktrees werden automatisch erkannt: Ein verknüpfter Worktree erhält den Zweignamen als Subdomain-Präfix, sodass jeder Worktree ohne zusätzliche Konfiguration seine eigene URL hat. Verwenden Sie --name, um den Basisnamen zu überschreiben, während Sie das Worktree-Präfix beibehalten.

Im Abschnitt Konfiguration, Laufzeit und Abhängigkeiten lässt sich portless an konkreten Repository-Spuren prüfen: vercel-labs/portless, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Betrieb, Sicherheit und Wartung · vercel labs portless

HTTPS mit HTTP/2 ist standardmäßig aktiviert. Beim ersten Start generiert portless eine lokale CA, vertraut ihr und bindet Port 443, wobei es unter macOS und Linux automatisch mit sudo erhöht wird. Verwenden Sie --no-tls für einfaches HTTP. Der Proxy startet automatisch, wenn Sie eine App ausführen, und verwendet die Konfiguration des letzten Laufs, sofern sie nicht durch Umgebungsvariablen überschrieben wird. Benutzerdefinierte TLDs werden über --tld unterstützt, z. B. .test, und der Proxy synchronisiert /etc/hosts automatisch für Routen-Hostnamen. Mehrsegment-TLDs wie dev.example.com sind erlaubt, was OAuth-Umleitungs-URIs und Cookies konsistent mit der Produktion halten kann. Die README empfiehlt .test und warnt aus spezifischen technischen Gründen vor .local und .dev.

Im Abschnitt Betrieb, Sicherheit und Wartung lässt sich portless an konkreten Repository-Spuren prüfen: vercel-labs/portless, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Lizenz und belegte Nutzung · vercel labs portless

Portless bietet drei Freigabemodi. Der LAN-Modus (--lan) bindet den Proxy an alle Schnittstellen und verwendet mDNS, um .local-Namen im lokalen Netzwerk zu veröffentlichen, mit automatischer LAN-IP-Erkennung. Tailscale-Freigabe (--tailscale) mountet jede App auf einem eigenen HTTPS-Port in Ihrem Tailnet und verwendet Ihre vorhandenen Tailscale-HTTPS-Zertifikate. Funnel (--funnel) macht die App über Tailscale Funnel öffentlich im Internet zugänglich. ngrok-Freigabe (--ngrok) erstellt eine öffentliche URL über ngrok. Jeder Modus hat seine eigenen Voraussetzungen: Tailscale-CLI und aktivierte HTTPS-Zertifikate für Tailscale, ngrok-CLI und Authentifizierung für ngrok sowie mDNS-Tools (avahi-utils unter Linux) für den LAN-Modus. Umgebungsvariablen wie PORTLESS_LAN=1 können einen Modus zum Standard machen.

Im Abschnitt Lizenz und belegte Nutzung lässt sich portless an konkreten Repository-Spuren prüfen: vercel-labs/portless, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Prüfung für den konkreten Anwendungsfall · vercel labs portless

Der Befehlssatz umfasst portless run zum Ableiten des Namens, portless alias für statische Routen, portless list zum Anzeigen aktiver Routen, portless doctor für Diagnosen, portless trust zum Installieren der CA, portless clean zum Entfernen aller Zustands- und Vertrauenseinträge und portless prune zum Beenden verwaister Prozesse. Es gibt auch Proxy-Steuerbefehle: portless proxy start, stop und Optionen wie --port, --no-tls, --foreground und --wildcard. Ein Dienst kann mit portless service install installiert werden, um den Proxy beim Systemstart über launchd, systemd oder den Taskplaner zu starten. Die README enthält eine Liste von Umgebungsvariablen, die Proxy-Einstellungen überschreiben, sowie Variablen, die in untergeordnete Prozesse injiziert werden, wie PORT und PORTLESS_URL. Um portless für einen einzelnen Lauf zu deaktivieren, setzen Sie PORTLESS=0.

Im Abschnitt Prüfung für den konkreten Anwendungsfall lässt sich portless an konkreten Repository-Spuren prüfen: vercel-labs/portless, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Ein sinnvoller Probelauf für portless beginnt mit dem im README genannten Einstieg und einer kleinen Eingabe. Dabei sollten Rückgabecode, erzeugte Dateien, Protokollausgaben und die verwendete Version gemeinsam notiert werden. Weicht das Ergebnis von der Beschreibung ab, gehört die genaue Kommandozeile samt Fehlermeldung in den Befund.

Redaktionelles Fazit

Geeignet ist portless für Leser, deren Anwendungsfall zu den im README beschriebenen Eingängen und Laufzeitbedingungen passt. Ungeeignet ist es, die Dokumentation als Zusage für nicht genannte Skalierung oder Kompatibilität zu lesen. Vor einer Entscheidung sollte der konkrete README-Einstieg mit einer kleinen Eingabe ausgeführt und das Ergebnis anhand der genannten Dateien und Ausgaben geprüft werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes