Welchen Ordner zippe ich — dist, build oder out?

Welchen auch immer dein Tool erzeugt: dist/ bei Vite, build/ bei Create React App, out/ bei einem statischen Export. Du kannst auch das ganze Projekt zippen — wir erkennen den Ausgabeordner (dist/build/out/public/_site) und servieren von dort, du musst also nicht exakt sein.

Laden meine gehashten JS- und CSS-Bundles korrekt?

Ja. Jedes Asset wird mit genau dem MIME-Type ausgeliefert, den der Browser braucht — text/javascript für JS, text/css für CSS, font/woff2 für Schriften — und Bundles mit Content-Hash bekommen einen ein Jahr gültigen, unveränderlichen Cache, während HTML ohne Cache bleibt, sodass Updates sofort sichtbar sind.

Wie bringe ich Client-Side-Routing zum Laufen?

Aktiviere den Single-Page-App-Modus. Unbekannte Pfade fallen dann mit einem 200 auf deine index.html zurück, sodass Deep-Links und Neuladen von deinem Router (React Router, Vue Router und so weiter) aufgelöst werden, statt einen 404 zu liefern.

Kann ich einen statischen Next.js- oder Nuxt-Export deployen?

Ja, wenn du einen vollständig statischen Build exportierst (den out/-Ordner). Alles, was zur Laufzeit einen laufenden Server braucht — pro Request gerenderte Server-Components, API-Routen, Server-Middleware — liegt außerhalb dessen, was statisches Hosting kann; exportiere eine statische Ausgabe oder hoste auf einer Plattform, die den Server ausführt.

Wie veröffentliche ich ein Update?

Führe deinen Build erneut aus, zippe die Ausgabe und lade sie hoch — dieselbe URL liefert die neue Version, sodass geteilte Links weiter funktionieren. Es gibt keine CI-Pipeline und keinen Redeploy-Befehl; das Ersetzen des ZIPs ersetzt die Site.

Kann ich meine eigene Domain nutzen?

Ja, mit Pro. Verbinde eine Domain oder Subdomain mit deiner Site mit automatischem SSL, sodass Besucher deine Adresse in der URL-Leiste sehen. Im Gratis-Tarif liegt die Site unter einer linkinseconds.com-Adresse.

Welche Größen- und Dateilimits gibt es?

Statisches Site-Hosting ist eine Pro-Funktion. Pro-Sites fassen bis zu 500 Dateien und 100 MB insgesamt; Lifetime erhöht das. Jede Site wird von einem eigenen isolierten Origin ausgeliefert, sodass das JavaScript deiner App vollständig von unserem getrennt ist.

Vite- oder React-Build als Site deployen

Deploye deinen Vite- oder React-Buildaus dem dist-Ordner

Du hast den Build ausgeführt und einen dist/-Ordner mit statischen Dateien bekommen. Zippe ihn, lade ihn hier hoch, und deine App ist live — gehashte Assets werden korrekt gecacht, Client-Side-Routen funktionieren, ganz ohne Deploy-Pipeline.

your file hier ablegen

Leg gleich mehrere ab — daraus wird ein Album-Link

Bis 100 MB gratis

Gratis: 20 Links, bis 100 MB · Pro: unbegrenzte Links, größere Uploads

Deinen Build in vier Schritten deployen

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, ein Bundle aus gehashtem JavaScript und CSS in einem assets/-Ordner sowie deine Bilder und Schriften. Dieser Ordner ist eine vollständige statische Site.

Ausgabeordner zippen

Komprimiere die Build-Ausgabe — dist/ bei Vite, build/ bei Create React App, oder out/ bei einem statischen Export — zu einer .zip-Datei. Du kannst auch das ganze Projekt zippen; wir erkennen den Ausgabeordner und servieren von dort, du musst also nicht exakt sein.

ZIP hochladen

Ziehe die .zip-Datei auf die Karte. Wir packen sie aus, finden deine index.html und liefern jede Datei mit dem richtigen Content-Type aus — text/javascript für dein Bundle, text/css für deine Styles, font/woff2 für deine Schriften — genau das, was der Browser braucht, um die App auszuführen.

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.