Comment Faire Tourner Node.js sur un VPS

Heroku a supprimé son offre gratuite et a augmenté le seuil minimum. Vercel facture par utilisateur et interrompt les tâches de longue durée. Render et Railway ajustent leurs prix en fonction du trafic.

Ouvre la facture la plus récente de ton fournisseur d’hébergement. L’application Node, une base de données Postgres, et un cache Redis. Trois lignes de frais, trois séries d’avertissements de dépassement, un fil Slack frénétique le jour où le marketing lance enfin une campagne.

Cette facture est la raison pour laquelle de nombreuses équipes se penchent à nouveau sur le VPS. Node.js lui-même ne se soucie pas de l’endroit où il s’exécute. La seule chose que le sans serveur vous protégeait de découvrir était ce qui se passe après ‘npm start’.

Examinons un modèle de configuration de production pour Node.js sur une machine Linux que tu contrôles. Si tu peux te connecter en SSH à une machine et lire un fichier de configuration, à la fin, tu auras une pile de production que tu peux faire fonctionner pendant des années avec quelques heures de maintenance par mois.

Quand Est-Il Judicieux de Faire Tourner Node.js Sur Un VPS ?

Un VPS est le domicile idéal pour Node.js lorsque tu as un processus de longue durée, une pile que tu souhaites consolider en une seule facture, ou une facture de runtime géré qui a dépassé la commodité.

De manière générale, il y a trois bonnes correspondances :

• Processus à longue durée de vie : Serveurs WebSocket, travailleurs de file d’attente, planificateurs de Cron Job, serveurs MCP. Tout ce qui doit rester en fonctionnement et à l’écoute. La plupart des plateformes sans serveur sont encore optimisées pour des cycles d’exécution et de demande de courte durée. Un processus Node sur un VPS reste simplement là.
• Consolidation des coûts : Application Node, Postgres, Redis, plus un petit travailleur de construction vivent tous sur la même boîte de 4 Go. Une ligne de facture, pas quatre.
• Applications qui ont dépassé PaaS : Délais de fonction sur votre travail de génération de PDF long. Tarification par utilisateur sur une équipe qui a finalement embauché un quatrième ingénieur. Une facture Heroku qui dépasse 60 $ par mois pour une charge de travail qui fonctionne bien sur un VPS de 15 $.

Et il y a trois mauvaises correspondances :

• Sites statiques et contenu SSG : Un export Next.js, une construction Astro, un blog Gatsby. La version gratuite de Vercel est l’outil approprié. Un VPS est excessif.
• Charges de travail sporadiques, pilotées par événements : AWS Lambda ou Cloudflare Workers coûtent quelques centimes pour un webhook qui s’exécute dix fois par jour. Un VPS coûte le même prix, que l’application soit active ou en veille.
• Applications en temps réel à échelle horizontale : Si votre serveur WebSocket doit être diffusé à 100 000 connexions simultanées, un VPS n’est pas la réponse. C’est un cluster Kubernetes, une infrastructure périphérique distribuée, ou une plateforme en temps réel gérée.

JavaScript est le langage le plus utilisé dans l’enquête des développeurs Stack Overflow de 2025, et Node.js reste l’une des manières par défaut pour les développeurs d’exécuter JavaScript sur le backend. Cela représente beaucoup de personnes utilisant Node quelque part. Cet article est destiné à la partie d’entre eux qui serait plus heureuse de l’exécuter sur un serveur qu’ils contrôlent.

J’ai vu des équipes déplacer quatre services Node de production de Heroku vers un seul VPS de 4 GB, avec la même garantie de disponibilité, un tiers de la facture, et des WebSockets à longue durée qui finalement fonctionnaient sans contournement.

La migration est principalement une après-midi de « apt install », un « pm2 start » et un changement de DNS.

De Quelles Spécifications VPS Node.js A-T-Il Réellement Besoin ?

Node.js est en lui-même léger. Un serveur Express minimal peut rester inactif bien en dessous de 100 Mo de mémoire résidente. Le conseil « Node a seulement besoin de 1 Go » que vous pouvez encore trouver sur des blogs plus anciens est techniquement vrai et pratiquement inutile. Au moment où vous avez ajouté Postgres, Redis, des logs et un processus de déploiement qui ne tient pas juste par espoir, vous dépassez déjà cette limite lors d’une journée calme.

Dimensionnement réaliste pour les charges de travail courantes :

Charge de travail	RAM	vCPU	Stockage	Notes
Petite API Express sans DB sur la machine	2 Go	1-2	40 Go NVMe	Seuil réaliste pour une application de production
API Node + Postgres + Redis sur une seule machine	4 Go	2	80 Go NVMe	Le juste milieu ; la plupart des équipes se retrouvent ici
Application lourde en SSR (Next.js, Nuxt, Remix)	8 Go	4	80 Go NVMe	Le rendu SSR et les pipelines de construction consomment beaucoup de mémoire
Application en temps réel/WebSocket, échelle modérée	8 Go	4	80 Go NVMe	Chaque connexion persistante consomme de la mémoire

Quelques détails à préciser avant de procéder à la provision :

• Le Stockage NVMe Est Plus Important Que La Taille Pure Du Disque : Les applications Node modernes manipulent des milliers de petits fichiers lors des installations, des constructions et du démarrage. Les disques lents rendent les installations de dépendances, les démarrages à froid et les reconstructions SSR nettement pires.
• Virtualisation KVM, Pas OpenVZ : Les anciens plans basés sur OpenVZ partagent un noyau avec l’hôte, ce qui peut signifier des versions de noyau obsolètes et des maux de tête de compatibilité occasionnels avec les nouveaux environnements d’exécution. La plupart des fournisseurs VPS réputés utilisent maintenant exclusivement KVM, mais cela vaut toujours la peine de vérifier.
• Espace De Swap : Active 1-2 Go de swap sur les petites boîtes. Le tas V8 de Node peut varier fortement lors du ramassage des ordures. Sans swap, un pic transitoire tue le processus. J’ai vu une boîte de 4 Go OOM pendant un déploiement routinier parce que quelqu’un avait désactivé le swap en pensant que c’était un anachronisme de l’ère Docker.
• Bande Passante : La plupart des plans VPS modernes incluent 1-4 To de bande passante mensuelle, suffisamment pour presque tout sauf l’hébergement vidéo. Les plans VPS auto-gérés incluent une bande passante non mesurée, une ligne de moins sur la feuille de calcul de la planification des capacités.

Un VPS de 4 Go coûte environ 15 $ par mois au tarif du marché. Cela fait 50 cents par jour, soit à peu près un café d’aéroport toutes les deux semaines. Comparé au paiement séparé pour les runtimes d’application, le Postgres géré et Redis sur un PaaS, l’économie s’inverse de manière surprenante rapidement.

Quelle Version De Node.js Devrais-Tu Installer ?

Installe Node.js 24 (nom de code Krypton). C’est la version LTS active actuelle, promue en octobre 2025 et soutenue jusqu’en avril 2028 selon le calendrier officiel des versions de Node.js.

De nombreux tutoriels dirigent encore les gens vers Node 22. Ces guides n’ont pas été mis à jour. Si tu lances un nouveau déploiement aujourd’hui, fixe ton image CI et ton VPS sur Node 24.x.

Version	Nom de Code	Statut	EOL
Node.js 26.x	(aucun)	Actuelle	Passe en LTS fin 2026
Node.js 24.x	Krypton	LTS Actif	Avril 2028
Node.js 22.x	Jod	LTS de Maintenance	Avril 2027
Node.js 20.x	Fer	Fin de Vie |	EOL atteint le 30 avril 2026. Ne pas utiliser.

Quelques règles de base :

• Ne faites pas fonctionner les versions actuelles (non-LTS) en production : Node 26 existe pour tester la compatibilité future et les nouvelles fonctionnalités d’exécution, et non pour l’application dont dépend votre revenu.
• Node 22 est l’option de repli si une dépendance critique n’est toujours pas compatible avec Node 24 : La plupart de l’écosystème s’est stabilisée quelques mois après la promotion LTS.
• Fixez votre version de Node partout : Votre image CI, Dockerfile, .nvmrc et VPS de production devraient tous être en accord. “Ça marche sur ma machine” devient rapidement coûteux une fois que les modules natifs entrent en jeu.

🤔Tu Considères Bun? Il est plus rapide sur certaines charges de travail et vraiment impressionnant, mais l’écosystème est encore plus petit et le bilan de production est moins long que celui de Node. Pour la plupart des équipes, le classique l’emporte.

NodeSource, qui maintient les dépôts apt et yum d’où de nombreuses équipes de production installent Node, met en avant les améliorations de la version 24.x, en commençant par un moteur V8 plus récent. Node 24 embarque également des outils désormais matures comme le built-in node –watch et un exécuteur de tests natif stable (node : test), tous deux stabilisés dans les versions 20–22 et qui se poursuivent ici. Rien de tape-à-l’œil. Cela élimine juste un peu de friction opérationnelle chaque mois.

Comment Installer Node.js Sur Un VPS ?

Tu as deux chemins d’installation réalistes. Choisis en fonction de si le serveur exécute une application Node ou plusieurs.

NodeSource pour un Serveur d’Application Unique

C’est le chemin de production le plus simple. Un script d’installation et une commande apt install te permettent d’obtenir la version LTS actuelle de Node 24 en tant que paquet système, et les futures mises à jour de sécurité seront intégrées via les mises à jour de paquets normales.

Sur Ubuntu ou Debian :

curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs

Vérifie l’installation :

node -v
npm -v

Tu devrais voir une version Node 24.x.

Les instructions pour les distributions de la famille RHEL (yum/dnf) se trouvent dans le dépôt officiel des distributions NodeSource.

nvm pour le changement de version par projet

nvm (Gestionnaire de Version Node) installe Node dans ton répertoire personnel et permet à différents projets d’exécuter différentes versions de Node. Utile si tu héberges plusieurs applications sur le même serveur ou si tu n’as pas accès à sudo.

Lance cela en tant qu’utilisateur de ton application, pas en tant que root :

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash

Recharge ton Shell, puis installe Node 24 :

nvm install 24
nvm use 24
nvm alias default 24

👉Une règle importante : Ne utilise pas sudo ‘npm install -g’ pour les dépendances d’applications.

Les installations globales sont généralement réservées aux outils CLI de niveau machine comme pm2, typescript ou nodemon. Les dépendances de ton application doivent figurer dans package.json et devraient être installées à partir du répertoire du projet avec npm ci.

NodeSource	nvm
Une version Node par serveur	Plusieurs versions Node par serveur
Installé sur tout le système, fonctionne pour tout utilisateur	Installé par utilisateur
Mises à jour automatiques avec ‘apt’	Géré manuellement
Requiert sudo	Pas de sudo requis

Si tu n’es pas sûr, commence par NodeSource. La plupart des serveurs de production à usage unique n’ont pas besoin de changement de version Node par projet.

👉Utilisateurs de VPS autogérés DreamHost : L’application Node disponible lors de la configuration est fournie avec Node 22 LTS — toujours pris en charge jusqu’en avril 2027. Pour utiliser Node 24, utilisez les étapes NodeSource ou nvm ci-dessus après la configuration.

Devrais-Tu Utiliser PM2 ou systemd Pour Maintenir Ton Application En Fonctionnement ?

Les deux fonctionnent. La réponse honnête est celle avec laquelle ton équipe est à l’aise. PM2 est la voie conviviale pour les développeurs. systemd est la voie native Unix. Les deux résolvent les trois mêmes problèmes : redémarrage en cas de crash, démarrage au boot, et arrêt en douceur lors d’un ‘SIGTERM’.

Si tu commences à partir de zéro, voici comment choisir :

	PM2	systemd
Temps de configuration	3 minutes	10 minutes
Mode cluster (multi-cœur)	Intégré	Non intégré (démarrer N unités)
Rotation des logs	Module : ‘pm2-logrotate’	Intégré via ‘journalctl’
Rechargement sans temps d’arrêt	‘pm2 reload’	Généralement géré manuellement avec redémarrages progressifs ou plusieurs unités
Surcharge mémoire (démon)	Faible surcharge du démon	Aucune (pas de démon supplémentaire)
Le meilleur pour	Boîte unique, boutique JS, itération rapide	Boîtes multi-applications, confort de l’équipe d’opérations

Le démarrage rapide PM2 est exactement cela, rapide :

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # imprime la commande de démarrage systemd à exécuter
pm2 save       # enregistre la liste des processus actuels

PM2 devient alors la seule chose à laquelle tu t’adresses : ‘pm2 logs,’ ‘pm2 reload api,’ ‘pm2 monit.’

👉Aussi bon à savoir : « pm2 startup » écrit une unité systemd, donc la configuration de PM2 utilise réellement systemd sous le capot.

Une unité systemd minimale pour la gestion directe de Node à ‘/etc/systemd/system/api.service’ :

[Unit]
Description=Mon API Node
After=network.target

[Service]
Type=simple
User=app
WorkingDirectory=/var/www/api
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
Ensuite ‘systemctl enable --now api.’ Les logs se trouvent dans ‘journalctl -u api -f.’

Si tu utilises déjà PM2 et que cela fonctionne, ne migre pas vers systemd simplement parce que quelqu’un sur Hacker News l’a dit. La mémoire du démon PM2 n’est pas la raison pour laquelle tu migrerais loin de celui-ci.

Migre lorsque tu as une vraie raison, comme faire fonctionner une demi-douzaine de processus Node où chaque mégaoctet compte, ou expédier dans un environnement opérationnel où chaque autre service est une unité systemd, et PM2 se démarque comme l’exception.

Comment Mettre NGINX (ou Caddy) Devant Ton Application Node ?

Tu veux un proxy inverse devant Node pour cinq raisons : terminaison HTTPS, compression gzip/brotli, service d’actifs statiques, exécution de plusieurs applications sur la même machine, et limitation de débit plus facile. Node peut faire tout cela. NGINX et Caddy le font mieux, et ils ne bloquent pas ta boucle d’événements lorsque quelque chose se comporte mal.

Choisis NGINX si quelqu’un dans ton équipe le connaît déjà. Choisis Caddy si tu veux HTTPS en trois lignes de configuration et que tu es à l’aise avec un écosystème de configuration avancée plus petit.

Configuration Minimale De NGINX

Mets ce bloc proxy dans /etc/nginx/sites-available/api, crée un lien symbolique vers sites-enabled, puis nginx -t && systemctl reload nginx.

server {
    listen 80;
    server_name api.example.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-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Les en-têtes ‘Upgrade’ et ‘Connection’ sont les lignes de support de WebSocket. Les propres documents de NGINX indiquent que Upgrade est un en-tête de saut par saut, il nécessite donc un traitement explicite lors de la proxyfication du trafic WebSocket.

Laisse-les si ton application utilise actuellement des WebSockets, ou pourrait les utiliser plus tard. Socket.IO, les abonnements GraphQL via WebSockets, et un nombre surprenant de fonctionnalités en temps réel « régulières » dépendent de cette poignée de main pour la mise à niveau.

Le bug de production le plus courant que je vois dans les configurations Node est un serveur Socket.IO derrière NGINX sans ces deux lignes. Les connexions échouent par intermittence, les développeurs blâment Socket.IO, et le problème réel est généralement la configuration du proxy.

Caddyfile Minimal

La version démarrage rapide du proxy inverse Caddy de la même chose :

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Voilà le fichier complet. Tant que le domaine pointe vers le serveur et que les ports 80/443 sont accessibles, Caddy configure et renouvelle automatiquement le HTTPS. La documentation de Caddy indique que le HTTPS automatique provisionne les certificats TLS pour les sites et les renouvelle ; son guide de démarrage rapide pour le proxy inverse mentionne également que le HTTPS est automatique lorsque Caddy connaît le nom d’hôte.

Lier Le Nœud À Localhost, Pas À 0.0.0.0

Quel que soit le proxy que tu choisis, configure ton application Node pour écouter sur 127.0.0.1:3000, et non 0.0.0.0:3000. La seule chose qui devrait être exposée à Internet public sur une boîte Node est le proxy. Associe cela à UFW, le frontend de pare-feu courant d’Ubuntu, pour tout refuser sauf les ports 22, 80, et 443.

ufw par défaut refuser entrant
ufw permettre 22/tcp
ufw permettre 80/tcp
ufw permettre 443/tcp
ufw activer

Si SSH fonctionne sur un port personnalisé, autorise ce port avant d’activer UFW.

Lie-toi à localhost dès le premier jour. La réunion où quelqu’un admet que « l’application était exposée parce que Node était lié à 0.0.0.0 » n’est pas une réunion à laquelle tu souhaites assister.

Comment Configurer HTTPS Pour Ton Application Node.js ?

Utilise Let’s Encrypt. C’est gratuit, automatisé, et approuvé par tous les navigateurs. Il existe deux chemins, selon le proxy que tu as choisi.

NGINX + Certbot

Oriente un enregistrement A vers ton IP VPS et attends que le DNS se propage.

Installe Certbot :

apt install certbot python3-certbot-nginx

Exécute :

certbot --nginx -d api.example.com

Certbot met à jour ta configuration NGINX et recharge le serveur automatiquement.

Sur les versions modernes d’Ubuntu, un minuteur systemd installé par le paquet Certbot gère automatiquement le renouvellement.

Ouvre https://api.example.com et confirme l’icône de verrou.

La documentation officielle de Certbot couvre également le chemin d’installation basé sur snap si le paquet de ta distribution est obsolète.

Caddy

Ajoute le domaine au Caddyfile (l’exemple ci-dessus l’a déjà), puis redémarre Caddy. Tant que le domaine est résolu correctement et que les ports 80/443 sont accessibles, le certificat est provisionné automatiquement lors du premier démarrage. Il n’y a pas de Certbot.

Ne termine pas le TLS dans Node lui-même pour la production.

Le module https de Node fonctionne parfaitement, mais les proxies inversés comme NGINX et Caddy sont spécialement conçus pour la terminaison TLS. Ils offrent le stapling OCSP, des valeurs par défaut de chiffrement modernes, le renouvellement automatique des certificats, le support de HTTP/2 et — dans le cas de Caddy — le support de HTTP/3 dès la sortie de la boîte.

Pourrais-tu gérer tout cela directement dans Node ? Bien sûr. Tu serais juste en train de reconstruire une infrastructure que ton proxy résout déjà extrêmement bien.

À Quoi Ressemble Vraiment Une Configuration Node.js Prête Pour La Production ?

Huit choses mordent les gens en production. La plupart ne figurent pas dans les tutoriels d’installation car elles ne correspondent pas à l’arc “installer Node, exécuter l’application”. Elles représentent la différence entre une application qui survit au deuxième mois et une qui ne le fait pas.

• NODE_ENV=production: L’étape la plus souvent oubliée. Dans de nombreux cadres et bibliothèques Node, cela désactive les comportements exclusifs au développement et active les optimisations de production. Express, par exemple, met en cache les modèles de vue compilés et renvoie des erreurs plus concises en production — ses propres documents mentionnent une amélioration des performances allant jusqu’à 3 fois. Définis la variable d’environnement partout.
• Arrêt en douceur: Lorsque ton VPS redémarre ou que PM2 envoie un ‘SIGTERM’, ton application dispose de quelques secondes pour gérer les requêtes en cours, fermer les connexions à la base de données et se terminer proprement. Configure un gestionnaire ‘process.on(‘SIGTERM’, …)’. Le timing d’arrêt par défaut de PM2 dépend de la configuration et de l’environnement, donc ne suppose pas que tu auras toujours beaucoup de temps pour nettoyer. 
• Rotation des logs: Le module ‘pm2-logrotate’ de PM2 s’en occupe pour PM2. Le journal systemd s’en occupe pour les unités systemd directes. Sans rotation, tes logs consomment le disque en un quart du temps que tu attendrais.
• Discipline .env: Ne jamais engager de secrets, ne jamais les enregistrer. Utilise ‘dotenv’ pour le développement local. En production, définis les variables d’environnement via ‘Environment=’ de ton unité systemd ou ton fichier écosystème PM2. Le jour où tu fais ‘console.log(process.env)’ par accident est le jour où tu fais tourner chaque identifiant.
• Un proxy inverse devant Node: Lie Node à localhost ; laisse NGINX ou Caddy faire face à internet public.
• Un pare-feu: UFW bloque tout sauf 22, 80, 443. Déplacer SSH loin du port 22 n’arrêtera pas un attaquant déterminé, mais cela réduit considérablement le bruit de force brute automatisé et les logs d’authentification inutiles.
• Surveillance: Un point de terminaison de vérification de santé que ton outil de surveillance consulte chaque minute. PM2 dispose des bases intégrées. Pour quelque chose de sérieux, utilise Prometheus et Grafana, ou un service de disponibilité hébergé comme Better Stack ou UptimeRobot. Tu veux savoir que ton application est hors ligne avant qu’un client te le signale.

Estimation de la maintenance pour la pile ci-dessus : une à trois heures par mois.

Mises à jour Apt, mises à niveau occasionnelles des dépendances et un examen trimestriel du volume des logs. C’est l’échange pour les gains de coût et de contrôle.

Quand Est-Ce Que Un VPS Est Un Mauvais Choix Pour Node.js ?

Un VPS est un mauvais choix lorsque ton travail est conçu pour autre chose. Sois honnête sur le côté où tu te trouves avant de provisionner.

• Sites statiques et contenu SSG : Exportation Next.js, Astro, Gatsby et un blog Eleventy. Des plateformes comme Vercel, Netlify ou Cloudflare Pages vous offrent un hébergement statique mis en cache globalement, des déploiements basés sur Git, et des reconstructions automatiques dès le départ. Un VPS est généralement une infrastructure inutile pour un contenu purement statique.
• Charges de travail événementielles et peu fréquentes : Cloudflare Workers et AWS Lambda sont économiques pour des webhooks qui s’exécutent dix fois par jour. 
• Applications en temps réel nécessitant plus de 100 000 connexions simultanées : Un VPS ne se scale pas horizontalement. Tu auras besoin d’orchestration (Kubernetes, ECS, Nomad) ou d’une plateforme gérée en temps réel comme Ably ou Pusher.
• Charges de travail réglementées et lourdes en conformité : HIPAA, PCI-DSS Niveau 1, FedRAMP. Une PaaS gérée avec des certifications de conformité intégrées épargne la douleur des audits. L’hébergement autogéré de la conformité sur un VPS est un projet de plusieurs trimestres que tu ne veux probablement pas.
• Aucun confort avec Linux — et aucune envie de le développer : Des plateformes comme Render, Railway et DigitalOcean App Platform se situent quelque part entre l’hébergement VPS brut et la PaaS entièrement gérée. Des outils comme Dokploy ajoutent des workflows de déploiement de style Heroku sur ton propre infrastructure VPS. Tu conserves encore beaucoup des avantages en termes de coût et de contrôle sans avoir besoin de te familiariser profondément avec iptables, les détails de systemd, ou le débogage de proxy inverse à 1 heure du matin.

Il n’y a aucune honte dans aucune de ces réponses. La meilleure décision technique est celle qui correspond à ta charge de travail.

Choisir Ton Stack Node Et Emménager

Ouvre cette facture d’hébergement encore une fois.

Tu es sur le point de remplacer une quantité surprenante par une seule facture de VPS.

👉La pile : Ubuntu 24.04 LTS, Node 24, PM2 (ou systemd), NGINX (ou Caddy), Let’s Encrypt via Certbot (ou intégré à Caddy).

Lance le plan VPS le plus petit qui atteint la RAM que tu as dimensionnée, installe Node, exécute ton application sur ‘127.0.0.1’, oriente NGINX vers celle-ci, et modifie ton DNS.

Si l’application survit à un déploiement, un redémarrage et une exécution nocturne sans problème, tu es presque arrivé.

Le reste, c’est de la maintenance. Une ou deux heures par mois, la fenêtre occasionnelle de « apt upgrade », une mise à jour des dépendances tous les trimestres. C’est l’accord que tu as conclu lorsque tu as échangé une facture par utilisateur contre une facture forfaitaire, et c’est avec le Self-Managed VPS Stack 4 de DreamHost que tu peux commencer.

Questions Fréquemment Posées Sur L’exécution De Node.js Sur Un VPS

Puis-je exécuter Node.js sur n’importe quel VPS ?

La plupart des plans VPS modernes exécutent très bien Node.js. Les plans VPS basés sur KVM avec une distribution Linux 64 bits sont la configuration par défaut la plus sûre pour les versions actuelles de Node.js.

Les anciens plans basés sur OpenVZ ont parfois des restrictions de noyau qui perturbent les nouvelles versions de Node. Si tu choisis entre des fournisseurs, demande s’ils utilisent KVM.

Combien de RAM Node.js nécessite-t-il sur un VPS ?

Un serveur Express minimal fonctionne au ralenti bien en dessous de 100 Mo, mais une application de production réaliste avec intergiciel, journalisation et un pool de connexions tourne généralement dans la plage de 150 à 300 Mo.

Le minimum réaliste pour une application de production est de 2 Go ; le niveau idéal pour une pile Node + Postgres + Redis est de 4 Go. La pile 4 (4 Go) de VPS auto-géré de DreamHost gère la plupart des charges de travail de production Node. Opte pour la pile 8 (8 Go) pour les applications utilisant intensivement le SSR ou en temps réel.

Quelle est la version LTS actuelle de Node.js ?

La version LTS active actuelle est Node.js 24.x (“Krypton”), promue le 28 octobre 2025 et supportée jusqu’en avril 2028. Node.js 22.x (“Jod”) est en LTS de maintenance jusqu’en avril 2027 si une dépendance impose une compatibilité arrière. Node.js 26 a été lancé le 5 mai 2026, comme actuel et sera promu en LTS en octobre 2026.

La plupart des équipes de production s’en tiennent aux versions LTS à moins qu’elles n’aient spécifiquement besoin de nouvelles fonctionnalités d’exécution.

Ai-je besoin de PM2 si j’ai systemd ?

Non, tu n’as pas besoin des deux. PM2 et systemd résolvent le même problème : maintenir ton application Node en fonctionnement en cas de plantages et de redémarrages. De nombreuses équipes centrées sur Node choisissent PM2 pour la gestion intégrée des grappes, la gestion des logs et les outils de rechargement.

Les équipes qui utilisent déjà des unités systemd pour tout le reste choisissent systemd.

Pourquoi mettre NGINX devant Node.js ?

NGINX (ou Caddy) devant Node.js centralise la terminaison TLS, la compression, la distribution d’actifs statiques et la limitation de débit dans un logiciel conçu spécifiquement pour le proxy et le service web.

Cela te permet également d’exécuter plusieurs applications Node sur le même VPS sans conflits de ports. En production, Node écoute sur localhost ; NGINX fait face à l’internet public.

Node.js sur un VPS est-il moins cher que Heroku ou Vercel ?

Oui, souvent. Un VPS de 4 Go se situe généralement dans la fourchette de 15 à 25 $ par mois au tarif du marché et peut consolider les coûts d’exécution d’applications, de base de données et de cache qui sont facturés séparément sur de nombreuses plateformes PaaS.

La tarification de Vercel Pro est basée sur le nombre d’utilisateurs, et les plateformes sans serveur imposent toujours des limites de durée d’exécution selon le runtime et le plan.

Le compromis est que tu gères les opérations toi-même, environ une à trois heures par mois.

Puis-je exécuter plusieurs applications Node sur un seul VPS ?

Oui, et c’est la raison la plus courante pour laquelle les équipes passent de PaaS à un VPS. Exécute chaque application sur son propre port interne (3000, 3001, 3002) et dirige le trafic avec des blocs serveur NGINX par nom d’hôte. PM2 gère tous ces processus séparément ; systemd utilise un fichier unitaire par application.

Un VPS de 4 Go peut souvent gérer plusieurs services Node légers en plus d’une petite charge de travail de base de données.

Puis-je exécuter Node.js sur le Shared Hosting DreamHost ?

Non. Node.js nécessite des processus persistants, des installations de paquets au niveau root et une liaison directe de port, ce que le shared hosting ne fournit pas. Les plans VPS Auto-gérés de DreamHost (Stack 4 et plus) conviennent aux charges de travail Node avec un accès root complet, un stockage NVMe et une bande passante illimitée.