Plusieurs sites sur le même serveur

Un seul serveur peut héberger autant de sites web et d’applis web que sa RAM et son disque le permettent. La règle qui détermine si un nouveau déploiement vit à côté d’un déploiement existant ou le remplace est la même dans tous les parcours : tout dépend de l’identifiant que tu lui donnes.

La règle

L’identifiant est ce qui associe un déploiement à un emplacement précis sur le serveur :

• Site statique → l’identifiant est le domaine saisi pendant le déploiement.
• Appli web → l’identifiant est le nom de l’appli dans la section Avancé (par défaut, le nom de ton dossier, par exemple my-api).
• Base de données → l’identifiant est le nom de la DB + le moteur (chaque moteur — Postgres / MySQL / MariaDB — s’exécute dans son propre conteneur).

Sites statiques — identifiés par domaine

Chaque déploiement de site statique vit dans /var/www/<domain>/ et obtient son propre bloc Caddyfile :

mysite.example.com { root * /var/www/mysite.example.com; file_server }
api-docs.example.com { root * /var/www/api-docs.example.com; file_server }

Deux domaines différents = deux dossiers différents, deux blocs Caddyfile, tous deux servis en parallèle. Caddy gère les certificats HTTPS de chacun indépendamment.

Si tu redéploies sur le même domaine, Faro décrit dans le chat l’étape qui va remplacer l’existant :

*"Attention : /var/www/mysite.example.com/ contient déjà un déploiement précédent. Contenu actuel : index.html, about.html, assets/. Tout ce dossier sera remplacé par tes N fichiers envoyés. Si tu as un répertoire d’exécution (uploads/, data/, etc.) à conserver, annule maintenant, ajoute un fichier vide .helm-keep dedans via l’onglet Fichiers, puis relance le déploiement."*

Le marqueur .helm-keep est la porte de sortie — voir [Conserver un dossier entre deux redéploiements](#preserve-a-folder-across-redeploys) plus bas.

Applis web — identifiées par nom d’appli

Chaque déploiement d’appli web vit dans /opt/<appName>/ et s’exécute comme sa propre unité systemd :

/opt/my-api/      → my-api.service      (Node, port 3000)
/opt/scraper/     → scraper.service     (Python, port 5000)
/opt/notifier/    → notifier.service    (Go, port 8080)

Trois noms d’appli différents = trois services indépendants. Chacun a son propre port interne, son propre utilisateur, ses propres journaux. Caddy sert de reverse proxy entre un domaine et chacun d’eux. Coût en ressources : faible (Node et Python consomment environ 50 à 200 Mo RSS selon l’appli).

Si tu redéploies avec le même nom d’appli, le dossier existant /opt/<app>/ est remplacé et le service redémarre avec le nouveau code. Le même mécanisme .helm-keep s’applique.

L’emplacement « sans domaine » est unique

Si tu déploies un site statique ou une appli web sans domaine, il va dans un emplacement spécial « par défaut » :

• Statique : /var/www/default/
• Appli web : les mêmes règles /opt/<appName>/ s’appliquent (tu choisis quand même un nom d’appli)

Pour les sites statiques, il n’existe qu’un seul emplacement par défaut. Un deuxième déploiement statique sans domaine remplace le premier, parce que l’identifiant de l’emplacement est la chaîne littérale default. Si tu veux deux sites statiques accessibles uniquement par IP, tu dois donner un vrai (sous-)domaine à au moins l’un des deux.

Pour les applis web, l’identifiant basé sur le nom d’appli continue de les distinguer : les applis web accessibles uniquement par IP peuvent très bien coexister tant qu’elles ont des noms différents, parce que le port sous-jacent est interne et que Caddy se charge d’associer :80 à l’une d’elles. (En pratique, une seule appli web sans domaine peut être la cible Caddy « par défaut » sur le port 80 à un moment donné. Faro comprend la situation et te l’explique.)

Conserver un dossier entre deux redéploiements

Quand tu redéploies avec le même identifiant, le comportement par défaut est de tout effacer puis de remplacer. Pour conserver un sous-répertoire précis (cas typiques : données envoyées par les utilisateurs dans uploads/, caches d’exécution dans data/), place un fichier vide nommé **.helm-keep** dedans avant le prochain redéploiement :

1. Ouvre le panneau du service du site → onglet Fichiers.
2. Va dans le sous-répertoire que tu veux conserver (par exemple uploads/).
3. Clique sur + Nouveau fichier dans la barre d’outils, saisis .helm-keep, puis appuie sur Entrée.
4. Redéploie comme d’habitude — Faro détecte le marqueur, met ce sous-répertoire de côté avant l’effacement, puis le restaure une fois les nouveaux fichiers en place.

Si tu préfères le faire en dehors du panneau, ces méthodes fonctionnent aussi : glisser-déposer un .helm-keep vide depuis ton ordinateur dans le sous-dossier, l’envoyer via SFTP (FileZilla, Cyberduck), te connecter en SSH et exécuter sudo touch /var/www/<domain>/<subdir>/.helm-keep, ou simplement demander à Faro dans le chat (*"create an empty .helm-keep in /var/www/mysite.example.com/uploads/"*).

Faro l’annonce dans le chat avant l’étape destructive, en listant les répertoires conservés pour que tu puisses confirmer :

*"Conservation de ces éléments, car ils contiennent un marqueur .helm-keep : uploads/, data/. Tout le reste sera remplacé par tes N fichiers envoyés."*

Si le nouvel envoi contenait aussi un répertoire uploads/, la version conservée côté serveur l’emporte — Faro t’indique ensuite que le uploads/ de ton envoi a été ignoré. Pour forcer la version envoyée à l’emporter à la place, supprime le marqueur .helm-keep et redéploie.

Limites de ressources

Il n’y a pas de limite fixe au nombre de sites que tu peux exécuter : tout dépend de la RAM et du disque. Quelques ordres de grandeur sur un petit serveur (2 Go de RAM) :

• Les sites statiques ne coûtent presque rien — des fichiers sur disque + un bloc Caddy. Tu peux facilement en faire tourner 50 ou plus. La contrainte principale est le disque, et chacun est généralement minuscule (≤ 100 Mo).
• Les applis web natives coûtent environ 50 à 200 Mo RSS chacune, selon le langage et ce qu’elles font. Un serveur de 2 Go en fait tourner confortablement 5 à 8 à côté de Caddy + une base de données.
• Les applis web en conteneur ajoutent environ 30 à 100 Mo par conteneur en plus du coût du runtime : elles verrouillent les versions du runtime, mais consomment plus de RAM. Voir [Natif ou conteneur](#) pour comparer.
• Les bases de données sont les plus lourdes : Postgres ou MySQL au repos prend environ 100 à 300 Mo ; sous charge, le buffer pool peut monter jusqu’à une limite configurable.

L’onglet État du panneau de chaque service affiche la mémoire et le CPU actuels ; le panneau Serveur affichera (dans une prochaine version) le total cumulé de tout ce qui tourne sur la machine.