Les trois cibles exécutent le même projet, mais pas avec le même niveau d’abstraction. Vercel prend en charge les fonctions spécifiques de Next.js ; Railway fournit un service applicatif managé ; un VPS vous laisse responsable du système, du proxy et des mises à jour.
Valider le projet localement
~~~bash npm ci npm run lint npm run build npm run start ~~~
Testez les routes dynamiques, les images, les variables serveur et les migrations. Une variable préfixée "NEXT_PUBLIC_" est intégrée au bundle client : n’y placez jamais de secret.
Option 1 : Vercel
Connectez le dépôt dans Vercel ou lancez la CLI depuis la racine :
~~~bash npm install -g vercel vercel vercel --prod ~~~
Configurez les variables par environnement. Chaque pull request peut obtenir une URL de prévisualisation. Vercel reste le chemin le plus direct pour SSR, streaming, image optimization et ISR, mais vérifiez les limites d’exécution et la région des fonctions lorsque l’application dépend d’une base.
Option 2 : Railway
Pour un déploiement auto-contenu, activez le mode standalone :
~~~typescript // next.config.ts import type { NextConfig } from "next";
const nextConfig: NextConfig = { output: "standalone", };
export default nextConfig; ~~~
Adaptez le script de démarrage :
~~~json { "scripts": { "build": "next build", "start": "node .next/standalone/server.js" } } ~~~
Puis utilisez le dépôt GitHub ou la CLI "railway init" et "railway up". Générez un domaine dans Networking. Pour Prisma ou Drizzle, placez la commande de migration dans l’étape pre-deploy, avant que la nouvelle version reçoive du trafic.
Option 3 : VPS avec Docker
Le build standalone produit un serveur minimal. Utilisez une image multi-stage, exécutez-la avec un utilisateur non root et copiez "public", ".next/standalone" et ".next/static". Définissez "HOSTNAME=0.0.0.0" et exposez le port 3000 au proxy interne, pas directement à Internet.
~~~bash docker build -t mon-app:2026-08-25 . docker run --name mon-app -p 127.0.0.1:3000:3000 --env-file .env.production mon-app:2026-08-25 ~~~
Placez Caddy ou Nginx devant le conteneur pour TLS et compression. Configurez redémarrage automatique, journaux, sauvegardes et correctifs système.
Santé, migrations et rollback
Ajoutez une route légère "/api/health" qui vérifie le processus sans exécuter une requête coûteuse. Les migrations doivent être rétrocompatibles pendant le déploiement : ajoutez une colonne avant de l’utiliser, migrez les données, puis retirez l’ancienne dans une version ultérieure.
Conservez au moins l’image ou le déploiement précédent. Un rollback applicatif ne suffit pas si une migration destructive a déjà modifié la base.
Choisir
Prenez Vercel pour l’intégration Next.js et les previews, Railway pour un service managé avec processus et bases proches, et un VPS lorsque contrôle, localisation ou coût stable justifient l’exploitation supplémentaire. Comparez sur la charge réelle, y compris trafic sortant, observabilité et temps humain.
FAQ
Pourquoi le build fonctionne-t-il localement mais pas en production ?
Vérifiez version de Node, casse des chemins, variables disponibles au build, dépendances natives et accès réseau. Reproduisez le build dans le même conteneur que la production.
Où exécuter les tâches longues ?
Dans un worker dédié ou une file, pas dans une requête de page susceptible d’expirer.