Meilleur hébergement pour Next.js : plateformes managées vs VPS

Next.js est un framework React capable de produire deux types de sortie très différents, et votre choix d'hébergement découle directement de celui que vous déployez. Un site 100% statique n'est qu'un ensemble de fichiers servis par un CDN ; une application rendue côté serveur est un processus Node.js de longue durée qui doit rester en vie. Confondez les deux et vous payez trop cher pour un site statique, ou vous déployez une application dynamique là où elle ne peut pas tourner. Ce guide explique les modes de rendu, puis compare honnêtement le compromis entre une plateforme managée et un VPS auto-hébergé.

D'abord, décidez comment votre application rend

La question la plus importante est de savoir si votre application est statique ou a besoin d'un serveur au moment de la requête. Next.js gère les deux, et ils ont des exigences d'hébergement complètement différentes.

• Export statique - avec output: 'export', Next.js construit du HTML, du CSS et du JavaScript simples au moment du build. Il n'y a pas de serveur : le résultat est un dossier de fichiers que n'importe quel hébergeur statique ou CDN peut servir. Bon marché et simple, mais cela exclut tout ce qui s'exécute à chaque requête.
• Rendu côté serveur (SSR / ISR / routes API) - le rendu côté serveur, la régénération statique incrémentale, les gestionnaires de routes et le middleware exécutent tous du code quand une requête arrive. Cela nécessite un runtime Node.js qui fait tourner votre build et reste en vie pour répondre aux requêtes.

Vous pouvez vérifier ce qu'utilise votre projet : s'il repose sur getServerSideProps, des composants serveur qui fetchent à la requête, des routes API sous app/api ou pages/api, ou la revalidation ISR, c'est une application serveur. Si chaque page peut être générée à l'avance, l'export statique est envisageable.

Option 1 : un export statique sur n'importe quel hébergeur statique

Si votre application est 100% statique, l'hébergement est trivial et bon marché. Réglez la sortie sur export, buildez, et déployez le dossier généré sur un hébergeur statique ou un CDN :

// next.config.js
module.exports = {
  output: 'export',
};

# le build produit un dossier statique 'out/'
npm run build

# 'out/' contient maintenant du HTML, CSS et JS a deposer n'importe ou

Le dossier out/ n'est que des fichiers, il fonctionne donc sur n'importe quel hébergeur statique avec un CDN mondial et du HTTPS gratuit. C'est le même modèle que celui couvert dans notre guide sur l'hébergement de site statique. Le hic, c'est qu'un export statique ne peut pas faire de rendu côté serveur, d'ISR, d'optimisation d'images à la volée ni de routes API - ces fonctionnalités n'existent tout simplement pas sans serveur.

Option 2 : une plateforme managée

Les plateformes managées construisent votre application depuis un push Git et font tourner le serveur à votre place, en gérant la montée en charge, le TLS et le pipeline de build. Vercel est la plus notable ici car c'est l'entreprise qui développe Next.js, donc sa plateforme suit de près les nouvelles fonctionnalités du framework. D'autres plateformes comme Netlify supportent aussi Next.js via leurs propres adaptateurs.

L'attrait est réel : vous faites git push et la plateforme exécute tout le flux, il n'y a donc pas de serveur à patcher ni de reverse proxy à configurer. Le compromis, c'est le contrôle et le coût. Vous travaillez dans le modèle de build et d'exécution de la plateforme, et une tarification à l'usage peut grimper à mesure que le trafic, l'exécution des fonctions et la bande passante augmentent. Pour un petit projet, les paliers gratuits ou bas sont généreux ; pour une application chargée, la facture croît avec l'usage, ce qui est précisément le moment où l'auto-hébergement devient intéressant.

Option 3 : auto-hébergement sur un VPS

Comme une application Next.js rendue côté serveur est au final un processus Node.js, vous pouvez la faire tourner vous-même sur un VPS - exactement comme vous hébergeriez n'importe quelle application Node. C'est l'option la plus flexible et généralement la moins chère à grande échelle, en échange du travail d'exploitation à assumer vous-même. Le build produit un serveur que vous démarrez avec next start :

# sur le serveur : installer les deps et builder
npm ci
npm run build

# demarrer le serveur de production (port 3000 par defaut)
npm run start

Comme pour tout processus Node de longue durée, vous ne devriez pas lancer next start à la main dans une session SSH. Utilisez un gestionnaire de processus comme PM2 pour le maintenir en vie et le redémarrer après un plantage ou un redémarrage, et placez un reverse proxy devant lui. C'est exactement le schéma de notre guide sur l'hébergement d'une application Node.js :

# maintenir le serveur Next.js en vie avec PM2
pm2 start "npm run start" --name next-app
pm2 startup
pm2 save

Puis pointez Nginx vers le processus Node pour qu'il termine le TLS et transmette le trafic public au port 3000 :

server {
  listen 80;
  server_name yourapp.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Ajoutez le HTTPS avec un certificat automatisé gratuit (des outils comme Certbot en font une simple ligne). Pour dimensionner la machine, les critères sont les mêmes que pour toute application web - la mémoire d'abord, puis le CPU - couverts dans notre guide sur le choix du meilleur VPS pour un projet web. Des fournisseurs axés sur un bon rapport ressources-prix, comme Contabo ou Hetzner, offrent une RAM et des vCPU généreux à un coût mensuel bas, ce qui convient bien à un build et un runtime Node.

Comment les options se comparent

Approche	Exécute quoi	Vous gérez	Idéal quand
Export statique	Fichiers sur un CDN (pas de serveur)	Juste un build et un dépôt	Chaque page peut être pré-générée
Plateforme managée	SSR, ISR, routes API	Juste votre code et les variables d'env	Vous voulez livrer vite, peu d'exploitation
VPS (auto-hébergé)	SSR, ISR, routes API	OS, Node, PM2, Nginx, TLS	Vous voulez le contrôle et un coût prévisible

Comment décider

Partez de la façon dont votre application rend, pas du marketing d'un fournisseur. Si chaque page peut être générée à l'avance, livrez un export statique et hébergez-le à bas coût sur un CDN. Si vous avez besoin de SSR, d'ISR ou de routes API, il vous faut un runtime Node.js - et cela revient alors à un compromis familier : une plateforme managée est le moyen le plus rapide de livrer et le moins de travail d'exploitation, tandis qu'un VPS est moins cher à grande échelle et vous donne le contrôle total, en échange de faire tourner vous-même Node, un gestionnaire de processus, un reverse proxy et le TLS. Choisissez la plus petite option qui couvre ce dont votre application a réellement besoin, et montez en gamme seulement quand la montée en charge ou la charge d'exploitation devient le vrai goulot d'étranglement.