Dimensionner le serveur

Cenaclo est conçu pour tenir sur un VPS d’entrée de gamme, pas sur une infrastructure dédiée. Cette page donne le gabarit de départ, ce qui consomme réellement des ressources, et comment dimensionner le disque en fonction de votre usage.

Gabarit de départ

Ressource	Recommandation
Processeur	2 vCPU
Mémoire	4 Go
Système	Debian 12 ou plus récent, Ubuntu 22.04 ou plus récent
Docker	Docker Engine avec le plugin Compose v2
Budget indicatif	5 à 10 € par mois chez un hébergeur généraliste

Les cibles testées sont les VPS d’entrée de gamme de Hetzner, OVH, Infomaniak et Scaleway. Toute distribution Linux disposant de Docker convient : le seul prérequis réel est un hôte Docker, pas un fournisseur particulier.

Un hébergement mutualisé sans Docker ne convient pas

Cenaclo se déploie exclusivement sous forme de conteneurs. Un hébergement mutualisé qui ne permet pas d’exécuter Docker ne peut pas faire tourner l’application, quelle que soit la formule souscrite. Il vous faut un VPS ou une machine virtuelle sur laquelle vous êtes administrateur.

Processeur et mémoire

L’empreinte de base est volontairement faible : le backend Node avec Fastify, Drizzle et le stockage objet embarqué tient autour de 250 Mo de mémoire au repos. Sur un gabarit 2 vCPU / 4 Go, ce sont les usages ponctuels qui dimensionnent la machine, pas le service au repos.

Trois postes consomment davantage.

• Le temps réel. Le dimensionnement de référence retenu par l’architecture vise un millier de connexions simultanées sur 2 vCPU. Cette cible s’appuie sur des mesures publiques de serveurs temps réel comparables, pas sur une mesure faite sur votre instance : traitez-la comme un ordre de grandeur et surveillez la charge réelle de votre communauté.
• Le replay vidéo. Le service livekit-egress compose les enregistrements en lançant un navigateur Chromium dans son conteneur. Une captation en cours est le pic de charge le plus marqué d’une instance Cenaclo. Si vous prévoyez d’enregistrer régulièrement vos directs, montez d’un cran en processeur et en mémoire.
• Le PaaS lui-même. Avec le parcours Coolify, Coolify tourne sur la même machine que Cenaclo. Additionnez son empreinte à celle de la stack : c’est la principale raison de ne pas descendre sous 4 Go de mémoire.

Le parcours Docker Compose est un peu plus économe puisqu’il n’embarque pas de PaaS, mais il vous laisse la charge du proxy, des mises à jour et des tâches planifiées.

Stockage

Le disque doit absorber quatre postes distincts.

1. Les images Docker. La stack tire une dizaine d’images. Celle du service de replay embarque un navigateur complet et reste la plus volumineuse. Comptez plusieurs gigaoctets avant même le premier message.
2. La base de données. Postgres porte les messages, les métadonnées et le journal d’audit. Sa croissance suit l’activité écrite de la communauté.
3. Le stockage objet. SeaweedFS porte les pièces jointes et les replays vidéo. C’est le poste qui croît le plus vite. Le quota par communauté est fixé par STORAGE_DEFAULT_QUOTA_BYTES, à 1 Gio par défaut : ajustez-le en connaissance de votre disque.
4. Les sauvegardes locales. Par défaut, l’archive chiffrée est écrite dans un volume de l’hôte. En mode archive complète, le script copie l’intégralité des objets localement avant de chiffrer : il faut donc de la place pour une copie supplémentaire du stockage objet, en plus de l’archive elle-même.

Quand les replays deviennent le poste dominant

Pour une communauté active, les replays vidéo peuvent dépasser 10 Go. À partir de ce volume, la sauvegarde complète quotidienne devient coûteuse en disque et en temps. Le mode recommandé est alors :

• une sauvegarde applicative quotidienne allégée, sans les objets, qui conserve la base et la configuration ;
• une synchronisation périodique des objets vers un stockage S3 externe dédié.

La procédure exacte, les commandes et les précautions de rétention sont détaillées dans Sauvegardes self-hosting.

Réseau

• Un domaine, avec un enregistrement DNS par service exposé publiquement.
• Les ports HTTP et HTTPS ouverts sur l’hôte, pour le proxy retenu.
• Les ports média LiveKit ouverts si vous hébergez le live vous-même. Le détail des ports, y compris la plage UDP du profil Coturn, est dans Firewall self-hosting.

Le trafic sortant compte aussi : un direct avec plusieurs participants consomme de la bande passante montante en continu. Vérifiez la politique de trafic de votre hébergeur avant d’ouvrir le live à toute la communauté.

Deux stacks sur le même serveur

C’est possible, mais les collisions ne sont pas les mêmes d’un parcours à l’autre, et elles ne se limitent pas aux ports.

Parcours Coolify

Les ports média LiveKit sont publiés sur l’hôte avec des valeurs fixes, 7881 en TCP et 7882 en UDP. Deux ressources ne peuvent pas les partager : donnez à la seconde une autre paire via LIVEKIT_RTC_TCP_PORT et LIVEKIT_RTC_UDP_PORT, puis ouvrez les nouveaux ports sur le firewall.

Parcours Docker Compose

Le fichier livré ne publie aucun port média sur l’hôte : ce n’est donc pas là que deux stacks se gênent. Le vrai risque est le partage silencieux des données, car le nom du projet, le réseau et les onze volumes portent des noms fixes, sans préfixe d’instance. Deux stacks lancées depuis le même fichier écriraient dans le même volume Postgres. Pour la seconde stack, changez donc :

• le nom de projet, avec -p ou COMPOSE_PROJECT_NAME ;
• le réseau, avec INTERNAL_NETWORK_NAME ;
• chaque volume, avec sa variable *_VOLUME_NAME, par exemple POSTGRES_VOLUME_NAME, REDIS_VOLUME_NAME et SEAWEEDFS_VOLUME_NAME ;
• les ports publiés si vous activez le profil caddy, avec CADDY_HTTP_PORT et CADDY_HTTPS_PORT.

Les ressources

Deux stacks complètes sur 2 vCPU / 4 Go se marchent dessus dès qu’un replay démarre. Prévoyez un gabarit supérieur ou séparez les machines.

Avant de mettre en production

• Vérifiez que la passphrase de chiffrement saisie au wizard est stockée hors du serveur. Elle n’est jamais sauvegardée par l’application.
• Vérifiez que les archives de sauvegarde partent hors du serveur : une sauvegarde qui reste sur la machine qu’elle protège ne protège de rien.
• Testez une restauration sur un hôte neuf avant d’en avoir besoin, en suivant Restaurer une instance.