Die Alternative zum Instant File Server: So machen Sie aus localhost einen öffentlichen Laufwerk

Das Entwickler-Dilemma: Sie haben gerade einen wichtigen Freitag-Sprint abgeschlossen und müssen eine 50GB Docker-Image, einen großen SQL-Dump oder einen Ordner mit unkomprimierten 4K-Assets an einen Kunden oder QA-Team übergeben. Sie ziehen den Ordner in Google Drive, S3 oder Dropbox und beobachten den Fortschrittsbalken beim Hochladen. Ihre Download-Geschwindigkeit ist schnell, aber die Upload-Geschwindigkeit im Heimnetz ist meist nur ein Bruchteil davon — bevor Ihr Kunde etwas herunterladen kann, müssen Sie warten, bis die gesamte Payload hochgeladen ist.

Was wäre, wenn Sie den Cloud-Mittelsmann ganz überspringen und den Kunden die Dateien direkt von Ihrer Maschine ziehen lassen?

Tunneling-Tools wie LocalXpose und Localtonet bieten integrierte File-Server-Modi, die genau das tun: Sie zeigen auf einen Ordner, und dieser wird sofort unter einer öffentlichen URL veröffentlicht, ohne einen separaten Webserver oder Upload-Wartezeit. Dieser Beitrag erklärt, wie man localhost in einen File-Server verwandelt, die Mechanik dahinter, sowie die tatsächliche (verifizierte) Befehlsyntax und Funktionsumfang beider Tools — inklusive Localtonet’s WebDAV-Netzlaufwerkmodus und den neueren verschlüsselten Backup-Funktionen.

---

Warum Cloud-Speicher das falsche Werkzeug für eine schnelle Übergabe ist

1. Das Doppel-Transfer-Flaschenhals. Cloud-Speicher ist asynchron: Gerät A muss den Upload von 100% der Datei abschließen, bevor Gerät B mit dem Download beginnen kann. Bei einer asymmetrischen Heimverbindung bedeutet eine 20GB-Datei bei 20 Mbps Upload-Geschwindigkeit über zwei Stunden nur das Staging des Transfers — bevor Ihr Kunde auch nur ein Byte berührt.
2. Speicher- und Bandbreitenlimits. Ein mehrgigabyte Log-Bundle oder ein Snapshot der Staging-Umgebung kann das kostenlose Speicherlimit schnell sprengen, was eine Bereinigung oder ein Upgrade erfordert, obwohl es nur für einmalige Übergaben gedacht ist.
3. Datenhoheit. Das Hochladen proprietärer Quelldateien, unveröffentlichter Medien oder Kundendaten (auch sanitisiert) in eine Cloud eines Drittanbieters bedeutet, dass diese auf Infrastruktur liegen, die Sie nicht kontrollieren.
4. Sync-Fragilität. Das ZIPpen riesiger Verzeichnisse mit vielen kleinen Dateien (z.B. node_modules-Baum, statische Website-Builds) und das Hochladen über einen Desktop-Sync-Client ist eine häufige Ursache für Datei-Lock-Probleme und beschädigte Übertragungen.

Die Alternative ist Peer-to-Peer, Zero-Upload-Sharing: Der Kunde zieht die Datei direkt von Ihrer Festplatte, nur mit Ihrer verfügbaren Upstream-Bandbreite.

---

Wie Reverse-Proxy-Verzeichnisfreigabe wirklich funktioniert

Selbsthosting eines File-Servers bedeutete früher, gegen das Netzwerk zu kämpfen: Statische IPs, Router-Port-Weiterleitung, Firewall-Regeln, und die Hoffnung, dass Ihr ISP Sie nicht hinter Carrier-Grade NAT (CGNAT) versteckt, das eingehende Verbindungen komplett blockiert.

Moderne Tunneling-Clients kehren das um. Statt einen Port zu öffnen und auf eingehenden Traffic zu warten, stellt ein leichter Agent auf Ihrer Maschine eine ausgehende Verbindung zu einem Edge-Server des Tunneling-Anbieters her. Ausgehende Verbindungen passieren NAT, CGNAT und die meisten Firewalls ohne Konfiguration. Der Edge-Server gibt Ihnen eine öffentliche HTTPS-URL; wenn jemand diese anfragt, leitet der Edge-Server die Anfrage über den bereits offenen Tunnel an Ihre Maschine weiter.

Wenn Sie diese Architektur auf einen Ordner statt auf eine App auf einem Port richten, erhalten Sie reverse-proxy Verzeichnisfreigabe: Ein spezifischer Pfad auf Ihrer Festplatte, sicher und temporär exponiert, ohne einen Webserver zu deployen oder Ihren Router zu konfigurieren.

---

LocalXpose’s integrierter File-Server

LocalXpose ist ein vielseitiger Tunneling-Client (HTTP, TLS, TCP, UDP), der auch einen File-Server-Modus direkt im http-Tunneltyp integriert hat — kein separater Webserver notwendig.

Der eigentliche Befehl

Die offiziellen Tutorials von LocalXpose geben genau diese Syntax für eine geschützte Dateifreigabe:

loclx tunnel http --subdomain mypics --basic-auth user:pass --file-server /home/pics

--file-server nimmt direkt den Ordnerpfad; --basic-auth user:pass schützt das gesamte Verzeichnis mit HTTP Basic Auth, noch bevor die Liste angezeigt wird, sodass unautorisierte Anfragen am Edge abgefangen werden, bevor sie Ihre Maschine erreichen. --subdomain ist optional — lassen Sie es weg, weist LocalXpose eine zufällige Subdomain zu.

Unter Windows sieht der entsprechende Befehl so aus:

loclx tunnel http --basic-auth client:supersecretpassword --file-server C:\Users\Dev\Deliverables

(Der Marketing-Abschnitt von LocalXpose zeigt auch eine alternative Form, --to /path --file-server mit --file-server als booleschem Flag — beide Varianten finden sich in den offiziellen Materialien, aber die oben genannte Syntax ist die im dedizierten File-Sharing-Tutorial dokumentierte und die sicherere Kopier-Variante.)

Client installieren

LocalXpose bietet Pakete für alle gängigen Plattformen:

# macOS (Homebrew)
brew install --cask localxpose

# Linux (Snap)
sudo snap install localxpose

# Plattform mit Node
npm install -g loclx

# Windows (Chocolatey)
choco install localxpose

Einmal anmelden mit loclx account login, oder ACCESS_TOKEN für nicht-interaktive/CI-Nutzung exportieren.

Noch weiter absichern

Basic Auth ist das Minimum. LocalXpose unterstützt auch ein ip_whitelist-Plugin und eine reserved_domain für eine stabile, einprägsame File-Server-URL, konfigurierbar via config.yaml:

file-server:
  type: http
  region: us
  reserved_domain: mydomain.com
  plugins:
    ip_whitelist:
      - 203.0.113.0/24
  apps:
    file_server:
      path: ./deliverables

Für eine Freigabe, die dauerhaft laufen soll, registriert loclx service install LocalXpose als Hintergrunddienst, sodass der Tunnel auch nach Schließen des Terminals oder Neustart bestehen bleibt.

---

Localtonet: drei File-Server-Modi, nicht nur einer

Localtonet verfolgt einen breiteren Ansatz: Sein File Server-Tunneltyp bietet im Dashboard einen eigenen “Process Type”-Selector mit drei Modi — Default (Browser-Dateimanager), SFTP und WebDAV — alle auf denselben lokalen Ordnerpfad gerichtet, ohne dass ein separater SFTP-Daemon oder Webserver auf Ihrer Seite laufen muss.

1. Default — browserbasierter Dateimanager

Laut eigener Dokumentation von Localtonet umfasst der Default-Modus: Hochladen, Herunterladen, Umbenennen, Verschieben, Kopieren, Löschen, Ordner erstellen, Suchen, Vorschau, Tagging, Archivierung und Teilen. Die Berechtigungen werden pro Tunnel mit globalen Upload / Download / Delete / Create Folder / Move / Share-Flags verwaltet, sowie mit Pfad-Overrides, bei denen der spezifischste Pfad gewinnt — eine feinere Steuerung als ein einfaches “Lesen/Schreiben/Löschen”-Toggle.

Ab Mitte 2026 hat Localtonet auch echte Sicherheits- und Backup-Funktionen hinzugefügt, die es wert sind, bei der Nutzung für mehr als eine einmalige Übergabe zu kennen:

• AES-256-CBC Ordnerverschlüsselung, mit Schlüsseln, die nie Ihre Maschine verlassen.
• Immich-kompatibles mobiles Fotobackup mit Deduplizierung, für die Nutzung als selbstgehostetes Fotobackup-Ziel.
• Geplantes Cloud-Backup zu Amazon S3 (und S3-kompatiblen Speicher wie Backblaze B2, Wasabi oder MinIO), FTP oder SFTP-Remote-Server — konfigurierbar mit mehreren Anbietern parallel (z.B. primäres S3-Ziel und sekundäres SFTP auf einem Heim-NAS).

Die Dokumentation von Localtonet bestätigt nicht, ob alle diese Funktionen (Verschlüsselung, Immich-Backup, geplantes Cloud-Backup) auch in den SFTP- oder WebDAV-Modi gelten — behandeln Sie diese bis zur offiziellen Dokumentation als spezifisch für den Default-Modus.

2. SFTP — für bestehende Tools und Automatisierung

Die Auswahl SFTP als Process Type gibt Ihnen einen standardisierten SFTP-Endpunkt, der auf denselben lokalen Ordner zugreift, sodass FileZilla, WinSCP, rsync oder CI-Backup-Skripte ohne Änderungen an der Konfiguration verbinden können. Da der eigene Agent von Localtonet den SFTP-Endpunkt bereitstellt, brauchen Sie keinen separaten SSH/SFTP-Daemon auf dem Host zu installieren oder zu öffnen.

3. WebDAV — den Ordner als Netzlaufwerk mounten

WebDAV ist der Modus, der es ermöglicht, den freigegebenen Ordner als natives Laufwerk zu mounten, anstatt ihn in einer Web-UI oder einem Dateiübertragungstool zu durchsuchen:

• Windows: Datei-Explorer → “Netzlaufwerk verbinden,” URL von Localtonet WebDAV einfügen, Anmeldedaten eingeben.
• macOS: Finder → Cmd+K (“Mit Server verbinden”), URL eingeben.

Nach dem Mounten kann der Client Dateien öffnen, bearbeiten und speichern mit den gewohnten Desktop-Apps (Word, VS Code, Photoshop), ohne manuelles Herunterladen oder Hochladen, und große Dateien per Drag-and-Drop direkt in das Laufwerk ziehen.

Einrichtung eines beliebigen Localtonet File-Server-Tunnels

1. Installieren Sie die Localtonet-App für Ihr Betriebssystem und melden Sie sich an.
2. Kopieren Sie Ihren AuthToken vom Dashboard und fügen Sie ihn in die App ein.
3. Gehen Sie auf die File Server-Seite, wählen Sie einen Process Type (Zufällige Subdomain / Benutzerdefinierte Subdomain / Eigene Domain), wählen Sie Default, SFTP oder WebDAV, und geben Sie Ihren AuthToken sowie die Serverregion an.
4. Geben Sie den lokalen Ordnerpfad ein (z.B. C:\Users\Work unter Windows, /root oder /usr/share unter Linux).
5. Drücken Sie Start. Standardmäßig sind alle Funktionen sofort öffentlich aktiv, sobald der Tunnel startet — klicken Sie auf Verwalten unter Berechtigungen, um Upload, Löschen oder Verschieben vor der Freigabe zu beschränken.

---

Ein allgemeiner Rahmen für beide Tools

1. Client installieren — LocalXpose (snap, brew, npm, choco) oder Localtonet (Plattform-Installer vom Dashboard).
2. Authentifizieren — loclx account login für LocalXpose; Ihren AuthToken in die Localtonet-App einfügen.
3. Einen isolierten Ordner wählen. Ein dedizierten Transfer-Ordner freigeben, niemals das Projekt-Root oder Home-Verzeichnis — so vermeiden Sie versehentlich .env-Dateien, .git/-Verlauf oder Build-Artefakte, die das System verlassen sollen.
4. Tunnel mit aktivierter Authentifizierung starten. Für LocalXpose immer --basic-auth hinzufügen. Für Localtonet den Default-Modus auf die minimalen Berechtigungen setzen, die der Empfänger braucht, oder SFTP/WebDAV-Zugangsdaten verwenden.
5. URL teilen, dann beenden. Nach erfolgreichem Transfer Ctrl+C bei LocalXpose oder im Dashboard auf Stopp bei Localtonet klicken — die öffentliche URL ist sofort weg.

---

Sicherheitsbest Practices

• Minimalrechte. Wenn nur Download benötigt wird, keine Upload/Delete/Verschieben-Rechte auf Localtonet gewähren, und --basic-auth bei LocalXpose nicht überspringen.
• Ephemere Nutzung. Behandeln Sie einen File-Server-Tunnel wie ein temporäres Passwort — nur für die Übergabe hochfahren und sofort wieder schließen.
• Getrennten Ordner verwenden. Dateien in einen dedizierten Freigabeordner kopieren, statt den Tunnel auf einen aktiven Arbeits- oder Projektordner zu richten.
• Logs überwachen. Beide Tools zeigen in Echtzeit Verbindungsaktivitäten im CLI oder Dashboard — unbekannte IPs oder eine Flut an schnellen, wiederholten Anfragen (Bot-Scanning) sind Hinweise, den Tunnel sofort zu stoppen.

---

Weitere Wege

• Python + ngrok / Pinggy. Kein dedizierter File-Server-Client? python3 -m http.server 8080 im Zielordner starten, dann Port 8080 mit ngrok http 8080 oder Pinggy tunneln. Es fehlt die Berechtigungssteuerung eines spezialisierten File-Servers, funktioniert aber überall, wo Python läuft.
• Pinggy’s eigener --serve-Shortcut. Das neuere CLI von Pinggy (cli-js) bietet eine Ein-Zeilen-Alternative: pinggy --serve /pfad/zu/dateien startet einen Tunnel und dient das Verzeichnis direkt — kombinierbar mit weiteren Auth-/IP-Whitelist-Flags, was die Lücke zu LocalXpose und Localtonet bei dedizierten File-Server-Modi verkleinert.
• Tailscale / ZeroTier. Wenn beide Seiten bereit sind, einen Mesh-VPN-Client zu installieren, können beide Maschinen im selben privaten Netzwerk sein und native OS-Dateifreigabe (SMB/CIFS) nutzen — allerdings erfordert das, dass der Empfänger zuerst das VPN installiert und authentifiziert, was bei einem einfachen URL nicht notwendig ist.

---

Aktuelle Preise (2026)

	LocalXpose	Localtonet
Kostenloses Kontingent	2 aktive HTTP-Tunnels	1 Tunnel, 1GB Bandbreite/Monat, 30 Minuten Timeout
Bezahltes Paket	Pro: 8$/Monat (96$/Jahr) — 10 aktive Tunnels, unbegrenzte Bandbreite	Bezahle, was du nutzt: ca. 2$ pro aktivem Tunnel/Monat
File-Server inklusive?	Ja, im kostenlosen HTTP-Tunnel-Kontingent	Ja, abgerechnet wie andere Tunneltypen pro aktivem Tunnel

Derzeit veröffentlicht LocalXpose keine konkrete Bandbreitenbegrenzung für das kostenlose Kontingent — bei größeren einmaligen Transfers prüfen Sie die aktuelle Preisseite, bevor Sie sich darauf verlassen.

---

FAQ

Was bedeutet es, localhost in einen File-Server zu verwandeln? Es bedeutet, einen bestimmten lokalen Ordner über eine öffentliche URL freizugeben, sodass jemand anderes Dateien direkt auf Ihr System herunterladen (oder je nach Modus hochladen) kann — ohne sie durch einen Cloud-Speicher zu leiten.

Ist das sicher? Das kann es sein, wenn Sie die Basics befolgen: HTTPS verwenden (beide Tools stellen es automatisch bereit), den Share hinter Authentifizierung (bei LocalXpose --basic-auth, bei Localtonet Berechtigungsflags oder SFTP/WebDAV-Zugangsdaten) schützen, nur einen Sandbox-Ordner freigeben und den Tunnel nach Abschluss wieder schließen.

Brauche ich eine öffentliche IP oder Port-Weiterleitung? Nein. Beide Tools funktionieren, indem sie eine ausgehende Verbindung von Ihrer Maschine zu den Edge-Servern des Anbieters herstellen, was NAT, CGNAT und Router-Konfigurationen umgeht.

Was ist der praktische Unterschied zwischen den SFTP- und WebDAV-Modi bei Localtonet? SFTP ist für bestehende Tools und Automatisierung — FileZilla, WinSCP, rsync, CI-Skripte — die bereits das SFTP-Protokoll sprechen. WebDAV ist für das Mounten des Ordners als natives Laufwerk, sodass jemand Dateien öffnen und speichern kann, ohne einen separaten Client.

---

Changelog

Verifiziert anhand der Dokumentation und Blogs von LocalXpose und Localtonet, Stand 7. September 2026.

• Korrektur der CLI-Syntax für den File-Server bei LocalXpose. Der Entwurf nutzte loclx tunnel http --file-server /path --basic-auth user:pass; die offizielle Anleitung dokumentiert die Flag-Reihenfolge als loclx tunnel http --subdomain X --basic-auth user:pass --file-server /path. Das Grundprinzip wurde beibehalten, aber die dokumentierte Flag-Reihenfolge angepasst. Die Marketingseiten von LocalXpose zeigen auch eine alternative Form --to /path --file-server mit --file-server als boolesches Flag — beide Varianten sind in den offiziellen Materialien, aber die oben genannte Syntax ist die im dedizierten File-Sharing-Tutorial dokumentierte und die sicherere Kopier-Variante.
• Unbestätigte Funktionen im Default-Modus bei Localtonet entfernt. Der Entwurf behauptete inline Textbearbeitung von .json/.js/.css-Dateien und einen “integrierten Papierkorb” für den Default-File-Manager — diese erscheinen in der aktuellen Dokumentation und Blog-Berichterstattung nicht. Stattdessen wurde die tatsächliche Feature-Liste (Upload, Download, Umbenennen, Verschieben, Kopieren, Löschen, Ordner erstellen, Suchen, Vorschau, Tagging, Archivierung, Teilen) eingefügt.
• Korrektur des Berechtigungsmodells bei Localtonet. Der Entwurf beschrieb “granulare Nutzerrechte (Lesen, Schreiben, Löschen)”; die Dokumentation nennt globale Flags für Upload/Download/Delete/Ordner erstellen/Verschieben/Teilen mit Pfad-Overrides, nicht ein einfaches “Lesen/Schreiben/Löschen”-Schema.
• Neue Funktionen bei Localtonet für den File Server, die im Entwurf fehlen: AES-256-CBC Ordnerverschlüsselung, Immich-kompatibles mobiles Fotobackup, geplantes Cloud-Backup zu S3-kompatiblen Speicher, FTP oder SFTP — dokumentiert ab Mitte 2026. Hinweis, dass diese Funktionen nicht bestätigt sind für SFTP/WebDAV.
• Klare Darstellung des Setups für SFTP/WebDAV bei Localtonet. Der Entwurf deutete auf eine generische “lokalen SFTP-Server freigeben”-Arbeitsweise hin; tatsächlich ist es ein “Process Type”-Auswahl (Default/SFTP/WebDAV) im File-Server-Tunnel, bei dem der eigene Agent den jeweiligen Dienst direkt bereitstellt — kein separater SFTP-Daemon notwendig.
• Pinggy’s --serve-Flag als Alternative, die im ursprünglichen Abschnitt “Alternative Lösungen” nicht erwähnt wurde, da sie die Annahme unterläuft, dass nicht-dedizierte Tools “den eingebauten Komfort” eines File-Servers nicht bieten.
• Aktuelle, belegte Preise für beide Tools — im Entwurf fehlend: LocalXpose (kostenlos: 2 HTTP-Tunnels; Pro: 8$/Monat, 96$/Jahr, 10 Tunnels, unbegrenzte Bandbreite) und Localtonet (kostenlos: 1 Tunnel/1GB/30 Min Timeout; Bezahlung nach Nutzung: ca. 2$/aktivem Tunnel/Monat).
• Konkrete Installationsbefehle für LocalXpose (Homebrew, Snap, npm, Chocolatey) und die config.yaml/reserved_domain/ip_whitelist/loclx service install-Optionen für einen persistenten, IP-geschützten File-Server-Tunnel — diese waren im Entwurf nicht enthalten.
• Entfernung von nicht-standardisiertem Code-Fragment. Entfernt wurden ein Python-Code-Generierungs-Transkript, Tracebacks und Dateischreib-Wrapper, die in den Entwurf eingedrungen waren, sowie Front-Matter-Metadaten; die Überschriften wurden in ein standardmäßiges Markdown-Format gebracht.