Mes bundles JS et CSS hachés se chargent-ils correctement ?

Oui. Chaque asset est servi avec le type MIME exact requis par le navigateur — text/javascript pour le JS, text/css pour le CSS, font/woff2 pour les polices — et les bundles avec hash de contenu obtiennent un cache immuable d'un an, tandis que le HTML reste sans cache, si bien que les mises à jour s'affichent immédiatement.

Comment faire fonctionner le routage côté client ?

Activez le mode SPA. Les chemins inconnus retombent alors sur votre index.html avec un code 200, si bien que les liens profonds et les actualisations sont résolus par votre router (React Router, Vue Router, etc.) au lieu de renvoyer une 404.

Puis-je déployer un export statique Next.js ou Nuxt ?

Oui, si vous exportez un build entièrement statique (le dossier out/). Tout ce qui a besoin d'un serveur actif au moment de la requête — composants serveur rendus par requête, routes API, middleware serveur — dépasse le cadre de l'hébergement statique ; exportez une sortie statique ou hébergez sur une plateforme qui exécute le serveur.

Comment publier une mise à jour ?

Relancez votre build, compressez la sortie et importez-la — la même URL sert la nouvelle version, donc les liens que vous avez partagés continuent de fonctionner. Il n'y a ni pipeline CI ni commande de redéploiement ; remplacer le ZIP remplace le site.

Puis-je utiliser mon propre domaine ?

Oui, avec l'offre Pro. Connectez un domaine ou sous-domaine à votre site avec SSL automatique pour que les visiteurs voient votre adresse dans la barre d'URL. Avec l'offre gratuite, le site vit à une adresse linkinseconds.com.

Quelles sont les limites de taille et de fichiers ?

L'hébergement de sites statiques est une fonction Pro. Les sites Pro contiennent jusqu'à 500 fichiers et 100 MB au total ; l'offre à vie augmente cette limite. Chaque site est servi depuis sa propre origine isolée, si bien que le JavaScript de votre application est entièrement isolé du nôtre.

Déployer un build Vite ou React en tant que site

Q: Quel dossier dois-je compresser — dist, build ou out ?

Celui que produit votre outil : dist/ pour Vite, build/ pour Create React App, out/ pour un export statique. Vous pouvez aussi compresser tout le projet — nous détectons le dossier de sortie (dist/build/out/public/_site) et servons depuis celui-ci, pas besoin d'être exact.

Déployez votre build Vite ou Reactdepuis le dossier dist

Vous avez lancé le build et obtenu un dossier dist/ de fichiers statiques. Compressez-le en ZIP, déposez-le ici, et votre application est en ligne — les assets hachés sont mis en cache correctement, les routes côté client se résolvent, sans pipeline de déploiement.

Déposez your file ici

Déposez-en plusieurs d'un coup : ils deviennent un seul lien d'album

Jusqu'à 100 MB gratuit

Gratuit : 20 liens, jusqu'à 100 MB · Pro : liens illimités, fichiers plus volumineux

Déployez votre build en quatre étapes

Construisez votre application

Lancez votre build de production — npm run build pour Vite/React/Vue/Svelte, ou l'équivalent pour votre outil. Il génère un dossier de fichiers statiques : un index.html, un bundle de JavaScript et CSS hachés dans un dossier assets/, ainsi que vos images et polices. Ce dossier est un site statique complet.

Compressez le dossier de sortie

Compressez la sortie du build — dist/ pour Vite, build/ pour Create React App, ou out/ pour un export statique — dans un fichier .zip. Vous pouvez aussi compresser tout le projet ; nous détectons le dossier de sortie et servons le site depuis celui-ci, pas besoin d'être précis.

Importez le ZIP

Glissez le .zip sur la carte. Nous le décompressons, trouvons votre index.html et servons chaque fichier avec le bon type de contenu — text/javascript pour votre bundle, text/css pour vos styles, font/woff2 pour vos polices — exactement ce dont le navigateur a besoin pour exécuter l'application.

Activez le mode SPA et ajoutez votre domaine

Si votre application utilise le routage côté client, activez le mode SPA pour que les liens profonds se résolvent vers votre index.html au lieu de renvoyer une 404. Avec l'offre Pro, connectez votre propre domaine avec SSL automatique. Réimportez après votre prochain build pour publier une mise à jour sur la même URL.

Votre build est déjà un site statique

Un build front-end moderne est, par nature, un dossier de fichiers statiques — c'est tout l'intérêt de l'étape de build. Vite, Create React App, Vue CLI, l'adaptateur statique de SvelteKit et Astro produisent tous un index.html ainsi que des bundles JS/CSS avec empreinte et vos assets. Aucun serveur n'est nécessaire pour les servir ; il vous faut juste un endroit où déposer les fichiers. Compresser ce dossier et le déposer ici est le chemin le plus court entre npm run build et une URL publique, sans CI, sans configuration de déploiement et rien à installer.

Compressez dist/ (ou build/, ou out/) — nous le trouvons

Chaque outil nomme le dossier de sortie différemment : Vite écrit dist/, Create React App écrit build/, un export statique Next ou Nuxt écrit out/, Jekyll et 11ty écrivent _site/ et public/. Pas besoin de retenir lequel — si votre ZIP contient l'un de ces dossiers (ou un unique dossier englobant créé en compressant depuis le bureau), nous détectons la vraie racine web et servons depuis celle-ci. Compressez la sortie du build plutôt que votre code source ; importer un projet brut sans build ne s'affichera pas, et nous vous préviendrons si nous ne trouvons pas d'index.html.

Un routage côté client qui fonctionne vraiment

Les applications monopages routent dans le navigateur : /dashboard et /settings sont gérés par React Router ou Vue Router, pas par des fichiers HTML distincts. Cela signifie qu'un visiteur qui ouvre directement un lien profond — ou actualise une page interne — a besoin que le serveur renvoie index.html pour que son router prenne le relais. Activez le mode SPA et c'est exactement ce qui se passe : les chemins inconnus retombent sur index.html avec un code 200, si bien que les actualisations et les liens profonds partagés fonctionnent au lieu de renvoyer une 404. Laissez-le désactivé pour un site multipage classique et les chemins inconnus renvoient une vraie 404 (ou votre propre 404.html).

Assets hachés en cache longue durée, HTML jamais obsolète

Les bons outils de build ajoutent une empreinte à vos bundles — app.4f3a9c2b.js — justement pour pouvoir les mettre en cache indéfiniment. Nous respectons cela : les assets avec hash de contenu sont servis avec un cache immuable d'un an, si bien que les visites répétées sont instantanées, tandis que votre index.html est servi sans cache pour qu'un nouvel import s'affiche immédiatement. Vous obtenez la performance d'un cache agressif sans le piège classique d'un fichier HTML obsolète pointant vers des bundles qui n'existent plus. Publiez un nouveau build en déposant un nouveau ZIP ; l'URL reste la même et les visiteurs reçoivent la nouvelle version dès leur prochain chargement.

Sur votre propre domaine, avec SSL

Un build hébergé sur une URL aléatoire convient pour un aperçu, mais une vraie application veut une vraie adresse. Avec l'offre Pro, connectez votre domaine ou sous-domaine et nous provisionnons le HTTPS automatiquement — aucune configuration de certificat, aucun renouvellement. Cela en fait un foyer légitime pour un petit front-end de production : un outil interne, un site marketing, une application de documentation, un livrable client. Tout ce dont le navigateur a besoin pour exécuter votre application est servi correctement ; il n'y a simplement pas de backend, ce qui est la limite honnête de l'hébergement statique.

Statique uniquement — là où un backend est nécessaire, ce n'est pas la solution

Ceci sert uniquement vos fichiers statiques compilés, rien d'autre : pas de rendu côté serveur à la requête, pas de routes API, pas de base de données. Si votre application appelle une API externe depuis le navigateur en HTTPS, cela continue de fonctionner. Si elle dépend de code serveur — composants serveur Next.js rendus par requête, endpoints SvelteKit, secrets d'environnement lus côté serveur — il vous faut une plateforme qui exécute ce serveur, et vous devriez exporter un build entièrement statique ou héberger ailleurs. Dit simplement : apportez votre sortie compilée, obtenez un hébergement statique rapide ; apportez une application dépendante d'un serveur, et l'hébergement statique n'est pas le bon outil.