Choisir entre Vercel et un VPS pour héberger une app Next.js

Le choix entre Vercel et un VPS n'est pas une question de préférence, mais d'architecture. Next.js expose des fonctionnalités (ISR, Server Actions, Middleware Edge, Image Optimization) dont le comportement change radicalement selon la plateforme d'exécution. Voici les critères techniques réels pour trancher.

Ce que Vercel résout, et ce qu'il facture

Vercel a été conçu par l'équipe Next.js et reste la plateforme où le framework tourne "as intended" : déploiement Git, ISR avec revalidation on-demand sans code additionnel, Edge Middleware exécuté au plus près de l'utilisateur, Image Optimization à la volée sans configuration serveur.

Le coût réel apparaît à l'échelle. Le plan Pro facture :

• les invocations de Serverless/Edge Functions (au-delà de 1M/mois sur Pro),
• la bande passante sortante (100 GB inclus, puis ~0,15 $/GB),
• les écritures ISR et les requêtes d'Image Optimization.

Une app avec beaucoup de pages dynamiques revalidées fréquemment (e-commerce, dashboard multi-tenant) peut voir sa facture grimper vite, car chaque revalidation ISR compte comme une exécution facturée. Sur un projet avec 50k pages revalidées toutes les 60 secondes, le calcul mérite d'être fait avant, pas après la mise en prod.

Vercel reste pertinent quand : l'équipe est petite, le time-to-market prime, le trafic est irrégulier (scaling automatique sans intervention), ou que l'app dépend fortement des primitives Next.js les plus récentes (PPR, Server Actions streaming).

VPS : contrôle total, mais opérations à votre charge

Sur un VPS (Hetzner CPX31, OVH, Scaleway), vous exécutez Next.js via next start en mode output: 'standalone', typiquement derrière PM2 ou dans un conteneur Docker orchestré avec Nginx en reverse proxy.

Ce que vous gagnez :

• coût prévisible et souvent inférieur à trafic élevé constant (un CPX41 Hetzner à ~30 €/mois encaisse un trafic que Vercel Pro facturerait plusieurs centaines d'euros),
• pas de vendor lock-in sur les runtimes,
• contrôle total sur les logs, le monitoring, les secrets, la conformité (utile en contexte réglementé — RGPD, hébergement souverain).

Ce que vous devez construire vous-même :

• ISR : Next.js standalone ne gère pas nativement le cache ISR distribué. Il faut un cache partagé (Redis) si vous scalez horizontalement sur plusieurs instances, sinon chaque instance a son propre cache de fichiers et sert des versions incohérentes.
• CDN et edge caching : sans CDN devant votre VPS, pas de cache géographique. Cloudflare devant Nginx est la configuration minimale viable, avec Cache Rules explicites sur les assets statiques (/_next/static/*).
• Zero-downtime deploy : nécessite un pipeline (GitHub Actions + Docker + blue-green ou reload PM2 sans coupure).
• Scaling horizontal : load balancer (HAProxy, ou Nginx upstream) + sessions/cache partagés si vous multipliez les instances.
• Image Optimization : le endpoint /_next/image tourne en local et consomme du CPU serveur ; à fort trafic, prévoir un service dédié (Sharp en worker séparé) ou déléguer à un CDN d'images externe.

Middleware Edge et Server Actions : la vraie différence technique

Le Middleware Next.js est pensé pour l'Edge Runtime de Vercel (V8 isolates, exécution < 50 ms partout dans le monde). Sur VPS, le Middleware s'exécute côté Node.js classique, sur une seule région géographique — ce qui annule l'intérêt principal de la fonctionnalité pour une audience internationale. Si votre app cible un public mono-région (France, marché B2B national), cette limite n'a pas d'impact réel.

Les Server Actions fonctionnent identiquement sur les deux plateformes puisqu'elles s'exécutent côté serveur classique, mais s