Comment exécuter Node.js sur un VPS

Heroku a supprimé son offre gratuite et relevé son prix d'entrée. Vercel facture par utilisateur et interrompt les tâches longues. Chez Render et Railway, le prix augmente avec le trafic.

Ouvrez la dernière facture de votre hébergeur. L'application Node, une base de données Postgres et un cache Redis. Trois lignes, trois séries d'alertes de dépassement et un fil Slack paniqué le jour où le marketing lance enfin une campagne.

C'est à cause de cette facture que beaucoup d'équipes reconsidèrent le VPS. Node.js lui-même ne se soucie pas de l'endroit où il tourne. La seule chose dont le serverless vous protégeait, c'était de découvrir ce qui se passe après « npm start ».

Voyons un modèle de configuration de production pour Node.js sur un serveur Linux que vous contrôlez. Si vous savez vous connecter à un serveur en SSH et lire un fichier de configuration, vous disposerez à la fin d'une stack de production capable de tourner pendant des années avec quelques heures de maintenance par mois.

Quand est-il judicieux d'exécuter Node.js sur un VPS ?

Un VPS est l'environnement idéal pour Node.js si vous avez un processus de longue durée, une stack que vous souhaitez regrouper sur une seule facture, ou une facture d'environnement d'exécution géré qui ne justifie plus sa commodité.

Globalement, il existe trois cas où c'est le bon choix :

• Processus de longue durée : serveurs WebSocket, workers de files d'attente, planificateurs cron, serveurs MCP. Tout ce qui doit rester actif et à l'écoute. La plupart des plateformes serverless restent optimisées pour des exécutions courtes et des cycles de vie de requêtes. Un processus Node sur un VPS, lui, tourne tout simplement en continu.
• Regroupement des coûts : l'application Node, Postgres, Redis et un petit worker de build cohabitent sur le même serveur de 4 Go. Une ligne de facture au lieu de quatre.
• Applications devenues trop grandes pour un PaaS : des délais d'expiration de fonction sur votre longue tâche de génération de PDF. Une tarification par utilisateur pour une équipe qui vient enfin d'embaucher un quatrième développeur. Une facture Heroku qui dépasse 60 $ par mois pour une charge de travail qui tourne très bien sur un VPS à 15 $.

Et trois cas où c'est le mauvais choix :

• Sites statiques et contenu SSG : un export Next.js, un build Astro, un blog Gatsby. L'offre gratuite de Vercel est l'outil adapté. Un VPS serait disproportionné.
• Charges de travail ponctuelles et événementielles : 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 occupée ou en sommeil.
• Applications temps réel à mise à l'échelle horizontale : si votre serveur WebSocket doit gérer 100 000 connexions simultanées, un seul VPS n'est pas la solution. Il vous faut un cluster Kubernetes, une infrastructure edge distribuée ou une plateforme temps réel gérée.

JavaScript est le langage le plus utilisé selon le 2025 Stack Overflow Developer Survey, et Node.js reste l'un des moyens privilégiés par les développeurs pour exécuter JavaScript côté backend. Cela fait beaucoup de monde qui fait tourner Node quelque part. Cet article s'adresse à ceux qui préféreraient le faire tourner sur un serveur qu'ils contrôlent.

J'ai vu des équipes migrer quatre services Node de production depuis Heroku vers un seul VPS de 4 Go, avec la même disponibilité, une facture divisée par trois et des WebSockets de longue durée qui fonctionnaient enfin sans bricolage.

La migration se résume pour l'essentiel à un après-midi de « apt install », un « pm2 start » et une modification DNS.

De quelles ressources VPS Node.js a-t-il vraiment besoin ?

Node.js est léger en soi. Un serveur Express minimal peut tourner au repos avec bien moins de 100 Mo de mémoire résidente. Le conseil « Node n'a besoin que de 1 Go » que l'on trouve encore sur d'anciens blogs est techniquement vrai, mais inutile en pratique. Une fois que vous avez ajouté Postgres, Redis, les logs et un processus de déploiement qui ne tient pas uniquement par miracle, vous dépassez déjà ce seuil un jour calme.

Dimensionnement réaliste pour les charges de travail courantes :

Quelques points à vérifier avant le provisionnement :

• Le stockage NVMe compte plus que la taille brute du disque : les applications Node modernes accèdent à des milliers de petits fichiers lors des installations, des builds et du démarrage. Des disques lents ralentissent nettement l'installation des dépendances, les démarrages à froid et les rebuilds SSR.
• Virtualisation KVM, pas OpenVZ : les anciennes offres basées sur OpenVZ partagent un noyau avec l'hôte, ce qui peut entraîner des versions de noyau obsolètes et des problèmes de compatibilité occasionnels avec les environnements d'exécution récents. La plupart des fournisseurs VPS sérieux n'utilisent plus que KVM, mais mieux vaut vérifier.
• Espace swap : activez 1 à 2 Go de swap sur les petits serveurs. Le tas V8 de Node peut varier fortement pendant le ramasse-miettes. Sans swap, un pic passager tue le processus. J'ai vu un serveur de 4 Go manquer de mémoire (OOM) pendant un déploiement de routine parce que quelqu'un avait désactivé le swap, le jugeant dépassé à l'ère de Docker.
• Bande passante : la plupart des offres VPS modernes incluent 1 à 4 To de bande passante mensuelle, de quoi couvrir presque tout sauf l'hébergement vidéo. Les offres VPS autogérées incluent une bande passante illimitée : une ligne de moins dans votre tableur de planification des capacités.

Un VPS de 4 Go coûte environ 15 $ par mois au prix du marché. Soit 50 cents par jour, ou à peu près un café d'aéroport toutes les deux semaines. Comparé au paiement séparé des environnements d'exécution, de Postgres géré et de Redis sur un PaaS, le calcul s'inverse étonnamment vite.

Quelle version de Node.js installer ?

Installez Node.js 24 (nom de code Krypton). C'est la version Active LTS actuelle, promue en octobre 2025 et prise en charge jusqu'en avril 2028 selon le calendrier officiel des versions de Node.js.

Beaucoup de tutoriels recommandent encore Node 22. Ces guides n'ont pas été mis à jour. Si vous lancez un nouveau déploiement aujourd'hui, fixez votre image CI et votre VPS sur Node 24.x.

Quelques règles empiriques :

• N'exécutez pas de versions Current (non LTS) en production : Node 26 sert à tester la compatibilité future et les nouvelles fonctionnalités de l'environnement d'exécution, pas à faire tourner l'application dont dépend votre chiffre d'affaires.
• Node 22 est la solution de repli si une dépendance critique n'est pas encore compatible avec Node 24 : la majeure partie de l'écosystème s'est stabilisée dans les quelques mois qui ont suivi le passage en LTS.
• Fixez votre version de Node partout : votre image CI, votre Dockerfile, votre .nvmrc et votre VPS de production doivent tous concorder. Le fameux « Ça marche sur ma machine » coûte vite cher dès que des modules natifs entrent en jeu.

🤔Vous envisagez Bun ? Il est plus rapide sur certaines charges de travail et vraiment impressionnant, mais son écosystème reste plus restreint et son historique en production plus court que celui de Node. Pour la plupart des équipes, le choix le plus sobre l'emporte.

NodeSource, qui maintient les dépôts apt et yum à partir desquels de nombreuses équipes installent Node en production, met en avant les améliorations de la branche 24.x, à commencer par un moteur V8 plus récent. Node 24 intègre aussi des outils désormais matures, comme node –watch et un exécuteur de tests natif stable (node: test), tous deux stabilisés dans les branches 20 à 22 et reconduits ici. Rien de spectaculaire. Cela réduit simplement un peu les frictions opérationnelles chaque mois.

Comment installer Node.js sur un VPS ?

Vous avez deux méthodes d'installation réalistes. Choisissez selon que le serveur exécute une ou plusieurs applications Node.

NodeSource pour un serveur à application unique

C'est la méthode de production la plus simple. Un script de configuration et un apt install suffisent pour obtenir la branche Node 24 LTS actuelle sous forme de paquet système, et les futures mises à jour de sécurité arrivent via les mises à niveau habituelles des paquets.

Sous Ubuntu ou Debian :

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

Vérifiez l'installation :

node -v
npm -v

Vous devriez 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 changer de version selon le projet

nvm (Node Version Manager) installe Node dans votre répertoire personnel et permet à différents projets d'utiliser différentes versions de Node. Pratique si vous hébergez plusieurs applications sur le même serveur ou si vous n'avez pas d'accès sudo.

Exécutez ceci avec l'utilisateur de votre application, pas en root :

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

Rechargez votre shell, puis installez Node 24 :

nvm install 24
nvm use 24
nvm alias default 24

👉Une règle importante : n'utilisez pas sudo ‘npm install -g’ pour les dépendances de votre application.

Les installations globales sont généralement réservées aux outils CLI au niveau de la machine, comme pm2, typescript ou nodemon. Les dépendances de votre application ont leur place dans package.json et doivent être installées depuis le répertoire du projet avec npm ci.

En cas de doute, commencez par NodeSource. La plupart des serveurs de production dédiés à un seul usage n'ont pas besoin de changer de version de Node selon le projet.

👉Utilisateurs d'un VPS DreamHost : l'application Node.js disponible au provisionnement est fournie avec Node.js 24 LTS, ainsi que fnm, PM2, Nginx et un certificat SSL Certbot : vous pouvez donc ignorer les étapes d'installation ci-dessus.

PM2 ou systemd : lequel choisir pour garder votre application en marche ?

Les deux fonctionnent. La réponse honnête : celui avec lequel votre équipe est à l'aise. PM2 est l'option pensée pour les développeurs, systemd l'option native d'Unix. Tous deux résolvent les trois mêmes problèmes : redémarrage en cas de plantage, lancement au démarrage et arrêt propre à la réception de « SIGTERM ».

Si vous partez de zéro, voici comment choisir :

Le démarrage rapide de PM2 porte bien son nom :

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # prints the systemd startup command to run
pm2 save       # saves the current process list

PM2 devient alors votre seul interlocuteur : « pm2 logs », « pm2 reload api », « pm2 monit ».

👉Bon à savoir : « pm2 startup » écrit une unité systemd, donc la configuration PM2 utilise en réalité systemd en coulisses.

Une unité systemd minimale pour gérer Node directement, dans « /etc/systemd/system/api.service » :

[Unit]Description=My Node APIAfter=network.target

[Service]Type=simpleUser=appWorkingDirectory=/var/www/apiExecStart=/usr/bin/node server.jsRestart=on-failureRestartSec=5Environment=NODE_ENV=productionStandardOutput=journalStandardError=journal

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

Si vous utilisez déjà PM2 et que tout fonctionne, ne migrez pas vers systemd simplement parce que quelqu'un l'a conseillé sur Hacker News. La mémoire consommée par le daemon PM2 n'est pas une raison de l'abandonner.

Migrez quand vous avez une vraie raison : par exemple, si vous exécutez une demi-douzaine de processus Node où chaque mégaoctet compte, ou si vous déployez dans un environnement ops où tous les autres services sont des unités systemd et où PM2 fait figure d'exception.

Comment placer NGINX (ou Caddy) devant votre application Node ?

Placer un proxy inverse devant Node se justifie pour cinq raisons : la terminaison HTTPS, la compression gzip/brotli, la distribution des ressources statiques, l'exécution de plusieurs applications sur le même serveur et une limitation de débit plus simple. Node peut faire tout cela. NGINX et Caddy le font mieux, et ils ne bloquent pas votre boucle d'événements quand quelque chose déraille.

Choisissez NGINX si quelqu'un dans votre équipe le connaît déjà. Choisissez Caddy si vous voulez HTTPS en trois lignes de configuration et qu'un écosystème de configuration avancée plus restreint ne vous dérange pas.

Configuration NGINX minimale

Placez ce bloc de proxy dans /etc/nginx/sites-available/api, créez un lien symbolique vers sites-enabled, puis exécutez 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 qui assurent la prise en charge des WebSockets. La documentation de NGINX elle-même souligne qu'Upgrade est un en-tête hop-by-hop (de saut à saut) : il doit donc être traité explicitement lors du proxy du trafic WebSocket.

Conservez-les si votre application utilise des WebSockets aujourd'hui, ou pourrait en utiliser plus tard. Socket.IO, les abonnements GraphQL via WebSockets et un nombre étonnant de fonctionnalités temps réel ordinaires dépendent de cette négociation de mise à niveau.

Le bug de production le plus fréquent que je rencontre dans les configurations Node, c'est un serveur Socket.IO derrière NGINX sans ces deux lignes. Les connexions échouent par intermittence, les développeurs accusent Socket.IO, alors que le vrai problème vient généralement de la configuration du proxy.

Caddyfile minimal

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

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

C’est tout le fichier. Tant que le domaine pointe vers le serveur et que les ports 80/443 sont accessibles, Caddy provisionne et renouvelle le HTTPS automatiquement. D’après la documentation de Caddy, le HTTPS automatique provisionne des certificats TLS pour les sites et les renouvelle. Son guide de démarrage rapide du reverse proxy précise aussi que le HTTPS est automatique dès que Caddy connaît le nom d’hôte.

Liez Node à localhost, pas à 0.0.0.0

Quel que soit le proxy choisi, configurez votre application Node pour qu’elle écoute sur 127.0.0.1:3000, et non sur 0.0.0.0:3000. Sur un serveur Node, seul le proxy doit être exposé à l’internet public. Associez cette configuration à UFW, l’interface de pare-feu courante d’Ubuntu, pour tout bloquer sauf les ports 22, 80 et 443.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Si SSH tourne sur un port personnalisé, autorisez ce port avant d’activer UFW.

Liez Node à localhost dès le premier jour. La réunion où quelqu’un avoue que l’application était exposée parce que Node écoutait sur 0.0.0.0, vous préférez l’éviter.

Comment configurer HTTPS pour votre application Node.js ?

Utilisez Let’s Encrypt. C’est gratuit, automatisé et reconnu par tous les navigateurs. Deux approches existent, selon le proxy que vous avez choisi.

NGINX + Certbot

Faites pointer un enregistrement A vers l’IP de votre VPS et attendez la propagation DNS.

Installez Certbot :

apt install certbot python3-certbot-nginx

Exécutez :

certbot --nginx -d api.example.com

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

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

Ouvrez https://api.example.com et vérifiez que l’icône de cadenas s’affiche.

La documentation officielle de Certbot décrit aussi l’installation via snap si le paquet de votre distribution est obsolète.

Caddy

Ajoutez le domaine au Caddyfile (l’exemple ci-dessus l’inclut déjà), puis redémarrez Caddy. Tant que le domaine se résout correctement et que les ports 80/443 sont accessibles, le certificat est provisionné automatiquement au premier démarrage. Pas besoin de Certbot.

En production, ne terminez pas le TLS dans Node lui-même.

Le module https de Node fonctionne parfaitement, mais les reverse proxies comme NGINX et Caddy sont conçus spécialement pour la terminaison TLS. Ils vous offrent d’emblée l’agrafage OCSP, des suites de chiffrement modernes par défaut, le renouvellement automatique des certificats, la prise en charge de HTTP/2 et, dans le cas de Caddy, celle de HTTP/3.

Pourriez-vous gérer tout cela directement dans Node ? Bien sûr. Vous ne feriez que reconstruire une infrastructure que votre proxy gère déjà extrêmement bien.

À quoi ressemble vraiment une configuration Node.js prête pour la production ?

Huit écueils piègent les gens en production. La plupart ne figurent pas dans les tutoriels d’installation, car ils ne rentrent pas dans le schéma installer Node, lancer l’application. Ce sont pourtant eux qui font la différence entre une application qui passe le cap du deuxième mois et une autre qui n’y arrive pas.

• NODE_ENV=production : l’étape la plus souvent oubliée. Dans de nombreux frameworks et bibliothèques Node, elle désactive les comportements réservés au développement et active les optimisations de production. Express, par exemple, met en cache les templates de vues compilés et renvoie des erreurs plus succinctes en production ; sa propre documentation évoque des performances jusqu’à 3 fois meilleures. Définissez cette « variable d’environnement » partout.
• Arrêt propre : quand votre VPS redémarre ou que PM2 envoie « SIGTERM », votre application dispose de quelques secondes pour terminer les requêtes en cours, fermer les connexions à la base de données et s’arrêter proprement. Mettez en place un gestionnaire « process.on(‘SIGTERM’, …) ». Le délai d’arrêt par défaut de PM2 dépend de la configuration et de l’environnement : ne comptez donc pas toujours sur beaucoup de temps pour faire le ménage.
• Rotation des logs : pour PM2, c’est le module « pm2-logrotate » qui s’en charge. Pour les unités systemd directes, c’est le journal systemd. Sans rotation, vos logs remplissent le disque quatre fois plus vite que prévu.
• Rigueur avec le fichier .env : ne commitez jamais de secrets et ne les journalisez jamais. Utilisez « dotenv » en développement local. En production, définissez les variables d’environnement via la directive « Environment= » de votre unité systemd ou votre fichier ecosystem PM2. Le jour où vous lancez un « console.log(process.env) » par accident, c’est le jour où vous changez tous vos identifiants.
• Un reverse proxy devant Node : liez Node à localhost et laissez NGINX ou Caddy faire face à l’internet public.
• Un pare-feu : avec UFW, bloquez tout sauf les ports 22, 80 et 443. Déplacer SSH hors du port 22 n’arrêtera pas un attaquant déterminé, mais cela réduit considérablement le bruit des attaques automatisées par force brute et les logs d’authentification parasites.
• Supervision : un endpoint de healthcheck que votre outil de supervision interroge chaque minute. PM2 propose les bases en natif. Pour un usage sérieux, déployez Prometheus et Grafana, ou utilisez un service hébergé de suivi de disponibilité comme Better Stack ou UptimeRobot. Vous voulez savoir que votre application est en panne avant qu’un client ne vous le signale.

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

Des mises à jour apt, quelques montées de version de dépendances et un coup d’œil trimestriel au volume de logs. C’est la contrepartie des économies et du contrôle gagnés.

Quand un VPS est-il un mauvais choix pour Node.js ?

Un VPS n’est pas le bon choix quand votre charge de travail est conçue pour autre chose. Soyez honnête sur votre situation avant de provisionner.

• Sites statiques et contenu SSG : un export Next.js, Astro, Gatsby ou un blog Eleventy. Des plateformes comme Vercel, Netlify ou Cloudflare Pages vous offrent d’emblée un hébergement statique mis en cache à l’échelle mondiale, des déploiements basés sur Git et des reconstructions automatiques. Pour du contenu purement statique, un VPS est généralement une infrastructure superflue.
• Charges de travail ponctuelles et événementielles : Cloudflare Workers et AWS Lambda coûtent peu pour des webhooks exécutés dix fois par jour.
• Applications temps réel nécessitant plus de 100 000 connexions simultanées : un seul VPS ne permet pas de mise à l’échelle horizontale. Il vous faudra de l’orchestration (Kubernetes, ECS, Nomad) ou une plateforme temps réel gérée comme Ably ou Pusher.
• Charges de travail réglementées, aux fortes exigences de conformité : HIPAA, PCI-DSS niveau 1, FedRAMP. Un PaaS géré disposant de certifications de conformité intégrées vous épargne bien des difficultés lors des audits. Assurer vous-même la conformité sur un VPS est un projet de plusieurs trimestres dont vous ne voulez probablement pas.
• Pas à l’aise avec Linux, et aucune envie de le devenir : des plateformes comme Render, Railway et DigitalOcean App Platform se situent entre l’hébergement VPS brut et le PaaS entièrement géré. Des outils comme Dokploy ajoutent des workflows de déploiement à la Heroku sur votre propre infrastructure VPS. Vous conservez une bonne partie des avantages en coût et en contrôle, sans devoir maîtriser en profondeur iptables, les rouages de systemd ou le débogage de reverse proxy à 1 h du matin.

Aucune de ces réponses n’a de quoi rougir. La meilleure décision technique est celle qui correspond à votre charge de travail.

Choisir votre stack Node et vous installer

Ouvrez cette facture d’hébergement une dernière fois.

Vous êtes sur le point d’en remplacer une part étonnante par une seule facture de VPS.

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

Lancez le plus petit plan VPS qui offre la RAM que vous avez estimée, installez Node, exécutez votre application sur « 127.0.0.1 », faites pointer NGINX vers elle et basculez votre DNS.

Si l’application survit à un déploiement, à un redémarrage et à une nuit de fonctionnement sans incident, vous avez fait l’essentiel.

Le reste, c’est de la maintenance. Une heure ou deux par mois, une fenêtre « apt upgrade » de temps en temps, une montée de version des dépendances chaque trimestre. C’est le marché que vous avez conclu en échangeant une facture par utilisateur contre un forfait fixe, et le Stack 4 VPS autogéré de DreamHost est un bon point de départ.

Questions fréquentes sur l'exécution de Node.js sur un VPS