Hosting Node.js i Next.js. Wypychasz kod, strona działa.

1. Node.js demande une solution intermédiaire entre le PaaS et un serveur bare metal

Pour une application Node.js, le premier choix est souvent le modèle des plateformes PaaS (Platform as a Service): tu fais un git push et l’application fonctionne, sans avoir à gérer de serveur. Le problème survient au moment de la facturation: la plupart de ces plateformes facturent en dollars, avec des tarifs qui grimpent rapidement lorsque le trafic réel de production augmente, tandis que l’infrastructure physique se trouve hors de Pologne.

Sur Saplo, l’application Node.js est déployée comme un starter Express prêt à l’emploi, avec le choix de la version de Node.js (18, 20 ou 22, 20 par défaut). Tu peux la remplacer par ton propre code grâce à git deploy: un push vers le dépôt met automatiquement à jour l’application en cours d’exécution, sans te connecter manuellement au serveur après chaque modification.

Le manifeste de l’application indique un minimum de 512 Mo de RAM et 3 Go de disque. Ainsi, même Box S (1 Go de RAM) peut techniquement héberger une application Node.js simple. Pour un usage plus sérieux qu’un prototype, envisage Box M avec un accès SSH complet.

2. Git deploy vs upload manuel

Avec git deploy, le dépôt de code devient l’unique source de vérité sur ce qui s’exécute en production: un push vers la branche définie déclenche la mise à jour de l’application sur Box, sans devoir transférer manuellement des fichiers via FTP ni les copier via SSH après chaque modification du code.

Pour une équipe qui travaille à plusieurs sur la même application Node.js, c’est une vraie différence: chaque commit qui arrive sur la bonne branche se retrouve immédiatement sur le serveur, ce qui facilite l’itération rapide sans étapes de déploiement supplémentaires au-delà du git push.

À partir de Box M, l’accès SSH avec sudo permet aussi de gérer manuellement le processus Node.js, par exemple le redémarrer après une modification des variables d’environnement ou installer des paquets système supplémentaires requis par certaines dépendances npm. Ce n’est pas toujours possible uniquement avec git deploy.

3. Pourquoi pas un VPS classique?

Sur un VPS vierge de chez Concurrent A (1 vCPU, 2 GB RAM, 20 GB de disque pour 11 €/mois HT, tarifs publics, état au 2026-10-10), le déploiement d’une application Node.js exige l’installation manuelle de Node, d’un gestionnaire de processus (par ex. PM2), d’un proxy inverse et d’un certificat SSL, avant que l’application ne soit accessible publiquement via un domaine en https.

Sur Saplo, ces éléments (proxy inverse nginx, SSL, gestionnaire de processus dans un conteneur) sont configurés automatiquement lors de l’installation depuis le catalogue d’applications. Entre le choix de la version de Node.js et la mise en ligne d’une application accessible publiquement sous ton propre domaine, il ne faut que quelques minutes, et non plusieurs heures de configuration manuelle du serveur.

Le coût est comparable à celui d’un VPS aux ressources similaires, mais sans avoir à administrer le système d’exploitation et sans risquer qu’une erreur de configuration du pare-feu ou lors d’une mise à jour du système ne mette l’application hors service pour une raison sans lien avec le code Node.js.

4. Plusieurs applications Node.js sur un même Box

Sur un même Box, tu peux exécuter simultanément plusieurs projets Node.js indépendants (API, panneau d’administration, microservice distinct, etc.). Chacun tourne dans son propre conteneur LXC, avec son propre domaine ou sous-domaine, sans conflit de ports entre les projets.

Pour les applications qui utilisent une base de données, Saplo propose des modules dédiés (Postgres, MySQL, Redis) déployés dans une configuration Compose séparée, sans supplément. L’association classique de Node.js et d’une base de données reste donc naturelle, sans coût supplémentaire pour la base. Déployer une base comme nouvelle application sur le même Box prend autant de temps que son installation depuis le catalogue, sans contrat distinct avec un fournisseur cloud de bases de données.

5. À qui cela s'adresse

Pour un développeur qui crée un backend API simple ou un microservice, Box M avec un accès SSH complet et le déploiement git fournit rapidement un environnement de production, sans avoir à configurer un serveur à partir de zéro.

Pour une startup qui développe plusieurs services Node.js en parallèle (API, panneau, worker), Box L permet de tous les déployer sur un même compte, dans des conteneurs distincts, sans facture séparée pour chaque microservice auprès de différents fournisseurs PaaS.

Pour quelqu’un qui migre depuis une plateforme PaaS étrangère facturée en dollars, Saplo offre un confort de déploiement similaire (git push), mais avec une facturation en PLN et une infrastructure située dans un centre de données européen.

6. Premier déploiement d’une application Node.js sur Saplo

Après avoir mis en place le starter Express avec la version de Node choisie (18, 20 ou 22), connecte le dépôt Git depuis le panneau afin que les prochaines modifications du code soient automatiquement transmises au serveur à chaque push vers la branche définie.

Remplace le code du starter par ta propre application, en conservant la structure du port et les variables d’environnement requises par le moteur Saplo, afin que le reverse proxy continue d’aiguiller correctement le trafic vers ton application via le domaine associé.

Tu définis les variables d’environnement (clés d’API, chaîne de connexion à la base de données) dans le panneau de l’application, sans les conserver directement dans le dépôt de code, ce qui constitue une bonne pratique de sécurité, où que l’application soit hébergée.

Si ton application utilise une base de données, ajoute un module séparé (Postgres, MySQL ou Redis) sur le même Box, puis connecte-toi à celui-ci via l’adresse interne, sans exposer la base de données publiquement sur Internet.

Surveille les journaux de l’application via SSH (à partir de Box M) pour repérer rapidement les erreurs après chaque déploiement, avant qu’elles ne deviennent visibles pour les utilisateurs de l’application en production.

7. Node.js dans une architecture microservices sur un seul Box

Tu peux déployer plusieurs services Node.js indépendants (API, worker qui traite une file d’attente, panneau d’administration) sous forme d’applications distinctes sur le même Box, chacune dans son propre conteneur. Les services communiquent ensuite via le réseau interne ou une API publique.

Cette séparation facilite le déploiement indépendant de chaque service (un git push vers l’un des services n’oblige pas à redéployer les autres). À mesure que le projet grandit, elle est plus pratique qu’un seul gros processus Node.js monolithique qui gère tout à la fois.

Souvent ajouté comme module de base de données distinct sur le même Box, Redis sert de file de tâches ou de cache entre les microservices, sans que tu doives te connecter à un service Redis externe et payant en dehors de l’infrastructure Saplo.

Pour une architecture microservices, envisage Box L ou une version supérieure, car plusieurs processus Node.js indépendants, une base de données et Redis consomment ensemble plus de mémoire qu’une application simple.

8. Surveillance et journaux de l’application Node.js en production

Une application Node.js en production finira par rencontrer une erreur qui ne s’était pas manifestée lors des tests locaux. L’accès aux journaux du processus via SSH (à partir de Box M) est donc un outil de diagnostic essentiel pour voir ce qui s’est réellement passé au moment d’une panne ou d’un comportement inattendu.

Une bonne pratique consiste à utiliser une journalisation structurée (par exemple au format JSON, avec un niveau de gravité et un horodatage) plutôt que de simples appels console.log dispersés dans le code. Cela facilite ensuite le filtrage des journaux selon le type d’événement ou le niveau d’erreur, surtout lorsque l’application grandit et que le volume de journaux augmente.

Le redémarrage du processus après une panne (par exemple une exception non gérée qui arrête Node.js) peut être configuré via un gestionnaire de processus exécuté dans le conteneur. Une panne brève n’entraîne ainsi pas une longue interruption de service en attendant que l’équipe remarque le problème et intervienne manuellement.

Pour les applications avec de nombreuses dépendances npm, il est utile de vérifier régulièrement les failles de sécurité connues dans les packages utilisés (avec les outils d’audit npm habituels), car les dépendances obsolètes sont un vecteur d’attaque fréquent contre les applications Node.js, quelle que soit la qualité du code de l’application.

Surveiller la consommation de RAM du processus Node.js en temps réel permet de détecter les fuites de mémoire (memory leaks) avant qu’elles ne provoquent la panne de toute l’application. Pour les processus de longue durée (serveurs WebSocket, connexions prolongées), le risque est réel sans un suivi adapté. Un simple contrôle régulier de la tendance de consommation de mémoire, même sans outil de profilage avancé, permet de repérer le problème suffisamment tôt pour planifier un correctif avant qu’il ne provoque une panne en production.

Le panneau Saplo affiche la consommation actuelle des ressources du conteneur. C’est le premier point de référence pour diagnostiquer les problèmes de performances, avant de recourir à des outils de profilage plus détaillés pour l’application Node.js elle-même.

9. La communauté et l’écosystème npm comme critère de choix de la stack technologique

Node.js dispose de l’un des plus grands écosystèmes de paquets (npm) parmi les langages et plateformes populaires. La plupart des besoins courants (authentification, connexion à une base de données, gestion des fichiers) disposent donc de bibliothèques prêtes à l’emploi et éprouvées, ce qui t’évite d’écrire cette logique de zéro pour chaque nouveau projet.

Sur Saplo, tu as pleinement accès à cet écosystème, car l’application s’exécute dans un environnement Node.js standard, avec accès au registre npm, sans aucune limitation imposée par la plateforme d’hébergement. Ce type de restrictions est courant sur certaines plateformes PaaS fermées qui ne prennent en charge qu’une liste limitée de packages.

Tu peux choisir librement entre les frameworks les plus populaires avec Node.js (Express, Fastify, NestJS). Le starter fourni par Saplo (Express) est un point de départ que tu peux remplacer, pas une contrainte rigide, si ton projet exige un autre framework.

Tu peux mettre à jour l’environnement Node.js lui-même (passer à une version LTS plus récente) lors de la reconfiguration de l’application. Tu peux ainsi suivre le cycle de publication de Node.js sans migrer vers un autre fournisseur uniquement parce que la version requise de l’environnement a changé.

Pour les équipes qui suivent l’évolution de l’écosystème JavaScript (nouveaux outils de build, nouveaux schémas architecturaux), l’accès SSH complet et l’environnement Node.js standard sur Saplo n’imposent aucune contrainte supplémentaire par rapport à ce qui est possible sur un serveur classique auto-administré.

10. Tester une application Node.js avant son déploiement en production

Avant chaque déploiement en production, il vaut mieux tester la nouvelle version de l'application dans un environnement aussi proche que possible de la production, par exemple sur une application temporaire distincte sur la même Box, avant que la modification ne soit appliquée au domaine final utilisé par vos clients.

Les tests automatisés (unitaires et d'intégration), exécutés avant le déploiement, même au sein d'un simple pipeline CI au niveau du dépôt, permettent de détecter les régressions avant qu'elles n'atteignent le serveur de production via git deploy. C'est bien moins coûteux que de corriger un bug déjà visible par les utilisateurs.

Pour les applications à fort trafic en production, envisage de déployer les modifications en dehors des heures de pointe. Cela limite le nombre d'utilisateurs affectés par une éventuelle courte panne pendant le processus de mise à jour via git deploy.

Le rollback vers la version précédente fonctionnelle (retour au commit antérieur et nouveau git push) est un mécanisme de sécurité simple lorsque le nouveau déploiement pose problème. La sauvegarde de la Box (à partir de Box L) protège également la base de données de l'application en cas de problème plus grave.

11. Résumé: Node.js avec git deploy, une voie rapide vers la production

L'association d'un starter Express prêt à l'emploi, du choix de la version de Node et du déploiement automatisé par git push réduit à quelques minutes le délai entre l'idée et une application Node.js fonctionnelle et accessible publiquement, au lieu des heures de configuration manuelle du serveur, du pare-feu et du reverse proxy, nécessaires sur un VPS vierge avant que la première ligne de code ne puisse fonctionner sur une adresse de production dotée d'un certificat SSL actif. Pour un développeur qui teste une nouvelle idée, cette différence de démarrage peut être déterminante: les premières heures de travail peuvent se concentrer sur la logique applicative plutôt que sur l'infrastructure qui doit l'héberger. L'argument est encore plus convaincant lorsque plusieurs idées sont testées en parallèle, car le coût de validation de chaque nouvelle idée se limite à l'écriture du code, sans avoir à recommencer la même configuration serveur à chaque essai.