Hébergement d’export statique Next.js

Next.js peut construire un site qui n’a pas besoin de serveur : réglez output: "export" et next build écrit chaque page en HTML dans out/. Lobsite héberge ce dossier. Lancez npm run build, puis npx lobsite, et le site est en ligne à une adresse *.lobsite.app en HTTPS. Pour être clair dès le départ : cette page concerne les exports statiques. Le rendu serveur, les routes d’API et le middleware nécessitent un hébergeur Node.js comme Vercel.

Comment ça marche

1. Activez l’export statique dans next.config.js avec output: "export" (voir ci-dessous), puis lancez npm run build. Le site arrive dans out/.
2. Lancez npx lobsite dans le projet. Il déploie out/, pas public/ ni .next/. Le premier déploiement ne demande pas de compte et dure 6 heures.
3. Gardez-le grâce au lien de récupération, dans un compte gratuit. Ensuite, chaque npm run build && npx lobsite met à jour la même adresse.

next.config.js pour un export statique

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "export",
  images: { unoptimized: true },
};

module.exports = nextConfig;

• output: "export" fait écrire out/ par next build. L’ancienne commande next export a disparu depuis Next.js 14 ; ce réglage l’a remplacée.
• images: { unoptimized: true } est nécessaire si vous utilisez next/image : le loader par défaut redimensionne les images sur un serveur à chaque requête. Avec ce réglage, les images sont servies telles quelles ; redimensionnez-les avant le build, ou utilisez un loader personnalisé.
• trailingSlash peut rester désactivé. Les pages sont écrites en about.html, et Lobsite les sert à /about.

Ce qu’un export statique ne sait pas faire

La documentation de Next.js liste les fonctionnalités qui exigent un serveur. Celles qu’on rencontre le plus :

• Routes d’API et Route Handlers autres que les GET statiques. Envoyez plutôt les formulaires vers /_lobsite/forms/contact ; voir formulaires.
• redirects, rewrites et headers dans next.config. Déplacez redirections et en-têtes dans lobsite.toml, où ils s’appliquent à chaque requête ; le Générateur de redirections écrit les règles.
• Middleware, Server Actions, ISR, et cookies() ou headers() dans les pages.
• Routes dynamiques sans generateStaticParams : chaque page doit être connue au moment du build.

Si votre application en dépend, ce n’est pas un site statique, et un hébergeur qui exécute Next.js sur un serveur est le bon choix.

Hébergeurs Next.js comparés

Vercel crée Next.js et en exécute tout. Pour un site vitrine, un blog ou une documentation construits en export statique, Lobsite est l’hébergeur le plus simple : une commande, seuls les fichiers modifiés envoyés, une URL d’aperçu pour chaque déploiement.

Questions fréquentes

Puis-je héberger ici une application Next.js avec rendu côté serveur ?

Non. Lobsite sert des fichiers, donc seul un export statique fonctionne. Si des pages utilisent getServerSideProps, des Server Actions ou un rendu dynamique, hébergez-la là où Next.js tourne sur un serveur.

Pourquoi mes images next/image sont-elles cassées après l’export ?

Le loader d’images par défaut a besoin d’un serveur. Ajoutez images: { unoptimized: true } à next.config.js, ou réglez un loader personnalisé qui pointe vers un CDN d’images, puis rebuildez.

Ma page 404 Next.js fonctionne-t-elle ?

Oui. next build écrit 404.html à partir de votre page not-found (App Router) ou de pages/404 (Pages Router), et Lobsite la sert pour toute adresse inexistante.

Puis-je utiliser l’App Router avec un export statique ?

Oui. Les Server Components sont rendus au build ; les composants client s’exécutent dans le navigateur comme d’habitude. Seules les fonctionnalités qui exigent une requête à l’exécution sont exclues.