So stellst du Localhost-Apps ohne VPS öffentlich bereit

Deine App läuft. Du hast den Dev-Server gestartet, http://localhost:3000geöffnet, und sie tut, was sie soll. Dann bittet dich jemand um einen Link, und du stellst fest, dass die URL auf deinem Bildschirm für niemanden außer dir etwas bedeutet.

Es gibt drei Wege, einer Localhost-App ohne VPS eine öffentliche URL zu geben, plus eine schnellere Option, wenn die andere Person in deinem lokalen Netzwerk ist. Die Wahl zwischen ihnen ist keine Werkzeugfrage. Es ist die Frage, wie lange die Sache erreichbar bleiben muss und ob sie irgendwo anders als auf deinem Laptop laufen kann. Unten findest du jeden Weg, den Befehl, der eine URL liefert, und genau das, was diese URL wieder unbrauchbar macht.

Kurzfassung

• Jemand in deinem WLAN muss sie sehen: binde den Dev-Server an alle Netzwerkschnittstellen und gib deine LAN-IP weiter. In Sekunden bereit, tot in dem Moment, in dem dein Besucher dein Netzwerk verlässt.
• Du brauchst einen Link, den jeder in der nächsten Stunde öffnen kann: starte einen Tunnel (cloudflared, ngrok, localtunnel, localhost.run). Öffentliche HTTPS-URL in etwa einer Minute, keine Router-Änderungen, und sie stirbt mit dem Prozess, der sie gestartet hat.
• Sie muss auch bei zugeklapptem Laptop laufen: schiebe die App auf einen kostenlosen Hosting-Tarif. Das entkoppelt die App von deinem Laptop und bringt neue Regeln mit: Kreditkarten, kommerzielle Nutzung und die Frage, ob deine Daten einen Neustart überleben.
• Deine App braucht zur Anfragezeit keinen Servercode: baue sie und lege die statische Ausgabe auf einen statischen Host. Sie bleibt ohne deinen Laptop online und hat keinen App-Prozess, der aufgeweckt werden müsste, solange Konto und Nutzungsgrenzen des Hosts noch passen.
• Ein Standardwert, den du kennen solltest: next dev und python -m http.server lauschen ohne jedes Flag bereits auf allen Netzwerkschnittstellen. Falls du angenommen hast, dein Dev-Server sei nur auf deinem Laptop sichtbar: Ist er nicht.

Welcher Weg zu deiner App passt

Drei dieser vier Wege geben deiner App eine öffentliche Internet-URL; der erste erreicht nur dein eigenes Netzwerk, was ihn gleichzeitig zum schnellsten und zum eingeschränktesten macht. Sortiere sie danach, wie lange die URL überleben muss, und die Wahl trifft sich fast von selbst.

Welche Zeilen dir offenstehen, hängt von drei Dingen ab, die du in deinem eigenen Projekt prüfen kannst:

• Braucht die App zur Anfragezeit deinen Servercode? Eine Flask- oder FastAPI-Route, ein server.js -Endpunkt oder anfragespezifische Serverlogik braucht einen serverseitigen Host. Servercode zur Build-Zeit schließt ein statisches Deployment nicht automatisch aus: Next.js Server Components können während next buildlaufen, und statische GET Route Handlers lassen sich vorrendern. Wenn jede Laufzeitanfrage als statische Assets ausgeliefert oder direkt vom Browser an eine externe API geschickt werden kann, steht der statische Weg weiterhin offen.
• Liest oder schreibt sie eine Datei, die sie behalten muss? Eine Datenbankdatei (.db, .sqlite), ein Upload-Ordner, eine JSON-Datei, die sie bearbeitet. Wenn ja, prüfe vor dem Deployment das Speichermodell des Hosts. Kostenlose Web Services bei Render und kostenlose Instanzen bei Koyeb nutzen flüchtigen lokalen Speicher, während Vercel Functions ein schreibgeschütztes Dateisystem mit temporärem /tmp -Speicher haben. Lege persistenten Zustand in ein dauerhaftes Volume, eine Datenbank oder einen Objektspeicher, statt anzunehmen, dass die lokale Platte der App überlebt.
• Braucht sie zur Laufzeit ein Secret? Ein Schlüssel in einer .env -Datei funktioniert auf den ersten beiden Wegen unverändert, da die App weiterhin auf deinem Rechner läuft. Auf den anderen beiden trägst du ihn in den Umgebungseinstellungen des Anbieters neu ein, und er darf nicht im Repository liegen, das du pushst.

Teile sie in deinem eigenen Netzwerk

next dev lauscht bereits auf allen Netzwerkschnittstellen deines Rechners (mehr bedeutet 0.0.0.0 nicht, wenn du es siehst), und dasselbe gilt für python -m http.server. Keiner der beiden braucht ein Flag, also ist der Dev-Server, den du gerade laufen hast, vermutlich schon von deinem Smartphone im selben WLAN erreichbar.

Next.js dokumentiert -H als Weg, diesen Hostnamen zu ändern, mit einem Standardwert von 0.0.0.0, und die Python-Dokumentation sagt, dass sich das Modul an alle Schnittstellen bindet , sofern du nicht --bind 127.0.0.1übergibst. Das macht es zum schnellsten Weg, eine Localhost-App zu teilen: kein Konto, keine Installation, kein Deployment. Den anderen gängigen Dev-Servern muss man es sagen.

# Already listening on all interfaces. Nothing to add.
next dev
python -m http.server 8000
streamlit run app.py

# Needs the flag.
npm run dev -- --host             # Vite
flask run --host=0.0.0.0
uvicorn main:app --host 0.0.0.0   # FastAPI

Vites Dokumentation: server.host steht standardmäßig auf localhostund akzeptiert --host auf der Kommandozeile oder server.host: '0.0.0.0' in der Konfigurationsdatei. Uvicorn nutzt standardmäßig 127.0.0.1, was FastAPI abdeckt, da es damit läuft. Streamlit lässt server.address leer, und seine Konfigurationsreferenz merkt an, dass das Setzen den Zugriff einschränkt , und zwar auf genau diese eine Adresse: leer heißt uneingeschränkt.

Dann brauchst du die Adresse zum Weitergeben. Das ist die eigene IP deines Rechners im lokalen Netzwerk, nicht localhost:

# macOS
ipconfig getifaddr en0

# Linux
hostname -I

# Windows (PowerShell)
ipconfig | findstr IPv4

Gib deinem Besucher http://<that-address>:3000 und er ist drin. Der Haken liegt in der Form des ganzen Wegs: Diese Adresse bedeutet außerhalb deines Netzwerks nichts. Sobald er in einem anderen WLAN, im Mobilfunknetz oder zu Hause ist, ist der Link für ihn tot.

Hinweis: Wenn der Befehl sauber läuft und das andere Gerät trotzdem keine Verbindung bekommt, ist es fast immer die Firewall des Betriebssystems, nicht der Befehl. Apples Firewall-Dokumentation sagt, macOS zeigt für eine noch nicht erlaubte App einen Hinweis an und verweigert die Verbindung, bis du handelst. Windows fragt stattdessen, welches Netzwerkprofil gilt, und hält getrennte Regeln für private und öffentliche Netzwerke vor. Wähle in einem Heim- oder Büronetzwerk „Privat“. Niemals „Öffentlich“.

Leg sie hinter einen Tunnel

Ein Tunnel ist ein kleines Programm, das neben deiner App läuft und ihr eine öffentliche HTTPS-Adresse gibt. Ein Befehl liefert dir in etwa einer Minute einen kostenlosen Tunnel zu localhost, und du solltest vorab wissen, dass die URL in dem Moment stirbt, in dem dieser Befehl endet:

cloudflared tunnel --url http://localhost:3000

An deinem Router ändert sich nichts, wegen der Richtung, in der die Verbindung läuft. Dein Rechner öffnet eine ausgehende Verbindung zum Edge des Anbieters, dieselbe Art, die dein Browser zum Laden jeder Seite aufbaut, und der Anbieter hält sie offen und schiebt eingehende Anfragen darüber zurück. Eingehende Ports bleiben bei dir geschlossen, und deshalb funktioniert das im Hotel-WLAN, über den Smartphone-Hotspot und an einem Heimanschluss, dessen Router du nicht kontrollierst.

Hinweis: Dieser letzte Fall verdient einen 60-Sekunden-Check, bevor du stattdessen Portweiterleitung in Betracht ziehst. Öffne die Statusseite deines Routers, such die dort angezeigte WAN-IP und vergleiche sie mit deiner tatsächlichen öffentlichen IP aus einer beliebigen „Wie ist meine IP“-Abfrage. Liegt die WAN-IP innerhalb von 100.64.0.0/10, ist CGNAT die wahrscheinliche Ursache. Unterscheiden sich WAN-IP und öffentliche IP nur, weißt du, dass es vorgelagert eine weitere NAT-Schicht gibt, aber das kann CGNAT oder gewöhnliches doppeltes NAT sein. In beiden Fällen reicht Portweiterleitung an diesem Router allein womöglich nicht. Dieser Bereich ist durch RFC 6598 als Shared Address Space reserviert, und genau dahinter setzt dich dein Provider, wenn ihm die Adressen ausgehen.

Die Optionen unterscheiden sich vor allem darin, was sie zuerst von dir wollen.

Cloudflare Quick Tunnels sind der Befehl oben: kein Konto, keine Domain, eine zufällige trycloudflare.com -Subdomain. Cloudflare begrenzt sie auf 200 gleichzeitig laufende Anfragen, darüber gibt es 429er, unterstützt keine Server-Sent Events und sagt in derselben Dokumentation, dass kostenlose Tunnel für Tests und Entwicklung gedacht sind, nicht für den Betrieb einer Produktionswebsite.

ngrok verlangt zuerst eine Registrierung, dann ngrok http 3000. Der aktuelle kostenlose Tarif gibt dir einmalig 5 $ inkludierte Nutzung, die sich nicht monatlich erneuert, bis zu 3 Online-Endpunkte, 1 GB Transfer, 20.000 HTTP/S-Anfragen und eine Warnseite, die dein Besucher wegklicken muss. Außerdem bekommst du eine kostenlose, automatisch zugewiesene Entwicklungsdomain, die ngrok 2023 angekündigt hat , um die alte Klage über die bei jedem Neustart wechselnde URL zu beenden.

localtunnel braucht weder Registrierung noch Installation über npx hinaus: npx localtunnel --port 3000. Du bekommst eine zufällige Subdomain, und die README sagt ausdrücklich, dass --subdomain einen Namen anfragt, ihn aber nicht garantiert.

localhost.run installiert nichts, weil es den SSH-Client nutzt, den dein Betriebssystem ohnehin mitbringt: ssh -R 80:localhost:3000 localhost.run. Die Dokumentation merkt an, dass kein Download nötig ist und dass für kostenlose Domains keine Kontoeinrichtung erforderlich ist.

VS Code hat das im Ports-Panel, praktisch, wenn du ohnehin im Editor lebst. Es verlangt eine GitHub- oder Microsoft-Anmeldung, und der Standardwert wird dir ein Bein stellen: ein weitergeleiteter Port ist privat, was bedeutet, dass dein Besucher aufgefordert wird, sich mit deinem Konto anzumelden, bis du den Port auf öffentlich umstellst. (Fein für einen Teamkollegen. Nutzlos für den Kunden, der einfach nur auf einen Link klicken will.)

Tailscale Funnel kann das ebenfalls, mit zwei Einschränkungen, die es meist entscheiden: Die URL kann nur auf der Domain deines eigenen Tailnets liegen, und es kann nur auf den Ports 443, 8443 und 10000 lauschen.

Egal, was du wählst: Sei dir im Klaren darüber, was du herausgegeben hast. Bei einem öffentlichen Tunnel ohne Zugriffskontrolle ist alles, was der Dev-Server ausliefert, für jeden mit dieser URL erreichbar, einschließlich Routen, die du nie verlinkt hast, und jeder Debug-Oberfläche, die du angelassen hast. Fein für eine Fünfzehn-Minuten-Demo. Deutlich weniger fein für eine URL, die du in einen öffentlichen Discord postest.

Das Ablaufen erwischt dich kalt, weil es aussehen kann, als wäre die App kaputt. Die meisten der schnellen Wege hier hängen weiterhin von Tunnel-Software auf deinem Laptop ab: Beende cloudflared, ngrok, localtunnel oder die SSH-Sitzung von localhost.run, und die Weiterleitung stoppt. Tailscale Funnel ist die Ausnahme, wenn du es mit --bgstartest, was die Funnel-Konfiguration im Hintergrund laufen lässt und nach einem Neustart wiederherstellt. Keiner davon kann deine lokale App ausliefern, während der Laptop selbst offline ist. Du kannst einen Tunnel tagelang laufen lassen, und er funktioniert genau so lange, bis der Deckel zugeht oder du das Anfragelimit erreichst.

Ein Tunnel ist das richtige Werkzeug für eine Demo und das falsche fürs Hosting: Seine Verfügbarkeit ist die deines Laptops.

Lass die App deinen Rechner verlassen

Das ist der erste Weg, bei dem dein Laptop nicht mehr tragend ist, und der erste, bei dem die Bedingungen mehr zählen als das Werkzeug. Was ihn hier beendet, ist keine Uhr. Es ist ein Spin-down, ein Zurücksetzen des Dateisystems oder ein Tarif, der entscheidet, dass deine App nicht das ist, was er auf einer kostenlosen Instanz haben will.

Die Optionen unten reichen von dauerhaft kostenlosen Tarifen bis zu kurzen Testphasen. Manche halten eine App innerhalb ihrer Grenzen unbegrenzt online; andere stoppen nach einer festen Testphase oder verlangen für Rechenleistung ein kostenpflichtiges Konto. Prüfe vor dem Deployment die Regeln zu Abrechnung, Ruhezustand und Speicher.

Die Bedingungen der kostenlosen Tarife unten wurden am 7. September 2026 auf der jeweiligen Preis- oder Dokumentationsseite des Anbieters geprüft.

„Nicht angegeben“ heißt, dass die Seiten des Anbieters selbst die Frage für den kostenlosen Tarif nicht beantworten. Behandle es als unbekannt, nicht als Ja oder Nein.

Drei dieser Zeilen verdienen vor dem Start einen zweiten Blick. Fly.io hat keinen dauerhaft kostenlosen Tarif: Der Test endet nach 2 Maschinenstunden oder 7 Tagen. Koyeb bietet eine kostenlose Instanz, aber Registrierung und Abrechnung verlangen vor dem Deployment Aufmerksamkeit. Hugging Face hält Static Spaces kostenlos, während neue Gradio- und Docker-Spaces ein kostenpflichtiges Konto verlangen, abgesehen von der begrenzten ZeroGPU-Ausnahme. Railway gehört nicht mehr auf diese Warnliste: Nach dem 30-tägigen Test mit 5 $ Guthaben wechselt es jetzt in einen Free-Tarif für 0 $ mit 1 $ Ressourcen-Guthaben pro Monat.

Dann ist da die Datenfrage, an der eine funktionierende App still zu einer kaputten wird. Renders kostenlose Web Services laufen auf einem flüchtigen Dateisystem, und die Dokumentation sagt unverblümt, dass alles, was dort geschrieben wird, hochgeladene Bilder und lokale SQLite-Datenbanken ausdrücklich eingeschlossen, bei jedem Redeploy, Neustart und Spin-down verloren geht. Vercels Functions laufen auf einem schreibgeschützten Dateisystem mit nur einem temporären Arbeitsbereich, sodass eine von deiner App geschriebene SQLite-Datei dort ebenfalls nicht sicher ist. Wenn deine App ihren Zustand in einer Datei hält, verschiebe ihn in dauerhaften Speicher: eine gehostete Datenbank, einen Objektspeicher oder ein persistentes Volume, wo die Plattform eines anbietet.

Den Spin-down solltest du einmal gespürt haben, bevor du dich festlegst. Im kostenlosen Tarif von Render schicken 15 Minuten Inaktivität den Dienst schlafen, und die nächste Anfrage weckt ihn über etwa eine Minute mit einer Ladeseite wieder auf, für denjenigen, der auf deinen Link geklickt hat. Bei einem Portfolio-Projekt ein Schulterzucken. Bei einem Kunden, der den Link im Call öffnet, sechzig schlechte Sekunden.

PythonAnywhere hat eine subtilere Variante der Falle. Es gibt keinen Spin-down bei Inaktivität, aber eine kostenlose Web-App läuft nach einem Monat ab und stoppt, sofern du nicht auf den Verlängerungslink klickst, den PythonAnywhere dir per E-Mail schickt, und kostenlose Konten haben eingeschränkten ausgehenden Internetzugang und erreichen nur eine Allowlist externer Hosts. Eine App, die eine API außerhalb dieser Liste aufruft, ist dann tadellos online und scheitert bei jeder Anfrage an diese nicht freigegebene API (grauenhaft zu debuggen, weil nirgends etwas ausgefallen aussieht).

Liefere sie als statische Site aus

Wenn nichts, was deine App tut, zur Anfragezeit Servercode braucht, ist ein statischer Host hier die Option, die „Einrichten und Vergessen“ am nächsten kommt: Sie bleibt ohne deinen Laptop online, und es wartet kein App-Prozess darauf, geweckt zu werden. Konto und Nutzungsgrenzen des Hosts gelten weiterhin. Mehr Apps kommen dafür infrage, als du erwarten würdest, und darum lohnt es sich, die erste dieser drei Fragen zu beantworten, bevor du annimmst, dass du einen serverseitigen Host brauchst.

Die Regel ist enger als „Hat sie ein Backend?“. Deine App kommt infrage, wenn jede Anfrage, die sie stellt, entweder an deine eigenen statischen Dateien geht oder direkt vom Browser an die API von jemand anderem. Supabase oder eine öffentliche API aus dem Browser abzurufen ist in Ordnung, mit dem einen Vorbehalt, dass ein Schlüssel im Browser-Code ein Schlüssel ist, den du veröffentlicht hast. Die Tür schließt sich, wenn dein eigener Code für jede Anfrage auf einem Server laufen muss.

Wenn sie infrage kommt, ist der Ablauf kurz:

npm run build   # Vite writes to dist/, a Next.js static export writes to out/

Dann stellst du diese Build-Ausgabe auf einem statischen Host bereit. Cloudflare Pages, Netlify und Vercel können aus einem verbundenen Repository bauen. GitHub Pages kann statische Dateien aus einem Branch veröffentlichen oder per GitHub Actions den Build deines Frameworks ausführen und die erzeugte Ausgabe bereitstellen.

GitHub Pages hat Einschränkungen, die scharf genug sind, um von Anfang an zu zählen. Nur statisch, eine Benutzer- oder Organisations-Site pro Konto, und Nutzungsgrenzen, die festhalten, dass es kein kostenloses Hosting für ein Unternehmen, einen E-Commerce-Shop oder kommerzielles SaaS ist. Wenn deine App Zahlungen entgegennehmen soll, scheidet das aus, bevor du anfängst.

Dieser Weg kennt kein Ablaufen eines App-Prozesses. Er funktioniert weiter, solange das Hosting-Konto aktiv und innerhalb seiner Grenzen bleibt, und er passt nicht mehr, sobald die App zur Anfragezeit serverseitige Arbeit braucht.

Wo die kostenlosen Wege enden

Die kostenlosen Wege scheitern an unterschiedlichen Stellen, nicht alle auf einmal. Ein statischer Host löst die Laptop-Verfügbarkeit bereits und gibt dir eine stabile Anbieter-URL. Ein kostenloser App-Host kann dasselbe, und manche bieten inzwischen persistenten Speicher. Ein VPS beginnt Sinn zu ergeben, wenn sich die Anforderungen stapeln: Dein eigener serverseitiger Prozess muss online bleiben, du brauchst verlässlichen persistenten Speicher, und die Ressourcen- oder Nutzungsregeln des kostenlosen Tarifs passen nicht mehr.

Diese Schwelle sollte man respektieren. Eine Demo ist kein Grund, einen Server zu kaufen, und ein statisches Projekt mit wenig Traffic auch nicht. Bleib beim Tunnel fürs kurzfristige Teilen, bleib beim statischen Host, solange die App wirklich statisch ist, und bleib beim kostenlosen App-Host, solange seine Grenzen zu dem passen, was du betreibst.

Wechsle zu einem VPS, wenn du einen dauerhaft laufenden Server brauchst, den du kontrollierst, und bereit bist, die damit verbundene Betriebsarbeit zu übernehmen. Unser Linux VPS ist eine Option, und ein vergleichbarer VPS eines anderen Anbieters erledigt denselben Job. Dimensioniere den Server für die App, statt anzunehmen, dass der kleinste Tarif reicht.

Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.

Linux-Pläne ansehen

Zwei Dinge ändern sich, sobald du das tust. Der Push-to-Git-Deployment-Workflow, den dir ein Plattform-Host gegeben hat, ist nicht mehr automatisch. Du kannst ihn mit einem selbst gehosteten PaaS wie Coolify oder Dokkunachbauen oder deinen eigenen CI/CD-Pfad aufsetzen, und so oder so gehören Updates und Wartung jetzt dir.

Die andere Änderung: Die Kiste beherbergt mehr als die App. Sie wird gern Code Server und Claude Code ausführen , falls du lieber auch deinen Editor dort wohnen lässt, was je nach Person entweder ein netter Bonus oder ein komplett neues Wochenende ist.

LESEN

Die besten selbstgehosteten Heroku- und Vercel-Alternativen: Coolify, Dokku und mehr

Häufig gestellte Fragen