Aktualisiert am 6. Okt. 2026 ## Wie deploye ich einen Vite- oder React-Build ohne Server? Um einen Vite- oder React-Build zu deployen, führe npm run build aus, zippe den Ausgabeordner (dist/, build/ oder out/) und lege ihn in das Upload-Feld oben. Wir packen ihn aus, finden deine index.html und liefern jede Datei mit dem richtigen Content-Type unter einer sauberen URL aus, gehashte Assets hart gecacht, Client-Side-Routen funktionieren, eigene Domain und SSL mit Pro, ohne CI und ohne Deploy-Konfiguration. ### Dein Build ist bereits eine statische Site Ein moderner Frontend-Build ist per Design ein Ordner mit statischen Dateien. Vite, Create React App, Vue CLI, der statische Adapter von SvelteKit und Astro erzeugen alle eine index.html plus fingerprinted Bundles. Diesen Ordner zu zippen und hier hochzuladen ist der kürzeste Weg von npm run build zu einer öffentlichen URL, ohne CI und ohne etwas zu installieren. [Statische Website hosten](https://linkinseconds.com/de/host-static-website) ### Client-Side-Routing, das funktioniert Single-Page-Apps routen im Browser: /dashboard und /settings werden von React Router oder Vue Router verarbeitet, nicht von separaten HTML-Dateien. Aktiviere den Single-Page-App-Modus, und unbekannte Pfade fallen mit einem 200 auf index.html zurück, sodass Deep-Links und Neuladen funktionieren statt einen 404 zu zeigen. ### Gehashte Assets hart gecacht, HTML nie veraltet Bundles 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. 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. [HTML-ZIP veröffentlichen](https://linkinseconds.com/de/publish-html-zip) ### Auf deiner eigenen Domain, mit SSL 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 und 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. [HTML-Hosting](https://linkinseconds.com/de/html-hosting) ### Was das Deployen eines Builds hier nicht macht Kein Server, keine API-Routen, keine Datenbank. Das hier liefert nur deine gebauten statischen Dateien aus, sonst nichts, alles, was zur Laufzeit einen laufenden Server braucht, liegt also außerhalb des Rahmens. Kein Server-Rendering pro Request. Pro Request gerenderte Next.js-Server-Components, SvelteKit-Endpoints und Server-Secrets brauchen eine Plattform, die diesen Server ausführt; exportiere stattdessen einen vollständig statischen Build. Kein Build-Schritt auf unserer Seite. Lade die gebaute Ausgabe hoch, nicht deinen Quellcode; ein Projekt ohne Build wird nicht gerendert, und wir sagen dir Bescheid, wenn wir keine index.html finden. Dein ZIP kann mit kostenloser Anmeldung bis 250 MB und mit Pro bis 500 MB groß sein. ## So funktioniert's - 1 ### App bauen Führe deinen Production-Build aus, npm run build für Vite/React/Vue/Svelte, oder das Äquivalent deines Tools. Er schreibt einen Ordner mit statischen Dateien: eine index.html, gehashtes JavaScript und CSS in einem assets/-Ordner sowie deine Bilder und Schriften. Dieser Ordner ist eine vollständige statische Site. - 2 ### Ausgabe zippen und hochladen Komprimiere die Build-Ausgabe, dist/ bei Vite, build/ bei Create React App, oder out/ bei einem statischen Export, zu einer .zip-Datei und ziehe sie auf die Karte. Wir packen sie aus, finden deine index.html und liefern jede Datei mit dem richtigen Content-Type aus, du musst also nicht exakt beim Ordner sein. - 3 ### SPA-Modus aktivieren und Domain hinzufügen Wenn deine App Client-Side-Routing nutzt, aktiviere den Single-Page-App-Modus, damit Deep-Links zu deiner index.html aufgelöst werden statt einen 404 zu liefern. Mit Pro verbindest du deine eigene Domain mit automatischem SSL. Lade nach deinem nächsten Build erneut hoch, um ein Update auf dieselbe URL zu bringen. ## Dein Build ist bereits eine statische Site 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. ## Zippe dist/ (oder build/, oder out/), wir finden es 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. ## Client-Side-Routing, das wirklich funktioniert 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). ## Gehashte Assets hart gecacht, HTML nie veraltet 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. ## Auf deiner eigenen Domain, mit SSL 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. ## Nur statisch, wo ein Backend gebraucht wird, ist das hier falsch 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. index.htmlHTML dist.zipZIP app.4f3a9c.jsHTML dashboard-routeHTML build.zipZIP index.htmlHTML dist.zipZIP app.4f3a9c.jsHTML dashboard-routeHTML build.zipZIP index.htmlHTML dist.zipZIP app.4f3a9c.jsHTML dashboard-routeHTML build.zipZIP index.htmlHTML dist.zipZIP app.4f3a9c.jsHTML dashboard-routeHTML build.zipZIP landing-pageHTML settings-routeHTML out.zipZIP docs-appHTML styles.a1b2.cssHTML landing-pageHTML settings-routeHTML out.zipZIP docs-appHTML styles.a1b2.cssHTML landing-pageHTML settings-routeHTML out.zipZIP docs-appHTML styles.a1b2.cssHTML landing-pageHTML settings-routeHTML out.zipZIP docs-appHTML styles.a1b2.cssHTML 2,600+ Menschen teilen Dateien 5,000+ geteilte Links 17,300+ Mal geöffnet Weiterlesen [KI-generiertes HTML hosten](https://linkinseconds.com/de/host-ai-generated-html)[Statische Website hosten](https://linkinseconds.com/de/host-static-website)[HTML-ZIP veröffentlichen](https://linkinseconds.com/de/publish-html-zip)[HTML-Hosting](https://linkinseconds.com/de/html-hosting)[Tiiny-Host-Alternative](https://linkinseconds.com/de/tiiny-host-alternative) Source: https://linkinseconds.com/de/deploy-vite-react-build