Deploye deinen Vite- oder React-Build aus dem dist-Ordner

Ein moderner Frontend-Build ist per Design ein Ordner mit statischen Dateien, genau das ist der Sinn des Build-Schritts. Vite, Create React App, Vue CLI, der statische Adapter von SvelteKit und Astro erzeugen alle eine index.html plus fingerprinted JS/CSS-Bundles und deine Assets. Zum Ausliefern brauchst du keinen Server, nur einen Ort für die Dateien. Diesen Ordner zu zippen und hier hochzuladen ist der kürzeste Weg von npm run build zu einer öffentlichen URL, ohne CI, ohne Deploy-Konfiguration und ohne etwas zu installieren.

Verschiedene Tools benennen den Ausgabeordner unterschiedlich: Vite schreibt dist/, Create React App schreibt build/, ein statischer Next- oder Nuxt-Export schreibt out/, Jekyll und 11ty schreiben _site/ und public/. Du musst dir nicht merken, welches, wenn dein ZIP einen dieser Ordner enthält (oder einen einzelnen umschließenden Ordner vom Komprimieren auf dem Desktop), erkennen wir das echte Web-Root und servieren von dort. Zippe die gebaute Ausgabe statt deines Quellcodes; ein rohes Projekt ohne Build hochzuladen wird nicht gerendert, und wir sagen dir Bescheid, wenn wir keine index.html finden.

Single-Page-Apps routen im Browser: /dashboard und /settings werden von React Router oder Vue Router verarbeitet, nicht von separaten HTML-Dateien. Das bedeutet, ein Besucher, der einen Deep-Link direkt öffnet, oder eine innere Seite neu lädt, braucht vom Server die index.html zurück, damit sein Router übernehmen kann. Aktiviere den Single-Page-App-Modus, und genau das passiert: unbekannte Pfade fallen mit einem 200 auf index.html zurück, sodass Neuladen und geteilte Deep-Links funktionieren statt einen 404 zu zeigen. Lass ihn für eine normale Multi-Page-Site deaktiviert, dann liefern unbekannte Pfade einen echten 404 (oder deine eigene 404.html).

Gute Build-Tools versehen deine Bundles mit einem Fingerprint, app.4f3a9c2b.js, genau damit sie für immer gecacht werden können. Das respektieren wir: Assets mit Content-Hash werden mit einem ein Jahr gültigen, unveränderlichen Cache ausgeliefert, sodass wiederholte Besuche sofort laden, während deine index.html ohne Cache ausgeliefert wird, damit ein erneuter Upload sofort sichtbar ist. So bekommst du die Performance von aggressivem Caching, ohne in die klassische Falle einer veralteten HTML-Datei zu tappen, die auf nicht mehr existierende Bundles zeigt. Bringe einen neuen Build heraus, indem du ein neues ZIP hochlädst; die URL bleibt gleich, und Besucher bekommen beim nächsten Laden die neue Version.

Ein Build auf einer beliebigen URL ist für eine Vorschau in Ordnung, aber eine echte App will eine echte Adresse. Mit Pro verbindest du deine Domain oder Subdomain, und wir richten HTTPS automatisch ein, keine Zertifikatseinrichtung, keine Verlängerungen. Das macht dies zu einem legitimen Zuhause für ein kleines Produktions-Frontend: ein internes Tool, eine Marketing-Site, eine Docs-App, ein Kundenprojekt. Alles, was der Browser braucht, um deine App auszuführen, wird korrekt ausgeliefert; es gibt nur kein Backend, das ist die ehrliche Grenze von statischem Hosting.

Das hier liefert nur deine gebauten statischen Dateien aus, sonst nichts: kein Server-Side-Rendering zur Laufzeit, keine API-Routen, keine Datenbank. Wenn deine App eine externe API aus dem Browser über HTTPS aufruft, funktioniert das weiterhin. Wenn sie von Server-Code abhängt, pro Request gerenderte Next.js-Server-Components, SvelteKit-Endpoints, auf dem Server gelesene Umgebungsvariablen, brauchst du eine Plattform, die diesen Server ausführt, und solltest einen vollständig statischen Build exportieren oder anderswo hosten. Ganz einfach gesagt: bring deine gebaute Ausgabe mit und bekomm ein schnelles statisches Hosting; bring eine serverabhängige App mit, und statisches Hosting ist das falsche Werkzeug.