Déploiement

Félicitations, il est temps de passer en production.

Vous pouvez déployer Next.js managé avec Vercel, ou l'auto-héberger sur un serveur Node.js, une image Docker, ou même des fichiers HTML statiques. Lors d'un déploiement avec next start, toutes les fonctionnalités de Next.js sont prises en charge.

Builds de production

L'exécution de next build génère une version optimisée de votre application pour la production. Des fichiers HTML, CSS et JavaScript sont créés en fonction de vos pages. Le JavaScript est compilé et les bundles navigateur sont minifiés en utilisant le Next.js Compiler pour atteindre les meilleures performances et supporter tous les navigateurs modernes.

Next.js produit une sortie de déploiement standard utilisée par Next.js managé et auto-hébergé. Cela garantit que toutes les fonctionnalités sont supportées dans les deux méthodes de déploiement. Dans la prochaine version majeure, nous transformerons cette sortie en notre spécification Build Output API.

Next.js managé avec Vercel

Vercel, les créateurs et mainteneurs de Next.js, fournissent une infrastructure managée et une plateforme d'expérience développeur pour vos applications Next.js.

Le déploiement sur Vercel est sans configuration et offre des améliorations supplémentaires pour la scalabilité, la disponibilité et les performances à l'échelle mondiale. Cependant, toutes les fonctionnalités de Next.js sont toujours supportées en auto-hébergement.

Apprenez-en plus sur Next.js sur Vercel ou déployez un template gratuitement pour l'essayer.

Auto-hébergement

Vous pouvez auto-héberger Next.js de trois manières différentes :

• Un serveur Node.js
• Un conteneur Docker
• Une exportation statique

Serveur Node.js

Next.js peut être déployé sur n'importe quel hébergeur supportant Node.js. Assurez-vous que votre package.json contient les scripts "build" et "start" :

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

Ensuite, exécutez npm run build pour construire votre application. Enfin, exécutez npm run start pour démarrer le serveur Node.js. Ce serveur supporte toutes les fonctionnalités de Next.js.

Image Docker

Next.js peut être déployé sur n'importe quel hébergeur supportant les conteneurs Docker. Vous pouvez utiliser cette approche lors d'un déploiement sur des orchestrateurs de conteneurs comme Kubernetes ou lors d'une exécution dans un conteneur chez n'importe quel fournisseur cloud.

1. Installez Docker sur votre machine
2. Clonez notre exemple (ou l'exemple multi-environnement)
3. Construisez votre conteneur : docker build -t nextjs-docker .
4. Exécutez votre conteneur : docker run -p 3000:3000 nextjs-docker

Next.js via Docker supporte toutes les fonctionnalités de Next.js.

Exportation HTML statique

Next.js permet de démarrer comme un site statique ou une application monopage (SPA), puis de passer ultérieurement à des fonctionnalités nécessitant un serveur.

Puisque Next.js supporte cette exportation statique, elle peut être déployée et hébergée sur n'importe quel serveur web capable de servir des assets statiques HTML/CSS/JS. Cela inclut des outils comme AWS S3, Nginx ou Apache.

L'exécution en tant qu'exportation statique ne supporte pas les fonctionnalités de Next.js nécessitant un serveur. En savoir plus.

Bon à savoir :

• Les composants serveur (Server Components) sont supportés avec les exports statiques.

Fonctionnalités

Optimisation d'images

L'optimisation d'images via next/image fonctionne en auto-hébergement sans configuration lors d'un déploiement avec next start. Si vous préférez avoir un service séparé pour optimiser les images, vous pouvez configurer un loader d'images.

L'optimisation d'images peut être utilisée avec une exportation statique en définissant un loader d'images personnalisé dans next.config.js. Notez que les images sont optimisées à l'exécution, pas pendant la construction.

Bon à savoir :

• En auto-hébergement, envisagez d'installer sharp pour une optimisation d'images plus performante dans votre environnement de production en exécutant npm install sharp dans votre répertoire de projet. Sur les plateformes Linux, sharp peut nécessiter une configuration supplémentaire pour éviter une utilisation excessive de la mémoire.
• En savoir plus sur le comportement de cache des images optimisées et comment configurer le TTL.
• Vous pouvez aussi désactiver l'optimisation d'images tout en conservant les autres avantages de next/image si vous préférez. Par exemple, si vous optimisez vous-même les images séparément.

Middleware

Le middleware fonctionne en auto-hébergement sans configuration lors d'un déploiement avec next start. Puisqu'il nécessite un accès à la requête entrante, il n'est pas supporté lors d'une exportation statique.

Le middleware utilise un runtime qui est un sous-ensemble de toutes les API Node.js disponibles pour garantir une faible latence, puisqu'il peut s'exécuter devant chaque route ou asset de votre application. Ce runtime ne nécessite pas de fonctionner "à la périphérie" et fonctionne sur un serveur mono-région. Une configuration et une infrastructure supplémentaires sont nécessaires pour exécuter le middleware dans plusieurs régions.

Si vous souhaitez ajouter une logique (ou utiliser un package externe) nécessitant toutes les API Node.js, vous pourriez déplacer cette logique dans un layout en tant que composant serveur (Server Component). Par exemple, vérifier les en-têtes et rediriger. Vous pouvez aussi utiliser des en-têtes, cookies ou paramètres de requête pour rediriger ou réécrire via next.config.js. Si cela ne fonctionne pas, vous pouvez aussi utiliser un serveur personnalisé.

Variables d'environnement

Next.js peut supporter des variables d'environnement à la fois au moment de la construction et à l'exécution.

Par défaut, les variables d'environnement ne sont disponibles que sur le serveur. Pour exposer une variable d'environnement au navigateur, elle doit être préfixée par NEXT_PUBLIC_. Cependant, ces variables d'environnement publiques seront intégrées dans le bundle JavaScript pendant next build.

Pour lire les variables d'environnement à l'exécution, nous recommandons d'utiliser getServerSideProps ou d'adopter progressivement le routeur App. Avec le routeur App, nous pouvons lire en toute sécurité les variables d'environnement sur le serveur pendant le rendu dynamique. Cela vous permet d'utiliser une image Docker unique qui peut être promue à travers plusieurs environnements avec des valeurs différentes.

import { unstable_noStore as noStore } from 'next/cache';

export default function Component() {
  noStore();
  // cookies(), headers(), et autres fonctions dynamiques
  // activeront aussi le rendu dynamique, faisant
  // que cette variable d'environnement est évaluée à l'exécution
  const value = process.env.MY_VALUE
  ...
}

Bon à savoir :

• Vous pouvez exécuter du code au démarrage du serveur en utilisant la fonction register.
• Nous ne recommandons pas d'utiliser l'option runtimeConfig, car elle ne fonctionne pas avec le mode de sortie standalone. Nous recommandons plutôt d'adopter progressivement le routeur App.

Cache et ISR

Next.js peut mettre en cache les réponses, les pages statiques générées, les sorties de build et d'autres assets statiques comme les images, polices et scripts.

La mise en cache et la revalidation de pages (en utilisant la Régénération Statique Incrémentielle (ISR) ou les nouvelles fonctions du routeur App) utilisent le même cache partagé. Par défaut, ce cache est stocké sur le système de fichiers (sur disque) sur votre serveur Next.js. Cela fonctionne automatiquement en auto-hébergement avec les routeurs Pages et App.

Vous pouvez configurer l'emplacement du cache Next.js si vous souhaitez persister les pages et données en cache dans un stockage durable, ou partager le cache entre plusieurs conteneurs ou instances de votre application Next.js.

Cache automatique

• Next.js définit l'en-tête Cache-Control à public, max-age=31536000, immutable pour les assets vraiment immuables. Cela ne peut pas être modifié. Ces fichiers immuables contiennent un hash SHA dans leur nom, donc ils peuvent être mis en cache indéfiniment. Par exemple, les imports d'images statiques. Vous pouvez configurer le TTL pour les images.
• La Régénération Statique Incrémentielle (ISR) définit l'en-tête Cache-Control à s-maxage: <revalidate in getStaticProps>, stale-while-revalidate. Ce temps de revalidation est défini dans votre fonction getStaticProps en secondes. Si vous définissez revalidate: false, cela utilisera par défaut une durée de cache d'un an.
• Les pages rendues dynamiquement définissent un en-tête Cache-Control à private, no-cache, no-store, max-age=0, must-revalidate pour empêcher la mise en cache de données spécifiques à l'utilisateur. Cela s'applique aux routeurs App et Pages. Cela inclut aussi le mode Draft.

Assets statiques

Si vous souhaitez héberger des assets statiques sur un domaine ou CDN différent, vous pouvez utiliser la configuration assetPrefix dans next.config.js. Next.js utilisera ce préfixe d'asset lors de la récupération des fichiers JavaScript ou CSS. Séparer vos assets sur un domaine différent a l'inconvénient d'un temps supplémentaire passé sur la résolution DNS et TLS.

En savoir plus sur assetPrefix.

Configuration du cache

Par défaut, les assets de cache générés seront stockés en mémoire (50mb par défaut) et sur disque. Si vous hébergez Next.js en utilisant une plateforme d'orchestration de conteneurs comme Kubernetes, chaque pod aura une copie du cache. Pour éviter d'afficher des données obsolètes puisque le cache n'est pas partagé entre les pods par défaut, vous pouvez configurer le cache Next.js pour fournir un gestionnaire de cache et désactiver la mise en cache en mémoire.

Pour configurer l'emplacement du cache ISR/Data lors de l'auto-hébergement, vous pouvez configurer un gestionnaire personnalisé dans votre fichier next.config.js :

module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0, // désactiver la mise en cache en mémoire par défaut
}

Ensuite, créez cache-handler.js à la racine de votre projet, par exemple :

const cache = new Map()

module.exports = class CacheHandler {
  constructor(options) {
    this.options = options
  }

  async get(key) {
    // Cela pourrait être stocké n'importe où, comme un stockage durable
    return cache.get(key)
  }

  async set(key, data, ctx) {
    // Cela pourrait être stocké n'importe où, comme un stockage durable
    cache.set(key, {
      value: data,
      lastModified: Date.now(),
      tags: ctx.tags,
    })
  }

  async revalidateTag(tag) {
    // Parcourir toutes les entrées du cache
    for (let [key, value] of cache) {
      // Si les tags de la valeur incluent le tag spécifié, supprimer cette entrée
      if (value.tags.includes(tag)) {
        cache.delete(key)
      }
    }
  }
}

Utiliser un gestionnaire de cache personnalisé vous permettra d'assurer la cohérence entre tous les pods hébergeant votre application Next.js. Par exemple, vous pouvez sauvegarder les valeurs en cache n'importe où, comme Redis ou AWS S3.

Bon à savoir :

• revalidatePath est une couche de commodité au-dessus des tags de cache. Appeler revalidatePath appellera la fonction revalidateTag avec un tag spécial par défaut pour la page fournie.

Cache de build

Next.js génère un ID pendant next build pour identifier quelle version de votre application est servie. La même build doit être utilisée et démarrée sur plusieurs conteneurs.

Si vous reconstruisez pour chaque étape de votre environnement, vous devrez générer un ID de build cohérent à utiliser entre les conteneurs. Utilisez la commande generateBuildId dans next.config.js :

module.exports = {
  generateBuildId: async () => {
    // Cela pourrait être n'importe quoi, en utilisant le dernier hash git
    return process.env.GIT_HASH
  },
}

Désynchronisation de version

Next.js atténuera automatiquement la plupart des cas de désynchronisation de version et rechargera automatiquement l'application pour récupérer les nouveaux assets lorsqu'elle est détectée. Par exemple, s'il y a une incohérence dans le deploymentId, les transitions entre pages effectueront une navigation complète plutôt que d'utiliser une valeur préchargée.

Lorsque l'application est rechargée, il peut y avoir une perte d'état de l'application si elle n'est pas conçue pour persister entre les navigations de page. Par exemple, utiliser l'état de l'URL ou le stockage local persisterait l'état après un rafraîchissement de page. Cependant, l'état des composants comme useState serait perdu dans de telles navigations.

Vercel fournit une protection supplémentaire contre la désynchronisation pour les applications Next.js pour s'assurer que les assets et fonctions de la version précédente sont toujours disponibles pour les anciens clients, même après le déploiement de la nouvelle version.

Vous pouvez configurer manuellement la propriété deploymentId dans votre fichier next.config.js pour s'assurer que chaque requête utilise soit la chaîne de requête ?dpl soit l'en-tête x-deployment-id.

Arrêts gracieux manuels

Lorsque vous hébergez vous-même votre application, vous pourriez vouloir exécuter du code lorsque le serveur s'arrête suite aux signaux SIGTERM ou SIGINT.

Vous pouvez définir la variable d'environnement NEXT_MANUAL_SIG_HANDLE à true puis enregistrer un gestionnaire pour ce signal dans votre fichier _document.js. Vous devrez enregistrer la variable d'environnement directement dans le script du package.json, et non dans le fichier .env.

Bon à savoir : La gestion manuelle des signaux n'est pas disponible dans next dev.

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "NEXT_MANUAL_SIG_HANDLE=true next start"
  }
}

if (process.env.NEXT_MANUAL_SIG_HANDLE) {
  process.on('SIGTERM', () => {
    console.log('Received SIGTERM: cleaning up')
    process.exit(0)
  })
  process.on('SIGINT', () => {
    console.log('Received SIGINT: cleaning up')
    process.exit(0)
  })
}