Installer PM2 proprement - Évitez les erreurs courantes en production

Installer PM2 correctement, ce n’est pas seulement ajouter un binaire sur une machine Node.js. C’est mettre en place un gestionnaire de processus qui relance votre application après un crash, garde des logs exploitables et reste simple à administrer sur un VPS ou en production. Je fais aussi une distinction utile dès le départ : pm2 install sert surtout à ajouter des modules PM2, alors que le cœur de l’outil s’installe via npm ou yarn.

Choisir la bonne méthode d’installation selon votre machine

La documentation officielle de PM2 met l’installation globale via npm en première ligne, et c’est aussi le chemin que je recommande dans la majorité des cas. Sur un serveur de production classique, je cherche surtout une chose : un binaire accessible, prévisible et installé dans le même contexte que Node.js. Si votre machine est déjà standardisée autrement, Yarn reste une alternative correcte, et un script dédié existe pour les environnements Debian bien cadrés.

Sur Windows, PM2 reste utilisable, mais je le choisis surtout quand je n’ai pas de meilleur standard en place ; pour une prod simple, Linux reste le terrain le plus fluide. Dans un contexte avec NVM ou un autre gestionnaire de versions Node, je préfère éviter de mélanger les utilisateurs et les privilèges : l’installation doit vivre dans le même environnement que Node lui-même. Une base propre à ce stade évite déjà une bonne partie des incidents de déploiement, et c’est la suite logique avant de tester le binaire.

Vérifier que le binaire répond bien dans le shell

Une fois installé, je ne passe jamais directement au déploiement. Je vérifie d’abord que le shell voit bien PM2 et que la session courante n’est pas en train de me mentir à cause d’un ancien PATH, d’un alias ou d’une installation globale faite avec un autre utilisateur. C’est une étape courte, mais elle évite de perdre du temps sur des faux problèmes.

pm2 -v
which pm2
pm2 completion install

Le test de version me dit immédiatement si le binaire est accessible. Si pm2 n’est pas trouvé, le souci vient souvent du shell ou d’une installation globale faite dans un autre contexte utilisateur, pas de PM2 lui-même. J’active aussi l’autocomplétion très tôt : ce n’est pas spectaculaire, mais sur une machine que l’on administre souvent, ça limite les fautes de frappe et les commandes mal relues.

Si vous utilisez un gestionnaire de versions comme NVM, réouvrez le terminal après l’installation et gardez Node et PM2 dans le même environnement utilisateur. Une fois que ce point est clair, on peut passer au lancement de la première application sans se battre avec l’outillage.

Lancer une application et comprendre ce que PM2 change

PM2 devient utile au moment où vous cessez de le voir comme un simple paquet et commencez à l’utiliser comme superviseur de service. Le démarrage le plus simple suffit souvent pour une API Express ou un backend Node classique, mais il faut le faire avec un minimum de discipline : un nom clair, des logs lisibles et des options adaptées au contexte.

Le démarrage le plus simple

Pour une première application, je pars sur un lancement explicite plutôt que sur une commande vague. Le nom de processus aide à retrouver la bonne entrée quand il y en a plusieurs, et les logs deviennent immédiatement plus lisibles.

pm2 start app.js --name api
pm2 ls
pm2 logs api

J’utilise --watch seulement en développement. En production, ce mode peut devenir trop sensible et provoquer des redémarrages à répétition à cause d’un fichier généré, d’un upload ou d’un artefact de build. Une bonne règle de base : ce qui aide à itérer vite en local n’aide pas toujours à stabiliser un service en ligne.

Le mode cluster quand l’application est vraiment stateless

Si l’application sert principalement du HTTP et ne dépend pas d’une mémoire locale unique, le mode cluster mérite d’être envisagé. Il répartit la charge entre plusieurs instances sur les cœurs disponibles, ce qui est utile quand le serveur a de la ressource et que le code tolère plusieurs processus. Je le vois comme un vrai gain opérationnel, mais pas comme une solution universelle : il faut encore gérer les sessions, la persistance et les dépendances externes correctement.

pm2 start app.js -i max

En pratique, c’est souvent dans ce scénario que PM2 montre sa valeur la plus visible : l’application continue de répondre même si une instance tombe, et le redémarrage se fait sans interaction manuelle. Quand il y a plusieurs services à orchestrer, la structure suivante devient encore plus importante : la persistance au reboot.

Lire aussi : Installer Composer sur Ubuntu - Guide Complet et Sans Erreurs

Le fichier ecosystem quand le projet grandit

Dès qu’un projet a plusieurs services, des variables d’environnement ou des paramètres de lancement différents selon l’environnement, le fichier d’écosystème devient plus lisible que des commandes longues recopiées à la main. Il ne change pas PM2 lui-même, mais il réduit les écarts entre développement, préproduction et serveur final. Pour une équipe, c’est aussi un moyen simple d’éviter les “ça marche chez moi” au moment du passage en production.

Rendre le process survivable aux redémarrages

Le point que beaucoup découvrent trop tard, c’est que l’installation ne suffit pas : sans script de démarrage, les processus repartent mal ou pas du tout après un reboot. C’est précisément là que pm2 startup et pm2 save font la différence.

pm2 startup
pm2 save

pm2 startup génère l’intégration au système d’init adapté à la machine, puis pm2 save fige la liste des processus à restaurer. Après une modification importante de votre parc de processus, je refais souvent pm2 save pour éviter les surprises au prochain redémarrage. Si vous mettez PM2 à jour, pm2 update permet aussi de rafraîchir le daemon proprement sans perdre la logique de reprise.

Une fois ce socle en place, la vraie question n’est plus “PM2 est-il installé ?” mais “qu’est-ce qui peut encore casser au quotidien ?”. C’est là que les erreurs classiques méritent d’être regardées de près.

Les erreurs que je corrige le plus souvent après une installation

• Installer en root, puis lancer l’application avec un autre utilisateur. Le résultat : des processus invisibles ou des droits incohérents.
• Oublier que chaque environnement Node géré par NVM a ses propres paquets globaux. Changer de version peut faire “disparaître” PM2 du PATH.
• Confondre installation et persistance. Sans pm2 startup et pm2 save, le reboot casse la continuité.
• Activer --watch en production sans contrôle. C’est utile en développement, pas comme garde-fou en serveur.
• Ignorer les logs. Si pm2 logs reste vide ou illisible, le problème est souvent dans votre application, pas dans PM2.
• Penser que PM2 remplace le déploiement, le reverse proxy ou la gestion des secrets. Il supervise un processus, il ne remplace pas l’architecture autour.

Je vois aussi souvent une confusion entre outil de supervision et chaîne de livraison. PM2 aide à maintenir un service en vie, mais il ne corrige pas une application mal configurée, un port déjà occupé ou une stratégie de déploiement fragile. Si l’installation semble “faite” mais que l’exploitation reste pénible, le problème n’est presque jamais la commande d’installation : c’est le cadre autour.

Ce que je vérifie avant de considérer l’installation comme prête pour la prod

• Un seul utilisateur administre PM2 et exécute l’application.
• Chaque service a un nom clair et un point d’entrée explicite.
• Le shell trouve pm2 sans bricolage.
• Le redémarrage système a été anticipé avec pm2 startup et pm2 save.
• Les logs, la rotation et une surveillance minimale sont déjà prévus.

Si vous cochez ces points, l’installation de PM2 devient réellement utile en exploitation, pas seulement “réussie” sur le papier. C’est ce petit ensemble de vérifications qui fait la différence entre un service qu’on surveille sereinement et un service qu’on doit babysitter après chaque incident.