Comment installer Node.js sur un serveur dédié

Node.js est un runtime JavaScript qui exécute votre code applicatif en dehors du navigateur, et npm est l'outil de paquets livré avec. Le poser sur du bare metal donne à l'event loop un processeur entier et un disque entier, sans hyperviseur entre votre processus et le matériel. Ce guide couvre le chemin complet d'un serveur vierge à un déploiement prêt pour la production : NVM, npm, PM2 en mode cluster, Nginx comme reverse proxy, SSL et pare-feu. Le matériel démarre à 9,99 €/mois.

Prérequis et exigences système

• Un serveur sous Ubuntu 24.04 ou 26.04 LTS, Debian 12, ou une distribution RPM comme Rocky ou Alma.

• Un accès root ou un compte avec droits sudo, plus l'adresse IP envoyée par e-mail après le provisioning.

• Un nom de domaine avec un enregistrement A pointant vers cette IP, si vous voulez du SSL.

• Un client SSH. Terminal sur macOS et Linux, PowerShell ou PuTTY dans une fenêtre Windows.

Node lui-même est léger. Ce que vous y exécutez décide de la configuration :

Se connecter au serveur dédié via SSH

Ouvrez une fenêtre de terminal et connectez-vous avec les identifiants de votre fournisseur :

ssh root@YOUR_SERVER_IP

Puis créez un utilisateur standard, parce que faire tourner une app en root est la première chose qu'un audit relèvera :

adduser nodeapp && usermod -aG sudo nodeapp
su - nodeapp

Mettez à jour les paquets de base avant toute autre chose :

apt update && sudo apt upgrade -y

Sur une distribution RPM, la paire équivalente est sudo dnf check-update et sudo dnf upgrade. Chaque instruction après cette étape s'exécute comme l'utilisateur nodeapp sauf mention contraire.

Installer NVM (Node Version Manager)

NVM est un script bash qui installe Node.js dans votre home. Pas de sudo, pas de conflit avec le gestionnaire de paquets de l'OS, et vous pouvez basculer entre les versions par projet, ce qui en fait le bon outil pour un environnement de développement comme pour un serveur.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
command -v nvm

L'installateur ajoute ses propres lignes à ~/.bashrc. Si command -v nvm n'imprime rien, ouvrez un nouveau shell ou ressourcez le fichier.

💡 Astuce N'installez pas Node depuis apt ou dnf sur une machine qui fait tourner des applications. Les paquets de distribution prennent des mois de retard sur la ligne de release, et les avancer signifie toucher des fichiers système. NVM garde Node.js dans votre répertoire home, là où il doit être.

Installer Node.js et npm via NVM

Les lignes paires de Node.js deviennent LTS chaque octobre et restent supportées trente mois. Le drapeau --lts se résout toujours vers l'Active LTS courant, donc vous n'avez jamais à suivre le numéro :

nvm install --lts
nvm use --lts
nvm alias default lts/*

La troisième commande compte. Sans alias par défaut, une nouvelle session shell démarre sans aucun Node, et PM2 ne trouvera pas le binaire.

npm arrive avec Node, donc il n'y a rien d'autre à installer. Si vous préférez yarn :

npm install -g yarn
yarn --version

Vérifier l'installation

Trois commandes confirment l'installation de Node.js, et la dernière montre où le binaire réside réellement :

node -v
npm -v
which node
nvm ls

Le chemin pointe à l'intérieur de ~/.nvm/versions/node/, le signe que NVM possède cette installation de Node.js plutôt que le système. nvm ls imprime chaque version sur la machine et marque le défaut. Si node -v échoue après un reboot, l'alias par défaut manque.

✅ Résultat attendu node -v et npm -v impriment tous deux des numéros de version, et which node se résout sous votre répertoire home.

Listez ce que npm a installé globalement à tout moment, ce qui est le moyen le plus rapide de voir quel jeu d'outils est sur le serveur :

npm ls -g --depth=0

Une installation Node.js fraîche ne montre que npm et corepack. Chaque paquet global ajouté ensuite, comme PM2 ou yarn, apparaît dans cette fenêtre de sortie, et chaque module qu'il tire vit sous le même préfixe.

Créer une application Node.js d'exemple

Créez quelque chose de minimal pour prouver que la chaîne fonctionne de bout en bout, avant que Nginx et le SSL ne compliquent le tableau. Deux étapes : un package.json, puis un script unique.

mkdir ~/nodeapp && cd ~/nodeapp
npm init -y

npm init -y écrit un package.json avec des valeurs raisonnables, le fichier de configuration que chaque outil Node.js lit. Créez maintenant le fichier d'entrée :

const http = require('http');
const port = process.env.PORT || 3000;
http.createServer((req, res) => {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('nodeapp is running\n');
}).listen(port);

Puis exécutez le script et vérifiez la réponse depuis une seconde fenêtre de terminal :

node app.js
curl http://localhost:3000

✅ Résultat attendu curl retourne la chaîne, ce qui signifie que votre app Node.js écoute sur le port 3000.

Installer et configurer le gestionnaire de processus PM2

Exécuter le fichier à la main meurt quand vous fermez le shell. PM2 est le gestionnaire de processus qui corrige cela : c'est l'outil qui garde l'app en vie, la redémarre après un crash, fait tourner les logs et pilote le cluster. La même configuration garde un bot Discord en ligne 24/7.

npm install -g pm2
cd ~/nodeapp
pm2 start app.js --name nodeapp -i max

Le drapeau -i max est le plus intéressant. Il lance PM2 en mode cluster, forkant un worker par cœur de CPU, si bien qu'une machine quatre cœurs fait tourner quatre copies de votre app Node.js derrière un seul port. Aucun changement de code n'est requis : le module cluster de Node.js fait le travail dessous, et PM2 le pilote. En mode cluster, PM2 recharge aussi les workers un par un, si bien qu'un déploiement ne cause aucun downtime. Le mode cluster, c'est là que le bare metal se paie lui-même : sur une plateforme partagée ces cœurs ne sont pas vraiment à vous.

pm2 status
pm2 logs nodeapp
pm2 monit

💡 Astuce Gardez la configuration dans des variables d'environnement plutôt que dans le code. PM2 lit un fichier .env ou une config ecosystem, et process.env.PORT dans l'exemple ci-dessus est déjà calibré pour ça.

Configurer Nginx comme reverse proxy

Votre app écoute sur 3000. Nginx écoute sur 80 et 443 et fait passer les requêtes, ce qui vous laisse ajouter SSL, compression et rate limiting sans toucher au code applicatif.

sudo apt install -y nginx
nano /etc/nginx/sites-available/nodeapp

Écrivez le server block :

server {
  listen 80;
  server_name example.com;
  location / {
    proxy_pass http://localhost: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;
  }
}

Les deux en-têtes websocket sont ce qui fait vivre une connexion en direct à travers le proxy. Tout le reste de ce server block est de la configuration Nginx standard, détaillée pas à pas dans notre guide du reverse proxy NGINX, si bien que vous pouvez le copier pour une seconde app Node.js sur un autre port. Liez le site en place et rechargez :

sudo ln -s /etc/nginx/sites-available/nodeapp /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

⚠️ Attention Retirez le site d'origine sous sites-available, sinon sa page de bienvenue continue de répondre sur votre domaine au lieu de votre app.

Sécuriser le serveur avec SSL (Let's Encrypt)

Certbot lit votre configuration Nginx, demande un certificat pour le domaine qu'il y trouve, et réécrit la configuration pour rediriger le port 80 vers le 443 :

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
certbot renew --dry-run

Le dry run prouve que le timer de renouvellement fonctionne. Les certificats durent quatre-vingt-dix jours, si bien qu'un renouvellement qui échoue en silence prend le site bas trois mois après que vous avez cessé de faire attention. Rien dans la configuration Node.js ne change : Nginx termine le TLS et l'app continue de servir du HTTP simple sur localhost.

Optimiser pare-feu et réglages de sécurité

Fermez tout sauf SSH et HTTPS. Le port 3000 ne doit pas être joignable de l'extérieur :

ufw allow OpenSSH
ufw allow 'Nginx Full'
sudo ufw enable && ufw status

Désactivez la connexion par mot de passe. Posez PasswordAuthentication no dans /etc/ssh/sshd_config et utilisez des clés. Ce seul réglage supprime toute la classe des attaques par devinette de mot de passe contre le serveur.

Désactivez le SSH root. Posez PermitRootLogin no dans le même fichier de configuration, puis rechargez sshd.

Bind l'app sur localhost. Changez .listen(port) en .listen(port, '127.0.0.1') dans le code, si bien que le processus ne peut être joint qu'à travers Nginx.

Gardez les dépendances npm à jour. Exécutez npm audit avant chaque build et traitez une découverte de sévérité haute comme un bloqueur. Suivez le même jeu d'instructions chaque fois plutôt que d'improviser par release.

Notre guide complet pour faire tourner un site web couvre le tableau plus large du durcissement.

Activer le démarrage automatique au reboot

PM2 ne survit pas seul à un reboot. Générez l'unité systemd et sauvegardez la liste de processus courante. C'est l'étape finale, et la sauter est la façon la plus courante dont un serveur Node.js revient vide :

pm2 startup systemd
pm2 save

La première commande imprime une ligne sudo env .... Copiez-la, exécutez-la exactement comme imprimée, puis lancez pm2 save pour stocker ce qui tourne. C'est ce qui survit au reboot. Rebootez et vérifiez :

reboot
pm2 status

✅ Résultat attendu Après le retour du serveur, pm2 status liste nodeapp en ligne sans aucune étape manuelle.

Conseils de dépannage courants

Conclusion

Vous avez maintenant une app Node.js qui tourne sous PM2 en mode cluster, derrière Nginx en HTTPS, sur une machine pare-feutée qui ramène tout après un reboot. Le travail restant est le déploiement : un dépôt git, une étape de build, et un script de pull-and-reload plutôt que d'éditer les fichiers sur le serveur en place. Gardez les mêmes instructions dans vos notes, parce que la prochaine app Node.js sur le même serveur les suit inchangées.

FAQ