Héberger Next.js sur votre VPS : Docker, Plesk et l’après-Vercel

L'été StartingUp continue. La saison nous sert de belvédère : relire une année dense et en dresser un compte-rendu honnête. Nous avons raconté pourquoi les tutoriels pas-à-pas ne survivent plus à leur date de publication ; voici donc tout ce qu'un tutoriel ne vous dira pas avant d'héberger une application Next.js sur votre propre VPS.

Vercel a rendu un service immense à l'écosystème Next.js : déployer en poussant un commit, prévisualiser chaque branche, ne jamais penser aux serveurs. Puis un jour, la question arrive, posée par un directeur financier, un DPO ou un client du secteur public : « où tournent nos applications, et combien cela coûtera-t-il l'an prochain ? ». Ce jour-là, l'autonomie cesse d'être un caprice de développeur.

Héberger une application Next.js sur un VPS tient en trois décisions : containeuriser l'application avec Docker (mode standalone), pousser l'image sur un registre, puis laisser un panneau comme Plesk gérer le proxy nginx et le certificat TLS. Le coût devient fixe et connu d'avance, et les données restent où vous l'avez décidé. Tout le reste de cet article détaille ces décisions, et les pièges qu'elles cachent.

Cet article n'est volontairement pas un guide pas-à-pas : ces contenus se périment plus vite qu'ils ne s'écrivent, et un agent IA en génère un à jour à la demande. Ce qui ne se génère pas, c'est la logique des décisions. Nous hébergeons nos propres projets Next.js en containers Docker sur nos serveurs : voici ce que nous aurions aimé lire avant de commencer.

Quatre motifs reviennent dans les discussions que nous avons avec les entreprises qui veulent quitter Vercel, et aucun n'est une lubie technique.

• La prévisibilité des coûts. La facturation à l'usage (bande passante, invocations de fonctions, optimisation d'images) est confortable au départ et difficile à budgéter ensuite : un pic de trafic, un crawler qui s'emballe, et la facture suit.
• La souveraineté des données. Un PaaS américain reste soumis au droit américain, quels que soient ses datacenters. Pour la santé, le juridique ou le secteur public, l'exigence d'un hébergement européen maîtrisé de bout en bout n'est pas négociable.
• La latence européenne. Le rendu côté serveur s'exécute par défaut dans une région nord-américaine (cela se configure, mais encore faut-il le savoir). Un serveur à Paris, Strasbourg ou Francfort place ce rendu à quelques millisecondes de vos utilisateurs.
• La mutualisation. Beaucoup d'entreprises paient déjà un VPS sous Plesk pour leurs sites. Y ajouter une application Next.js a un coût marginal proche de zéro.

Soyons honnêtes : si aucun de ces motifs ne vous concerne, rester sur un PaaS est un choix parfaitement défendable. Le confort de développement y est inégalé, et l'autonomie a un prix que nous détaillerons plus bas.

Une image Docker est un artefact figé : même code, mêmes dépendances, même version de Node, partout et pour toujours. Votre serveur n'exécute plus « du Node installé un jour par quelqu'un », il exécute une image versionnée que l'on peut reconstruire à l'identique, auditer, et vers laquelle on peut revenir en cas de problème. C'est cette reproductibilité, bien plus que la mode, qui justifie le container.

Next.js a prévu le cas avec son mode output: standalone : au build, le framework trace les dépendances réellement utilisées et produit un bundle autonome, sans le poids mort du dossier node_modules complet. Combiné à un build en deux étapes, on obtient une image finale de quelques centaines de mégaoctets au lieu de plusieurs gigaoctets, qui démarre en une commande.

Une quinzaine de lignes, données ici pour le principe : votre projet aura les siennes. L'essentiel tient en deux idées : l'étape de build, lourde, reste confinée dans une image intermédiaire jetée après coup ; l'image finale ne contient que le nécessaire pour servir, et tourne sans privilèges.

Plesk traîne une réputation d'hébergement PHP à l'ancienne. Elle est datée : son extension Docker, fournie par l'éditeur, pilote un Docker standard installé sur le serveur. Depuis l'interface, on récupère une image depuis Docker Hub ou un registre privé, on définit les variables d'environnement et les volumes, on active le redémarrage automatique. Rien d'exotique : c'est du Docker ordinaire, avec une interface d'administration par-dessus.

Le point le plus élégant est le raccordement au web. On mappe le port de l'application sur un port local du serveur, puis les règles de proxy Docker du domaine demandent à Plesk d'écrire lui-même la configuration nginx correspondante, en substance celle-ci :

Le certificat TLS, lui, reste géré au niveau du domaine, avec le Let's Encrypt en un clic que Plesk propose pour n'importe quel site : le container ne sait même pas que HTTPS existe, et c'est très bien ainsi.

Les limites méritent d'être dites aussi : Plesk gère des containers, il n'orchestre rien. Pas de build sur le serveur (l'image se construit en intégration continue ou sur un poste, puis se pousse sur un registre), pas de déploiement progressif, pas de montée en charge automatique. Pour héberger une application ou dix, c'est exactement l'outil qu'il faut ; pour un cluster, non.

Le piège classique des migrations. Next.js incorpore les variables préfixées NEXT_PUBLIC_ dans le JavaScript au moment du build : les modifier ensuite dans Plesk ne change rien, l'image est déjà figée. Seules les variables lues côté serveur se transmettent au container à l'exécution. Conséquence pratique : soit vous construisez une image par environnement, soit vous limitez strictement les variables publiques. Le découvrir en production coûte une soirée ; le savoir avant coûte ce paragraphe.

La régénération statique incrémentale écrit son cache sur le disque du container, qui est éphémère par nature : chaque redéploiement repart de zéro, avec des pages froides et un pic de régénération. La parade est simple, monter un volume persistant sur le dossier de cache depuis Plesk, à condition d'y avoir pensé. Et si vous visez un jour plusieurs instances de l'application, ce cache devra devenir partagé : autant intégrer cette contrainte à l'architecture dès le départ.

Sur un PaaS, chaque commit déclenche build et mise en ligne. Ce circuit, il faut désormais le construire : l'intégration continue fabrique l'image et la pousse au registre, puis Plesk recrée le container, à la main dans l'interface ou par un script. La recréation impose quelques secondes d'interruption, acceptables pour la plupart des sites, à contourner sinon. S'y ajoutent les mises à jour du serveur lui-même : système, Docker, Plesk. C'est le vrai prix de l'autonomie, et il se paie en discipline plus qu'en argent.

Un container qui tourne n'est pas une application qui répond. Ajoutez une instruction HEALTHCHECK à l'image, une politique de redémarrage au container, et surtout une surveillance externe qui vous prévient quand le site ne répond plus : sur un PaaS, quelqu'un regardait à votre place ; ici, personne ne regardera si vous ne l'avez pas décidé. Rien de sorcier, mais rien d'automatique non plus.

Sur la maintenance, notre expérience est sans mystère : une fois le circuit de déploiement en place, l'entretien se compte en heures par mois, pas en jours, mais il ne descend jamais à zéro. En face, la facturation à l'usage suit votre trafic, y compris celui que vous ne choisissez pas : à l'heure où les robots des moteurs génératifs parcourent le web plus que jamais (nous l'observions en définissant le GEO), une bande passante facturée au volume est une variable que vous ne contrôlez qu'à moitié.

Si vos contraintes parlent de souveraineté, de budget à maîtriser ou d'un serveur déjà en place, la containeurisation sur votre propre VPS est aujourd'hui une voie mature, et Plesk rend accessible ce qui exigeait hier un profil devops à demeure. Si elles n'en parlent pas, un PaaS reste un excellent choix, et il n'y a aucune gloire particulière à administrer un serveur.

La vraie bonne nouvelle est ailleurs : une application Next.js proprement containeurisée n'appartient à aucun hébergeur. La même image tourne sur votre VPS, chez un autre prestataire, dans un cloud européen demain si le contexte l'exige. C'est peut-être la définition la plus concrète de la souveraineté : non pas l'endroit où l'on héberge, mais la liberté d'en changer sans réécrire une ligne.