Pourquoi héberger Nuxt sur un VPS ?
Les plateformes d'hébergement mutualisé ne supportent pas Node.js de manière native, ce qui rend l'auto-hébergement d'une application Nuxt impossible sans un VPS ou un serveur dédié. Un VPS vous permet de choisir la version de Node.js que vous souhaitez, de configurer un reverse proxy (Nginx ou Caddy) sur le port de votre choix, et de gérer vos propres certificats TLS — le tout sans limitation artificielle sur les ressources CPU ou mémoire. C'est la solution idéale pour les développeurs indépendants et les PME qui veulent maîtriser leur stack de bout en bout.
Contrairement aux solutions PaaS ou serverless, un VPS ne facture pas à l'exécution et ne plafonne pas les temps de réponse : un appel API qui dure bien en dessous de la seconde n'entraîne aucun surcoût. Vous gardez aussi la main sur les headers HTTP, le cache de bord et la configuration TLS — trois leviers déterminants pour le SEO et la performance réelle.
SSR, SSG ou SPA : quel mode choisir pour votre projet Nuxt ?
Faites défiler le tableau
| Mode | Rendu | Processus Node requis | Idéal pour |
|---|---|---|---|
| SSR (ssr: true) | À la requête, côté serveur | Oui — PM2 permanent | App dynamique, SEO, contenu personnalisé |
| SSG (nuxt generate) | Au build, HTML statique | Non — nginx suffit | Blog, vitrine, contenu peu changeant |
| SPA (ssr: false) | Dans le navigateur | Non — nginx suffit | Dashboard interne, app derrière auth |
| Hybrid (routeRules) | Par route : SSR + SSG mixés | Oui — Nitro server | App avec pages statiques et routes API |
Ce que vous pouvez faire avec Nuxt sur un VPS
Un VPS ServOrbit avec le template Nuxt préconfiguré vous ouvre quatre axes que les hébergeurs mutualisés ou les PaaS ferment :
Capacités concrètes sur VPS
- Servir une application Nuxt en mode SSR pour un SEO optimal et des temps de chargement réduits — PM2 maintient le processus Nitro actif et le redémarre automatiquement après un crash ou un redémarrage serveur
- Déployer un site statique généré avec
nuxt generateet le servir via Nginx sans processus Node.js permanent — idéal pour un blog ou une vitrine à faible fréquence de mise à jour - Héberger plusieurs projets Nuxt sur le même VPS grâce à un reverse proxy et des Virtual Hosts Nginx — chaque application tourne sur son propre port interne (3000, 3001…)
- Configurer des variables d'environnement sensibles (clés API, connexions DB) directement sur le serveur dans
/etc/environmentou via un fichier.envhors dépôt Git - Activer les API routes Nitro (
server/api/) pour exposer une couche backend légère depuis le même process Node.js, sans serveur Express séparé - Automatiser vos déploiements avec PM2 ecosystem, des webhooks GitHub ou une pipeline CI/CD pointant sur votre VPS via SSH
- Activer HTTPS automatiquement avec Let's Encrypt via Certbot pour sécuriser vos utilisateurs sans coût de certificat
Installer et déployer Nuxt sur votre VPS ServOrbit
Commander un VPS Cloud ServOrbit
Rendez-vous sur la page
/vps-cloudet choisissez la formule adaptée à votre projet. Pour une application Nuxt en SSR, comptez au minimum 1 vCPU et 1 Go de RAM ; 2 Go permettent d'absorber confortablement le processus Nitro, un éventuel reverse proxy et les pics de compilation lors des déploiements. Si vous hébergez plusieurs applications Nuxt, préférez 2 vCPU / 4 Go dès le départ. Complétez la commande et accédez à votre espace client une fois le VPS livré — généralement en moins d'une minute.Installer Nuxt depuis le Marketplace
Connectez-vous à votre espace client ServOrbit, naviguez vers la section Marketplace depuis le tableau de bord de votre VPS, puis recherchez Nuxt. Cliquez sur la fiche, confirmez l'installation. Le script configure automatiquement Node.js LTS, PM2 comme gestionnaire de processus, Nginx en reverse proxy sur le port 80 (et 443 si un domaine est renseigné). L'opération prend moins de deux minutes. À la fin, votre VPS expose déjà un serveur Nuxt d'exemple accessible via l'IP du VPS.
Déposer votre application et configurer les variables d'environnement
Connectez-vous en SSH (
ssh root@<IP-du-VPS>), puis clonez votre dépôt dans le répertoire préparé :git clone https://github.com/votre-org/votre-app.git /var/www/nuxt-app cd /var/www/nuxt-app npm installCréez ensuite un fichier
.envhors dépôt Git avec vos variables de runtime :NUXT_PUBLIC_API_BASE=https://api.votre-domaine.com NUXT_SECRET_KEY=votre-clé-privée DATABASE_URL=postgres://user:pass@localhost/madbNuxt 3 lit les variables préfixées
NUXT_viauseRuntimeConfig()— les variablesNUXT_PUBLIC_*sont exposées côté client, les autres restent serveur uniquement. Ne jamais commiter le.env: ajoutez-le à.gitignoredès la création du dépôt.Construire l'application et la lancer avec PM2
Compilez l'application pour la production :
npm run buildNuxt 3 génère le dossier
.output/contenant le serveur Nitro. Lancez-le avec PM2 en mode cluster pour exploiter tous les cœurs CPU :pm2 start .output/server/index.mjs -i max --name nuxt-app pm2 save pm2 startupLa commande
pm2 startupgénère la ligne systemd à exécuter pour que PM2 redémarre automatiquement au reboot du serveur. Vérifiez l'état :pm2 status— les instances doivent être enonline. Pour recharger sans temps d'arrêt lors d'un déploiement :pm2 reload nuxt-app.Configurer Nginx en reverse proxy et pointer votre domaine
Le template Marketplace installe un Virtual Host Nginx prêt à l'emploi dans
/etc/nginx/sites-available/nuxt-app. Éditez-le pour y renseigner votre nom de domaine et activer la mise en cache des assets statiques :server { server_name votre-domaine.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_cache_bypass $http_upgrade; } location /_nuxt/ { proxy_pass http://127.0.0.1:3000; expires 1y; add_header Cache-Control "public, immutable"; } }Pointez ensuite votre entrée DNS A vers l'IP du VPS, puis lancez Certbot pour obtenir un certificat TLS gratuit :
certbot --nginx -d votre-domaine.com. Rechargez Nginx :nginx -s reload. Votre application Nuxt est désormais accessible en HTTPS.Automatiser les déploiements suivants
Pour les mises à jour, créez un script de déploiement
/var/www/nuxt-app/deploy.sh:#!/bin/bash set -e cd /var/www/nuxt-app git pull origin main npm install --production=false npm run build pm2 reload nuxt-app echo "Déploiement terminé"Rendez-le exécutable (
chmod +x deploy.sh) et déclenchez-le depuis votre pipeline CI/CD via SSH :ssh root@<IP> /var/www/nuxt-app/deploy.sh. Le rechargement PM2 (reloadet nonrestart) assure une transition sans interruption de service — PM2 attend que chaque nouvelle instance soit prête avant de couper l'ancienne.
Variables d'environnement et configuration runtime Nuxt 3
Nuxt 3 distingue deux niveaux de variables via useRuntimeConfig() :
- runtimeConfig.public.* → disponibles côté client et serveur (ex. URL d'API publique, clés de tracking)
- runtimeConfig.* (non public) → serveur uniquement (ex. clés secrètes, credentials DB)
Les variables d'environnement les remplacent automatiquement au runtime en suivant la convention NUXT_<NOM> (public : NUXT_PUBLIC_<NOM>). Cela signifie que vous n'avez pas besoin de rebuilder l'application pour changer une URL d'API ou une clé d'accès : il suffit de modifier le fichier .env sur le serveur et de recharger PM2 (pm2 reload nuxt-app). C'est particulièrement utile pour les environnements multiples (staging, production) qui partagent le même artefact de build.
Pour les secrets critiques (tokens DB, clés de chiffrement), préférez les variables système dans /etc/environment à un fichier .env dans le répertoire de l'application — elles sont chargées au niveau du système et non exposées par un accès en lecture sur le dossier de l'application.
Surveiller les logs et diagnostiquer les erreurs
PM2 centralise les logs de votre application Nuxt en temps réel. Quelques commandes essentielles :
pm2 logs nuxt-app # flux en direct (stdout + stderr)
pm2 logs nuxt-app --lines 100 # 100 dernières lignes
pm2 monit # dashboard CPU / mémoire en temps réelLes logs sont persistés dans ~/.pm2/logs/ — nuxt-app-out.log pour la sortie standard et nuxt-app-error.log pour les erreurs. Pensez à configurer la rotation des logs pour éviter de remplir le disque :
pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 7Pour les erreurs Nginx (502, 503 quand PM2 est hors ligne), consultez /var/log/nginx/error.log. Une erreur 502 persistante indique généralement que le processus PM2 n'est pas démarré (pm2 status) ou que le port 3000 n'est pas accessible depuis le proxy.
Diagnostiquer les problèmes courants
Trois situations reviennent fréquemment lors du déploiement d'une application Nuxt sur VPS :
Erreur 502 Bad Gateway. Nginx ne peut pas joindre le processus Nitro sur le port 3000. Causes classiques : pm2 start n'a pas été lancé ou s'est arrêté (pm2 status pour vérifier), le port 3000 est bloqué par le pare-feu (ufw allow 3000 temporairement pour tester), ou l'application a planté au démarrage (pm2 logs nuxt-app --lines 50 pour lire la dernière erreur).
Variables d'environnement non résolues. useRuntimeConfig() retourne undefined côté client sur une variable qui devrait être publique. Vérifiez que la variable est bien préfixée NUXT_PUBLIC_ dans votre .env, et que vous avez redémarré PM2 après la modification : pm2 reload nuxt-app. Les variables d'environnement ne sont lues qu'au démarrage du processus Nitro, pas en live.
Page blanche en production après nuxt generate. Le HTML statique s'affiche mais les données dynamiques sont vides. Ce n'est pas un problème serveur — c'est un problème de baseURL : côté serveur lors du prerender, un $fetch avec chemin relatif n'a pas d'origine. Passez l'URL complète de votre API dans NUXT_PUBLIC_API_BASE et utilisez useAsyncData avec useFetch en spécifiant cette base explicitement dans les pages qui nécessitent du contenu crawlable.
Astuce performance : mode cluster PM2. La commande pm2 start .output/server/index.mjs -i max --name nuxt-app démarre autant d'instances que de cœurs CPU disponibles et répartit automatiquement la charge entre elles. Sur un VPS 2 vCPU vous obtenez deux workers Nitro actifs, ce qui double le débit sur les routes SSR — idéal pour absorber les pics de trafic sans changer de formule. Vérifiez avec pm2 status que les N instances sont toutes en online.
La documentation officielle
Pour la configuration avancée, les options propres à l'outil et les changements de version, référez-vous à la documentation officielle de Nuxt. Ce guide couvre la mise en ligne sur VPS ServOrbit ; la documentation éditeur reste la référence pour les réglages fins (routeRules, Nitro presets, modules officiels).