Déployer Next.js sans Vercel : ce que vous gardez, ce que vous perdez.

La colonne du milieu reprend ce que Next.js dit d’un serveur next start auto-hébergé. La dernière colonne indique ce que Canner fait en plus, vérifié dans notre documentation Next.js et le code de la plateforme.

next start exécute la sortie de compilation normale avec tous vos node_modules. C’est ce que fait npm start dans un projet neuf, et il n’a besoin de rien d’autre. C’est aussi l’option la plus tolérante : chaque fichier du dépôt est encore sur le disque à l’exécution.

output: "standalone" retrace les fichiers qu’importe chaque route et ne copie que ceux-là dans .next/standalone, avec un petit server.js pour les servir. L’option existe pour les images Docker, où des node_modules de 1 Go ralentissent chaque envoi. Le piège est dans la documentation de Next.js : server.js ne sert ni public ni .next/static à moins de les y copier. D’où tous ces déploiements standalone qui affichent une page sans CSS.

• Les fichiers lus avec `fs` à l’exécution (gabarits de courriel, JSON de traduction, fichier de données) ne sont pas importés : le traçage peut les oublier. L’appli démarre, et une route répond 500. Utilisez outputFileTracingIncludes, ou restez sur next start.
• Sur Canner, le mode standalone est inutile, comme le dit la documentation : la compilation par défaut est ce qu’attend next start. Si votre configuration l’active quand même, Canner copie public et .next/static, reprend aussi les dossiers d’exécution courants comme templates, locales et messages, puis appelle vos routes avant la fin du déploiement. Si l’une répond par une erreur 5xx, il remet ce déploiement sur la compilation next start complète.

// next.config.ts
const nextConfig = { output: "standalone" };
export default nextConfig;

// After `next build`, on a host that doesn't do this for you:
cp -r public .next/standalone/
cp -r .next/static .next/standalone/.next/
PORT=3000 HOSTNAME=0.0.0.0 node .next/standalone/server.js

Hors de Vercel, /_next/image est servi par votre propre processus. Next.js redimensionne avec sharp, qui fournit des binaires précompilés que le gestionnaire de paquets choisit selon le système et le processeur à l’installation. Deux choses tournent mal en pratique :

• sharp absent sur le serveur. Vous avez installé sous macOS et copié node_modules vers Linux, ou l’installation a sauté les dépendances optionnelles. Installez sur la plateforme cible, à partir du fichier de verrouillage, avec les dépendances optionnelles.
• La mémoire qui grimpe sous la charge. La documentation de sharp indique que l’allocateur glibc par défaut convient mal au traitement d’images multifil de longue durée, et sharp limite lui-même sa concurrence quand il détecte glibc. Alpine (musl) n’est pas touché; sur une image Debian ou Ubuntu, vous pouvez précharger jemalloc.
• Sur Canner, l’optimisation d’images fonctionne sans configuration et son cache dans .next/cache est conservé d’un déploiement à l’autre. Les scripts d’installation des paquets sont désactivés par défaut; si le journal de compilation montre qu’un script a été sauté et que le paquet échoue ensuite, autorisez-le avec canner.allowedBuildScripts dans package.json (déroulement d’une compilation).

En auto-hébergement, les pages ISR et le cache de données vivent là où Next.js les met par défaut : en mémoire (50 Mo) et sur le disque local de chaque serveur. Rien n’est partagé entre serveurs à moins de le configurer.

Avec un seul serveur, c’est tout ce qu’il faut, et c’est ce que Canner exécute : un processus par projet, donc revalidateTag sur ce processus invalide la seule copie qui existe. Les ennuis commencent avec plusieurs instances. Chacune a son cache, une revalidation sur l’une n’atteint pas les autres, et le guide d’auto-hébergement vous fait écrire un gestionnaire de cache appuyé sur un stockage partagé comme Redis. Canner n’a pas de Redis : si vous avez besoin de plusieurs instances, il vous faut un autre hébergeur.

Pour les sites pilotés par un CMS, Canner offre aussi une mise en cache des réponses par étiquette devant l’appli. Le webhook du CMS vide une étiquette, et le visiteur suivant obtient un rendu frais. Chaque déploiement de production réussi la vide aussi.

Ce sont des produits Vercel, pas des fonctions de Next.js : aucun autre hébergeur ne vous les donne tels quels.

• Vos utilisateurs sont partout dans le monde et la latence compte. Vercel fait le rendu près d’eux. Canner a une seule région, Montréal, sans basculement.
• Il vous faut plusieurs instances derrière un répartiteur de charge. Canner exécute un processus par projet. Passer à plusieurs instances exige un gestionnaire de cache partagé, la même clé de chiffrement et la même compilation partout.
• Vous dépendez de la Skew Protection pour de longues sessions, comme un paiement ou un examen qui ne doit pas se recharger en cours de route.
• Sinon, une appli Next.js avec une base de données Postgres fonctionne de la même façon sur un seul processus Node. Sur Canner, c’est un git push, avec la base de données et vos données au Québec; les tarifs détaillent ce que comprend chaque forfait.