Comparateur indépendant · sans classement payant
Accueil / Blog / Héberger sa première application Node.js sans la traiter comme un site PHP
Guide

Héberger sa première application Node.js sans la traiter comme un site PHP

Node.js tourne en processus long, pas en requête PHP éphémère. PM2, reverse proxy, variables d'environnement et port d'écoute changent tout — dès la première app Express ou Nest.

6 min Mis à jour 19 juil. 2026

Un développeur envoie son application Express par FTP sur un hébergement mutualisé PHP. Rien ne démarre : pas de node server.js permanent, pas de port 3000 exposé, pas de reverse proxy configuré. Ce n'est pas Node.js qui est « compliqué » — c'est Node.js hébergé comme du PHP, où chaque requête lancerait un interpréteur qui meurt aussitôt.

Héberger sa première application Node.js, c'est accepter un modèle d'exécution différent. PHP-FPM traite des requêtes courtes ; Node.js maintient un processus vivant qui garde l'état en mémoire, écoute un port HTTP et attend des connexions. Sans process manager, proxy et redémarrage automatique, la première vague de trafic — ou le premier arrêt brutal du processus — met fin à votre « mise en production ».

PHP et Node.js : deux modèles d'exécution

AspectPHP classique (FPM)Node.js
ProcessusCourt, par requêteLong, persistant
ÉcouteVia Apache ou nginx vers FPMPort HTTP propre
État en mémoireLimitéSessions, cache applicatif possibles
DéploiementFichiers + OPcachenpm ci, build, redémarrage du processus
Montée en chargePlus de workers FPMCluster PM2, instances multiples

Traiter Node.js comme du PHP, c'est demander à un restaurant de réchauffer le four à chaque commande.

Sur un mutualisé PHP, le serveur web sait exécuter des fichiers .php. Il ne sait pas garder un processus Node.js actif entre deux requêtes. Même si vous uploadez server.js, personne ne le lance — et personne ne le relance s'il plante à 3 h du matin.

Stack minimale pour une première production

1. Build en intégration continue. npm ci, tests automatisés, npm run build si un frontend est compilé. La production reçoit un artefact testé, pas un git pull improvisé.

2. Gestionnaire de processus. Fichier ecosystem PM2 ou unité systemd avec Restart=always. Le processus doit survivre aux erreurs non capturées et redémarrer au boot du serveur.

3. Reverse proxy. nginx avec proxy_pass vers 127.0.0.1:PORT. Node.js n'expose pas directement le port 3000 sur Internet — le proxy gère TLS, les en-têtes et la compression.

4. Chiffrement TLS. Let's Encrypt sur nginx, pas dans Node.js sauf contrainte spécifique. Renouvellement automatisé et rechargement nginx documenté.

5. Variables d'environnement. NODE_ENV=production, secrets via variables d'environnement — jamais commités dans le dépôt. Un fichier .env sur le serveur, permissions restreintes.

6. Journaux. stdout et stderr agrégés ; rotation si écriture sur disque. Sans logs centralisés, un crash nocturne reste invisible jusqu'au lundi matin.

7. Contrôle de santé. Route /health pour la supervision et le répartiteur de charge. Sans elle, un processus zombie peut rester « en ligne » sans servir de requêtes.

Choisir le bon hébergeur

OptionPour qui
PaaS Node (Railway, Clever Cloud, Heroku-like)Première application, peu d'exploitation
VPS + PM2Contrôle total, coût prévisible
Conteneur (Docker, Kubernetes)Équipe déjà containerisée

Évitez les offres « mutualisé PHP illimité » sans mention explicite de Node.js — ce n'est pas le bon produit. Comparez les offres PaaS et VPS dans notre annuaire et le comparateur. Pour la culture du déploiement long-running, voir aussi Django en production et PM2 et déploiement — autres stacks, mêmes principes.

Erreurs classiques à la première mise en production

  • node_modules uploadés depuis Windows vers Linux sans reconstruction des modules natifs — bcrypt, sharp et sqlite3 plantent silencieusement.
  • Application qui écoute 0.0.0.0 sans pare-feu — le port Node.js est exposé directement, contournant nginx.
  • Pas de limite mémoire — une fuite JavaScript tue le serveur entier après quelques heures.
  • WebSockets oubliés dans la configuration nginx — les en-têtes Upgrade et Connection manquent, le temps réel ne fonctionne pas.
  • Déploiement = git pull sans redémarrage PM2 — l'ancien code tourne encore en mémoire.

Chaque erreur est prévisible. Aucune n'est une fatalité si vous testez le cycle complet avant d'annoncer la mise en ligne.

Le sommet : Node.js demande un hôte qui laisse vivre un processus

Voici ce que les tutoriels « déployez en cinq minutes » oublient de dire.

Décider et avancer sans angle mort

Sur une journée, vous pouvez poser les fondations d'une vraie production Node.js :

  1. Validez une offre Node.js, PaaS ou VPS avec accès root.
  2. Configurez PM2 ou systemd, puis nginx en reverse proxy.
  3. Automatisez le déploiement avec redémarrage du processus à chaque release.
  4. Testez la reprise après crash — tuez le processus manuellement et vérifiez le redémarrage.
  5. Surveillez la mémoire et le nombre de redémarrages PM2.

Commencez par valider que votre hébergeur autorise bien un processus persistant — c'est le prérequis non négociable. Ensuite, documentez qui modifie la configuration, comment relancer nginx après renouvellement TLS, et où lire les journaux en cas d'incident. Pour aller plus loin sur les fuites mémoire, consultez Fuite mémoire Node.js.

Questions fréquentes

Peut-on héberger Node.js sur un mutualisé PHP ?

Rarement. Un mutualisé PHP ne maintient pas de processus Node.js persistant, n'expose pas de port personnalisé et ne configure pas de reverse proxy vers votre application. Cherchez une offre Node.js dédiée, un PaaS ou un VPS.

PM2 ou systemd en production ?

Les deux fonctionnent. PM2 simplifie le mode cluster et le rechargement sans coupure ; systemd s'intègre nativement au journal système Linux. Dans les deux cas, le redémarrage automatique après crash et au boot du serveur est obligatoire.

Faut-il nginx devant Node ?

Oui en pratique : nginx gère le chiffrement TLS, HTTP/2, les fichiers statiques et la limitation de débit. Node.js écoute en local sur un port interne, nginx achemine le trafic public vers lui.

Comment déployer sans interruption de service ?

Utilisez le rechargement PM2, un déploiement blue-green ou deux instances derrière un répartiteur de charge. Construisez toujours avec npm ci en intégration continue, jamais à la main sur le serveur de production.


Node.js en production, ce n'est pas un fichier uploadé — c'est un processus que quelqu'un doit veiller à garder en vie.

Comparez les hébergeurs européens

Filtrez par conformité, localisation et usage — puis ouvrez les fiches pour vérifier le périmètre réel.

Voir l'annuaire
Blog

À lire aussi

Tous les articles →