Next.js en production sur un VPS : notre méthode

Chaque produit Anested — ce site compris — tourne sur la même infrastructure Anested Clouds que nous vendons à nos clients. Cette contrainte nous garde honnêtes. Si un schéma de déploiement est trop fragile pour nos propres produits, il n'a aucune raison de devenir un défaut sur le VPS de quelqu'un d'autre.

Notre stack Next.js de production est délibérément ennuyeuse, et nous le disons comme un compliment. Un VPS avec une version Node.js LTS figée, un gestionnaire de processus qui redémarre l'application en cas de panne, et un reverse proxy qui termine le TLS devant. Pas de cluster d'orchestration, pas de service mesh, pas de conteneurs sidecar. Aucune de nos charges de travail n'a encore mérité cette complexité, et prétendre le contraire signifierait simplement plus de choses qui cassent à deux heures du matin.

Le déploiement sans interruption est le seul endroit où nous investissons un vrai effort d'ingénierie. Chaque version se construit dans un répertoire séparé pendant que l'ancienne continue de servir le trafic. Nous lançons des vérifications de santé sur le nouveau build via un port interne, et ce n'est que lorsqu'il répond correctement que nous basculons l'upstream du reverse proxy. Si quelque chose semble anormal dix minutes plus tard, le retour arrière est un changement de symlink et un rechargement — pas un redéploiement paniqué.

Notre plus grande erreur des débuts fut de traiter les logs comme une réflexion après coup. Quand quelque chose cassait, nous faisions du SSH sur les serveurs pour fouiller des fichiers éparpillés. Aujourd'hui, chaque application envoie des logs structurés vers un stockage central dès le premier jour, et l'ingénieur d'astreinte peut répondre à la question « qu'est-ce qui a changé ? » en moins d'une minute. Cette seule habitude a réduit notre temps de résolution d'incident plus que n'importe quel achat d'outil.

Le cache mérite une mention car Next.js en offre tellement de couches — pages statiques à la compilation, revalidation incrémentale, en-têtes CDN. Notre règle : cacher agressivement en périphérie pour le trafic anonyme, et jamais pour les pages authentifiées. Des règles ennuyeuses et explicites valent mieux que des règles astucieuses que vous ne pouvez pas expliquer pendant une panne.

Si vous voulez cette même configuration sans la construire vous-même, c'est littéralement ce que vend Anested Clouds. Les schémas décrits dans cet article sont les défauts de chaque nouveau VPS que nous provisionnons — parce que nous faisons tourner notre propre entreprise dessus.