Héberger plusieurs applications React sur un même VPS

#Donner une frontière à chaque application

Attribuez à chaque application un répertoire de release, un processus supervisé, un port local et ses propres variables d’environnement. Un reverse proxy commun choisit la destination d’après le domaine. Un redémarrage doit viser un service identifiable sans toucher aux autres.

Pour des projets de clients différents, examinez aussi les comptes de service et les permissions. Des processus lancés sous le même compte peuvent accéder aux fichiers que ce compte lit. Un port distinct ne crée pas une isolation de sécurité. Des conteneurs ou des machines séparées peuvent être nécessaires selon le niveau de séparation attendu.

#Prévoir les domaines et les ports locaux

Ce tableau illustre un placement possible. Les noms example.com sont des exemples à remplacer. Les ports locaux ne sont pas des URL publiques : seul le proxy reçoit les requêtes du navigateur.

Chaque domaine a besoin d’un certificat valide et d’une configuration adaptée. Vérifiez les liens absolus, les callbacks d’authentification et les cookies du domaine concerné. Si plusieurs applications partagent un domaine et des chemins, leurs préfixes et assets demandent une configuration supplémentaire. Des sous-domaines évitent souvent ce couplage.

#Budgéter les pointes qui peuvent arriver ensemble

Relevez pour chaque service le repos, la charge courante et une pointe représentative. Ajoutez les services communs, le système et la marge de déploiement. Une base partagée doit être comptée une fois dans le budget global, avec sa propre pointe.

Rejouez ensuite un pic sur deux applications simultanément. Un test isolé peut ignorer la compétition sur le CPU, le disque et les connexions à la base. Pour une équipe qui lance des démonstrations pendant les heures de travail, les périodes d’activité peuvent justement coïncider.

Construire un budget mémoire à partir de vos mesures

#Encadrer les ressources avec des limites explicites

Sur un système utilisant les contrôleurs nécessaires, systemd permet de suivre et limiter un groupe de processus. Dans un drop-in dédié au service testé, MemoryHigh introduit une pression de récupération, tandis que MemoryMax constitue une borne dure pouvant mener à un arrêt. CPUQuota exprime un plafond de temps CPU.

Le fragment ci-dessous illustre la syntaxe. Les valeurs sont à remplacer après mesure et ne sont pas un dimensionnement Next.js recommandé. Une application qui atteint sa limite peut ralentir ou échouer ; observez la latence, les événements mémoire et les journaux. La limite doit couvrir les enfants du processus, pas seulement le parent.

[Service]
MemoryAccounting=yes
MemoryHigh=512M
MemoryMax=768M
CPUQuota=100%

#Éviter que les builds saturent les voisins

Planifiez les builds et leur nettoyage séparément des processus actifs. Si possible, compilez en CI dans un environnement compatible et transférez un artefact vérifié. Sinon, mesurez le build dans le budget partagé et évitez plusieurs compilations lourdes simultanées.

Utilisez une release par répertoire et un contrôle avant la bascule. Les anciennes connexions et les assets d’onglets déjà ouverts demandent une attention particulière. La sauvegarde de la base reste distincte de l’archive applicative ; vérifiez régulièrement une restauration sur des données de test.

#Étudier la veille pour les projets intermittents

PRNext peut libérer la mémoire de workers inactifs, avec un coût au réveil. Cela peut être utile si les périodes creuses sont longues et que les premières visites acceptent ce délai. Une sonde fréquente ou des requêtes en arrière-plan peuvent modifier ce comportement.

Avant de regrouper davantage de projets, testez aussi leurs réveils simultanés. La sonde mémoire publiée par PRNext concerne une petite application ; elle ne donne pas une capacité garantie en nombre de sites. Les bases, le proxy, le système et les caches conservent leurs besoins.

Comprendre les réglages et les limites du mode sleep

Vérifier le déploiement public de chaque application