BlogIngénierie

Ingénierie

Exécuter Next.js comme un serveur Node sans Lambda

Déployez Next.js comme un serveur Node avec des compilations standalone, systemd, NGINX, du streaming, des choix explicites de cache partagé et des déploiements de versions sûrs.

Équipe Adios25 septembre 2026Mise à jour 26 septembre 202620 min de lecture

Next.js peut fonctionner comme un processus Node persistant : compilez l’application, démarrez son serveur de production et envoyez-lui des requêtes HTTP. Le rendu serveur, les Route Handlers, les Server Actions, l’optimisation des images et le streaming peuvent y fonctionner sans adaptateur Lambda. Voici comment conditionner ce serveur, le maintenir en fonctionnement et déployer une seconde instance sans créer de problèmes de cache ou de versions.

Ce qui s'exécute dans le processus Node

Une requête entrante atteint votre proxy inverse, puis un serveur Next.js. Celui-ci peut renvoyer une page prégénérée, rendre une page pour la requête actuelle, exécuter un Route Handler ou servir une réponse en cache. En cas d’absence dans le cache, il peut appeler votre base de données ou votre API. Aucun wrapper Express n’est nécessaire pour ce fonctionnement.

Un processus persistant peut réutiliser les pools de connexions à la base de données et les connexions HTTP entre les requêtes. Il faut toujours prévoir suffisamment de CPU et de mémoire pour les pics de trafic, une politique de redémarrage et une procédure de déploiement. Un redémarrage, un nouveau réplica ou un cache vide peuvent ralentir les requêtes ; exécuter Node ne supprime pas ces coûts.

Choisir le format de sortie de production de l’application
Résultat	Mode d’exécution	Éléments à déployer
Serveur Node standard	next build, puis next start.	La compilation, les ressources publiques, les métadonnées des packages et les dépendances d’exécution requises.
Serveur Node standalone	Définissez output: standalone, compilez, puis exécutez le fichier server.js généré.	Fichiers d’exécution identifiés par le traçage, plus public et .next/static. C’est le parcours principal présenté ci-dessous.
Export statique	Servir les fichiers exportés depuis un serveur HTTP ou un stockage objet.	Fichiers statiques uniquement. Les fonctionnalités serveur exécutées à chaque requête nécessitent un autre backend.

The deployment we will build

Browser
   |
   v
NGINX :443  -- TLS, request limits, streaming passthrough
   |
   v
Next.js / Node :3001  -- rendering, routes, Server Actions
   |               |
   v               v
Database / API   Next.js caches

systemd supervises the Node process.
Each release gets its own directory and configuration.

Exécuter d’abord la compilation de production

Assurez-vous que l’application fonctionne avec le serveur de production avant de configurer une VM ou un conteneur. Conservez ces scripts dans package.json et installez les dépendances à partir du fichier de verrouillage enregistré dans le dépôt. Installez les dépendances de compilation avant de compiler : omettre devDependencies trop tôt peut supprimer des outils nécessaires au compilateur.

package.json scripts

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

Vérifier le même mode que celui qui sera déployé

Avec la sortie standard, les commandes ci-dessous démarrent le serveur Node complet sur l’adresse de boucle locale. Vérifiez une page dynamique, une requête authentifiée et un Route Handler en plus de la page d’accueil. Une session next dev réussie ne teste ni le prérendu de production, ni le traçage des dépendances, ni le comportement du cache en production.

Standard output: local production check

npm ci
npm run build
npm start -- --hostname 127.0.0.1 --port 3000

# In a second terminal:
curl --fail --show-error -I http://127.0.0.1:3000/

Conditionner une version standalone

La sortie standalone rassemble les fichiers que Next.js identifie pour le serveur et génère le point d’entrée server.js. Ajoutez les options ci-dessous à votre fichier next.config.mjs existant, en conservant les autres paramètres de l’application. Attribuez un identifiant de version à chaque compilation et réutilisez exactement sa sortie pour tous les réplicas de cette version.

next.config.mjs

const nextConfig = {
  output: "standalone",
  deploymentId: process.env.RELEASE_ID,
};

export default nextConfig;

Inclure les ressources du navigateur

La sortie standalone ne copie pas automatiquement public ni .next/static. Incluez-les lorsque le serveur Node doit servir ces fichiers. Si vous omettez cette étape, une page peut renvoyer correctement son HTML alors que tous les scripts du navigateur renvoient 404.

Build, package, and start

npm ci
RELEASE_ID=release-001 npm run build
mkdir -p .next/standalone/.next
cp -a .next/static .next/standalone/.next/static
if [ -d public ]; then
  cp -a public .next/standalone/public
fi

HOSTNAME=127.0.0.1 PORT=3001 RELEASE_ID=release-001 \
  node .next/standalone/server.js

Tester l’artefact hors de l’arborescence source

Copiez le répertoire standalone vers un emplacement propre et lancez-y server.js. Cela révèle les dépendances qui ne fonctionnaient que grâce à la présence de la copie du dépôt source. Dans un monorepo, inspectez l’arborescence générée : outputFileTracingRoot et outputFileTracingIncludes peuvent être nécessaires pour les packages partagés ou les fichiers ouverts via des chemins dynamiques.

A separate terminal, using a different port

release_dir=$(mktemp -d)
cp -a .next/standalone/. "$release_dir/"
cd "$release_dir"
HOSTNAME=127.0.0.1 PORT=3002 RELEASE_ID=release-001 node server.js

Séparer les valeurs de compilation des secrets d’exécution

Une variable d’environnement réservée au serveur peut être lue au moment d’une requête. Une variable NEXT_PUBLIC_ est intégrée au JavaScript du navigateur lors de la compilation. La modifier au démarrage du processus ne met pas à jour un bundle existant. Le contenu rendu côté serveur pendant la compilation peut aussi figer les valeurs disponibles à ce moment-là.

Moment où la configuration prend effet
Valeur	Moment de configuration	Conséquence pour le déploiement
NEXT_PUBLIC_API_URL	Compilation des ressources du navigateur.	Recompilez pour modifier une URL intégrée au code, ou exposez une configuration publique d’exécution volontairement prévue via votre propre point de terminaison.
DATABASE_URL / identifiants d’API	Démarrage du serveur, lorsque le code les lit dynamiquement.	Ne les placez pas dans les variables publiques, le dépôt source ni les couches de l’image.
deploymentId	Compilation de la version.	Utilisez le même identifiant pour tous les réplicas de cet artefact. Un changement effectué uniquement au démarrage ne réécrit pas la compilation.
PORT / HOSTNAME	Démarrage de server.js.	Utilisez l’adresse de boucle locale derrière un proxy sur le même hôte ; utilisez 0.0.0.0 dans un conteneur ou une charge de travail gérée.

Ajouter une route de santé sans cache

Cette route attend une requête avant de lire RELEASE_ID et indique l’état de santé du processus. Elle ne teste pas la base de données. Si le service nécessite une base de données pour traiter le trafic, ajoutez un contrôle de disponibilité distinct avec les délais d’attente de requête et de connexion de votre client de base de données ; renvoyez 503 lorsque ce parcours obligatoire échoue. Ne faites pas d’un service d’analytics facultatif une dépendance du contrôle de disponibilité.

src/app/api/health/route.js

import { connection } from "next/server";

export async function GET() {
  await connection();
  return Response.json(
    { ok: true, release: process.env.RELEASE_ID || "unknown" },
    { headers: { "Cache-Control": "no-store" } },
  );
}

Garder le serveur Node en marche avec systemd

Sur une VM, exécutez le serveur conditionné sous un utilisateur dédié et laissez systemd le redémarrer après un arrêt anormal. Utilisez un répertoire distinct pour chaque version afin qu’un déploiement ne puisse pas écraser les fichiers dont un processus actif a encore besoin. Les commandes ci-dessous supposent un nouvel hôte de type Debian avec Node installé ; vérifiez command -v node et adaptez ExecStart si le chemin diffère.

Install the already-built artifact on the target host

sudo useradd --system --home-dir /srv/next --shell /usr/sbin/nologin nextjs
sudo install -d -o nextjs -g nextjs /srv/next/releases/release-001
sudo cp -a .next/standalone/. /srv/next/releases/release-001/
sudo chown -R nextjs:nextjs /srv/next/releases/release-001
sudo install -d -m 700 /etc/next
sudo touch /etc/next/release-001.env
sudo chmod 600 /etc/next/release-001.env
sudoedit /etc/next/release-001.env

Définir l’environnement de la version

Utilisez ces valeurs dans le fichier d’environnement et ajoutez les secrets serveur requis par l’application via votre mécanisme de déploiement. La limite du tas est un exemple de point de départ, pas une estimation de capacité. La mémoire totale de Node inclut aussi les allocations natives et les tampons : gardez donc une marge sous la limite de mémoire totale du service.

/etc/next/release-001.env

PORT=3001
RELEASE_ID=release-001
NODE_OPTIONS=--max-old-space-size=768

Démarrer une version nommée

Enregistrez ce modèle dans /etc/systemd/system/next@.service. La valeur %i sélectionne le répertoire de version et le fichier d’environnement. Une seconde version peut utiliser son propre port et fonctionner à côté de la première pendant vos vérifications. Cette unité supervise le processus ; elle ne retire pas un processus défaillant d’un équilibreur de charge.

/etc/systemd/system/next@.service

[Unit]
Description=Next.js release %i
After=network.target

[Service]
Type=simple
User=nextjs
Group=nextjs
WorkingDirectory=/srv/next/releases/%i
Environment=NODE_ENV=production
Environment=HOSTNAME=127.0.0.1
EnvironmentFile=/etc/next/%i.env
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
KillSignal=SIGTERM
TimeoutStopSec=30
MemoryMax=1G
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Inspecter le démarrage avant d'ajouter du trafic

La réponse de santé doit identifier release-001. Vérifiez les journaux pour repérer les modules manquants, configurations invalides ou problèmes de permissions du répertoire de cache. Gardez les chemins du cache Next.js de la version accessibles en écriture ; rendre tout le système de fichiers accessible en lecture seule sans stratégie de cache peut interrompre la régénération ou l’optimisation des images.

Start and inspect

sudo systemctl daemon-reload
sudo systemctl enable --now next@release-001
sudo journalctl -u next@release-001 -n 50 --no-pager
curl --fail --show-error http://127.0.0.1:3001/api/health

Mettre NGINX devant et préserver le streaming

Gardez le port Node privé. Sur la même VM, NGINX peut terminer la connexion HTTPS et transmettre les requêtes à 127.0.0.1:3001. L’exemple suppose que le DNS pointe déjà vers l’hôte et qu’un certificat valide existe aux chemins indiqués. Remplacez app.example.com, puis vérifiez la configuration avec nginx -t avant de la recharger.

Laissez le cache du proxy désactivé au départ et désactivez la mise en tampon des réponses pour que les fragments diffusés parviennent au navigateur dès leur arrivée. Préservez l’hôte public et le protocole pour les redirections et les contrôles d’origine. Cette configuration d’en-têtes suppose que NGINX est le point d’entrée public ; si un équilibreur de charge de confiance le précède, configurez explicitement cette limite de confiance.

/etc/nginx/conf.d/next.conf, inside the http context

upstream next_app {
  server 127.0.0.1:3001;
  keepalive 32;
}

server {
  listen 80;
  server_name app.example.com;
  return 301 https://app.example.com$request_uri;
}

server {
  listen 443 ssl;
  server_name app.example.com;
  ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
  ssl_protocols TLSv1.2 TLSv1.3;
  client_max_body_size 10m;
  if ($host != app.example.com) { return 421; }

  location / {
    proxy_pass http://next_app;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_buffering off;
    proxy_cache off;
    proxy_connect_timeout 5s;
    proxy_read_timeout 60s;
  }
}

Tester deux fragments via le nom d’hôte public

Ajoutez ce Route Handler de diagnostic et recompilez la version. Interrogez-le directement puis via NGINX avec curl --no-buffer. La première ligne doit arriver avant la seconde. Si elles arrivent ensemble uniquement par la route publique, vérifiez la mise en tampon dans chaque proxy et CDN entre le navigateur et Node.

src/app/api/stream/route.js

import { connection } from "next/server";

export async function GET() {
  await connection();
  const encoder = new TextEncoder();
  const body = new ReadableStream({
    async start(controller) {
      controller.enqueue(encoder.encode("first chunk\n"));
      await new Promise((resolve) => setTimeout(resolve, 1000));
      controller.enqueue(encoder.encode("second chunk\n"));
      controller.close();
    },
  });
  return new Response(body, {
    headers: {
      "Content-Type": "text/plain; charset=utf-8",
      "Cache-Control": "no-store",
      "X-Accel-Buffering": "no",
    },
  });
}

Vérifier les limites aux deux couches

proxy_read_timeout définit le délai d’inactivité entre les lectures depuis le serveur en amont. Les flux de longue durée nécessitent des délais adaptés et, si nécessaire, des signaux périodiques de maintien de connexion. L’application impose aussi des limites de téléversement : augmenter la limite de taille du corps des requêtes dans NGINX ne modifie pas les limites des Server Actions de Next.js. Ajustez la limite précise que vous atteignez plutôt que d’ouvrir toutes les limites globalement.

Check proxy configuration and streaming

sudo nginx -t
sudo systemctl reload nginx
curl --fail --no-buffer http://127.0.0.1:3001/api/stream
curl --fail --no-buffer https://app.example.com/api/stream

Savoir quel cache vous modifiez

Aucun réglage unique du cache Next.js ne couvre toutes les couches. Une page produit obsolète peut provenir d’un cache applicatif, d’une route générée, d’une réponse CDN ou de l’état de navigation du navigateur. Identifiez la couche avant de modifier les TTL ou d’ajouter Redis.

Responsabilités du cache dans un déploiement auto-hébergé
Couche	Ce qu'il contient	Éléments à vérifier
Ressources de compilation	JavaScript, CSS et autres fichiers sous .next/static.	Déployez les ressources issues de la même compilation et conservez les fichiers nécessaires aux navigateurs qui utilisent la version précédente.
cache de données / ISR	Données fetch en cache et contenu de route régénéré dans le modèle de cache concerné.	Le stockage local doit être accessible en écriture. Avec plusieurs réplicas, le stockage et l’invalidation doivent être coordonnés explicitement.
Cache Components	Valeurs créées avec use cache et les directives associées.	Par défaut, les données résident dans la mémoire locale du processus. Une directive distante nécessite un gestionnaire externe configuré pour partager les données.
Optimisation des images	Variantes générées par next/image.	Surveillez le CPU, le disque et la latence de la première requête. Un gestionnaire de cache de données ne partage pas automatiquement les fichiers d’images optimisées.
Proxy inverse / CDN	Réponses HTTP autorisées par la politique de cache des nœuds périphériques.	Respectez Cache-Control et les variations de réponses. Les pages authentifiées et les réponses publiques partagées nécessitent des politiques différentes.

Les deux API de gestionnaires de cache sont différentes

Pour le cache serveur incrémental utilisé par ISR et les données en cache, Next.js expose cacheHandler, au singulier. Lors de la configuration d’un stockage partagé pour ce modèle, cacheMaxMemorySize: 0 peut désactiver la couche mémoire propre à chaque processus. Votre gestionnaire doit implémenter le stockage et le comportement des tags requis.

Cache Components utilise cacheHandlers, au pluriel. Un gestionnaire distant configuré peut fournir le cache de use cache: remote ; sans lui, cette directive seule ne provisionne pas Redis et ne crée pas de cache partagé. Coordonnez l’état des tags aussi bien que les valeurs, notamment avec refreshTags lorsque l’API du gestionnaire l’exige. Choisissez l’API adaptée à la version de Next.js installée et au modèle de cache utilisé.

Dans Next.js 16.2 et les versions ultérieures, les images optimisées peuvent utiliser cacheHandler grâce à images.customCacheHandler: true. Ce gestionnaire doit prendre en charge les entrées IMAGE, avec leurs données binaires et leur expiration. Configurez et testez explicitement ce mécanisme si vous souhaitez partager les variantes d’images entre les réplicas.

Ne pas mettre tout le HTML en cache sur les nœuds périphériques

La navigation Next.js peut demander des données React Server Component en plus du HTML. Un CDN doit préserver les variations de requêtes et les clés de cache requises par le framework. Une règle générique mettant tout en cache peut mélanger les types de réponses ou exposer du contenu personnalisé. Commencez par les en-têtes de cache du framework et les recommandations officielles sur les CDN, puis testez séparément les requêtes des utilisateurs connectés et déconnectés.

Ajouter des réplicas sans multiplier les problèmes

Exécutez le même artefact sur chaque réplica d’une version, mais donnez à chaque processus sa propre identité d’exécution et ses propres chemins locaux accessibles en écriture. Stockez les fichiers téléversés durables hors du répertoire de version. Les sessions doivent être utilisables par le réplica qui traite la requête suivante, au moyen de cookies vérifiés ou d’un stockage partagé des sessions, plutôt que d’un objet local au processus.

Dimensionnez les connexions à la base de données pour l’ensemble des processus. Quatre processus avec un pool maximal de dix connexions peuvent en utiliser quarante ; garder les quatre anciens processus actifs pendant un déploiement peut porter ce total à quatre-vingts, avant même de compter les workers et les connexions d’administration. Fixez les limites des pools selon la capacité de la base et le nombre maximal temporaire de réplicas.

Mesurez l’utilisation du CPU, le retard de la boucle d’événements, la mémoire totale du processus, la latence des requêtes et les erreurs sous une charge représentative. Un processus Node persistant peut gérer des entrées-sorties concurrentes, mais du JavaScript gourmand en CPU peut bloquer des requêtes sans rapport. Déplacez les tâches de fond coûteuses vers un worker et dimensionnez le système selon les goulots d’étranglement mesurés. Augmenter la limite du tas V8 ne résout pas un goulot d’étranglement CPU.

Déployez une nouvelle version pendant que l'ancienne est encore en service

Démarrez release-002 dans son propre répertoire sur le port 3002 pendant que release-001 continue de servir le trafic sur 3001. Effectuez les contrôles de santé et les tests applicatifs sur 3002. Modifiez ensuite l’upstream NGINX pour utiliser 3002, validez la configuration et rechargez-la. Gardez l’ancien processus disponible pendant la fin des requêtes existantes et la vérification de la nouvelle version.

Un navigateur peut encore conserver du JavaScript et des données préchargées de release-001. deploymentId permet à Next.js de détecter une divergence et de déclencher une navigation complète, susceptible de perdre l’état non enregistré des composants. Le paramètre de requête dpl ne fait pas router les requêtes vers une ancienne version par Next.js. Conservez les anciennes ressources et utilisez un routage tenant compte des versions si les clients doivent continuer à communiquer avec cette version.

État de la version à maintenir cohérent
Point à prendre en compte	Éléments à préserver	Défaillance à tester
Ressources du navigateur	Les fichiers référencés par les nouvelles pages et par les anciennes pages encore ouvertes.	Ouvrez une page avant la promotion, puis chargez un composant importé à la demande après celle-ci.
Server Actions	Un artefact unique et une configuration compatible de chiffrement des actions sur tous ses réplicas.	Après la bascule du trafic, envoyez un formulaire chargé avant la promotion.
Schéma de base de données	Compatibilité avec les deux versions pendant leur coexistence et en cas de retour arrière.	Exécutez l’ancienne version avec le schéma migré avant de déclarer le retour arrière disponible.
Requêtes en cours	Un délai mesuré pour laisser les requêtes en cours se terminer avant l’arrêt de l’ancien processus.	Basculez le trafic pendant une réponse lente ou un flux et vérifiez qu’ils se terminent correctement.

Maintenir des clés cohérentes pour les Server Actions

Le chiffrement des closures des Server Actions utilise une clé définie lors de la compilation. Réutiliser un même artefact préserve sa clé générée sur tous les réplicas. Si vous gérez explicitement NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, injectez la même clé AES valide, encodée en base64, dans les compilations qui en ont besoin et protégez-la comme un secret. Une clé partagée ne rend pas interchangeables les identifiants d’actions de compilations différentes.

Laisser terminer les requêtes, arrêter le processus et préserver un retour arrière

Retirez l’ancienne instance du routage des nouvelles requêtes avant d’envoyer SIGTERM. Laissez les traitements en cours se terminer dans le délai d’arrêt prévu ; augmentez la limite de 30 secondes de l’exemple si le comportement mesuré des requêtes le nécessite. Les callbacks after() ne constituent pas une file de tâches durable : les tâches qui doivent survivre à un arrêt anormal doivent utiliser une file persistante avec gestion des nouvelles tentatives.

Si la nouvelle version échoue, renvoyez le trafic vers le processus dont le bon fonctionnement est établi et conservez les journaux du processus défaillant. Les migrations de base de données et les effets de bord externes peuvent rendre ce retour arrière dangereux : il faut donc tester la compatibilité du schéma avant la promotion.

Déployer le même modèle de serveur sur Adios

Sur Adios, déclarez la commande de compilation, la commande de démarrage standalone, le port d’écoute et le chemin de santé dans adios.yaml. La passerelle publique transmet les requêtes à la charge de travail Node, qui doit donc écouter sur 0.0.0.0. Les configurations systemd et NGINX de la VM ne sont pas nécessaires à l’intérieur de cette charge de travail gérée.

Définissez un RELEASE_ID unique dans build.env et dans env pour chaque déploiement, afin que la compilation et le processus actif identifient la même version. Incluez devDependencies pendant la compilation, même si NODE_ENV vaut production. Cet exemple commence avec un réplica. En augmenter le nombre ne configure pas automatiquement un cache partagé, des sessions partagées ou la capacité de la base de données.

adios.yaml

name: web
region: de
replicas: 1

build_cmd: |
  npm ci --include=dev
  npm run build
  mkdir -p .next/standalone/.next
  cp -a .next/static .next/standalone/.next/static
  if [ -d public ]; then cp -a public .next/standalone/public; fi
start_cmd: node .next/standalone/server.js

build:
  env:
    RELEASE_ID: release-001

env:
  NODE_ENV: production
  HOSTNAME: 0.0.0.0
  PORT: "3000"
  RELEASE_ID: release-001

runtime:
  name: node@24
  port: 3000
  health_path: /api/health
  memory_mb: 1024

Vérifier ces défaillances avant d'ajouter du trafic

Effectuez les contrôles sur la version de production conditionnée et son nom d’hôte définitif. Conservez l’identifiant de version dans les journaux applicatifs pour déterminer si une erreur concerne un réplica, une compilation ou tout le service.

—Un artefact propre démarre sans accès à la copie du dépôt source.
—Les contrôles de santé, requêtes authentifiées, ressources, traitements d’images et réponses en streaming fonctionnent via HTTPS.
—Le service se rétablit après un redémarrage du processus, et une dépendance défaillante produit la réponse de disponibilité prévue.
—Un ancien onglet du navigateur continue de fonctionner correctement après la promotion, y compris pour l’envoi de formulaires.
—Les réplicas renvoient les mêmes données après invalidation, et la base de données conserve une marge de connexions disponibles.
—La version précédente et un schéma compatible restent disponibles pour le retour en arrière.

Vérification de la production et dépannage
Symptôme	Piste probable à examiner	Vérification
Le HTML fonctionne ; les scripts ou styles renvoient 404	Fichiers .next/static manquants ou mélange de versions.	Vérifiez une URL de script tirée du HTML réel et confirmez que l’artefact de sa version contient ce fichier.
L'URL publique renvoie 502	Adresse d’écoute, ports incompatibles ou processus arrêté à la suite d’une erreur.	Interrogez la route de santé directement sur le port Node, puis inspectez les journaux du proxy et du processus.
Le contenu en streaming arrive en une seule fois	Mise en tampon dans le proxy inverse ou le CDN.	Comparez l’accès direct au point de terminaison à deux fragments avec l’accès par le nom d’hôte public.
Le navigateur utilise encore une ancienne URL d’API	Une valeur NEXT_PUBLIC_ figée dans le bundle.	Inspectez le code compilé pour le navigateur et recompilez avec la configuration publique prévue.
Seules certaines requêtes affichent des données obsolètes	Caches indépendants des réplicas ou cache périphérique.	Vérifiez directement chaque réplica et contrôlez les valeurs stockées ainsi que l’invalidation des tags.
Les Server Actions échouent après un déploiement	Divergence entre versions compilées, clés de chiffrement incompatibles ou en-têtes d’origine.	Comparez les identifiants de version, l’artefact utilisé par chaque réplica et la transmission des en-têtes Host/Origin.
Le processus est arrêté de force sous charge	La mémoire totale dépasse la limite de l'hôte ou du conteneur.	Vérifiez la mémoire RSS, la charge liée à l’optimisation des images, la croissance du cache et la raison de l’arrêt indiquée par le superviseur.

Tous les articles