Quelles options de déploiement et quels résultats de build Next.js supporte-t-il ?

Question

Accepted Answer

Next.js supporte plusieurs cibles de déploiement, contrôlées en partie par la config **`output`**. Le bon choix dépend de la nécessité d'avoir le serveur Node, des conteneurs, ou de l'hébergement purement statique.

## Les modes de résultat de build

```js
// next.config.js
module.exports = {
  // output: undefined  → default: needs a Node.js server (full features)
  // output: "standalone" → self-contained folder for Docker/containers
  // output: "export"     → pure static HTML/CSS/JS (no server)
};
```

## 1. Défaut (serveur Node) — toutes les fonctionnalités

Exécute un serveur Node.js, donc vous obtenez **tout** : SSR, ISR, Server Actions, Route Handlers, optimisation d'image, middleware. C'est ce que les plateformes comme **Vercel** (le créateur de Next.js, zéro configuration) et les hôtes Node utilisent.

## 2. output: "standalone" — pour Docker / auto-hébergement

```dockerfile
# Next traces only the needed files into .next/standalone → a tiny, self-contained server
COPY --from=builder /app/.next/standalone ./
CMD ["node", "server.js"]
```

`standalone` produit un dossier minimal avec seulement les dépendances réellement utilisées, idéal pour les petites images Docker sur AWS, GCP, vos propres serveurs, etc. Vous conservez toutes les fonctionnalités serveur.

## 3. output: "export" — entièrement statique

```text
next build → out/  (plain HTML/CSS/JS, deployable to any static host: S3, GitHub Pages, Netlify CDN)
```

L'export statique offre l'hébergement le moins cher et le plus simple, mais **désactive les fonctionnalités serveur** : pas de SSR, pas de ISR, pas de Route Handlers, pas de Server Actions, pas d'optimisation d'image à la volée. Convient uniquement pour les sites entièrement statiques.

## Choisir

```text
Need SSR/ISR/Server Actions, want zero-config → Vercel (or a Node host) — default output
Want containers / self-host with full features → output: "standalone" + Docker
Purely static content (docs, marketing)        → output: "export" → any static CDN
```

## Autres considérations

```text
- Runtime choice (Edge vs Node) affects where functions run
- Self-hosting ISR/caching needs persistent storage or a shared cache
- Image optimization on non-Vercel hosts may need a custom loader
```

## Pourquoi c'est important

Le déploiement n'est pas un standard unique : le mode `output` détermine quelles fonctionnalités Next.js survivent.

Savoir que la sortie **défaut/Node** conserve toutes les capacités serveur, que **standalone** les empaquette pour Docker/auto-hébergement, et que **export** sacrifie toutes les fonctionnalités serveur pour un hébergement purement statique vous permet de adapter le build à votre infrastructure — et d'éviter le piège de `output: "export"` qui casse silencieusement SSR/ISR/Server Actions.