Héberger Matrix Synapse sur un VPS : guide pratique

Ce qu’il faut pour maintenir un homeserver Matrix Synapse en service

Matrix Synapse est facile à installer et facile à délaisser. L’installation consiste à ajouter un dépôt apt, à créer un fichier de configuration, à définir un bloc de reverse proxy et à ajouter un enregistrement DNS. Maintenir le homeserver en bon état pendant un an demande un autre travail : une véritable base de données, un media store nettoyé régulièrement, une inscription que des inconnus ne peuvent pas utiliser et une sauvegarde qui couvre les deux parties du serveur.

Ce guide cible Ubuntu 24.04 LTS et installe Synapse depuis le dépôt apt de matrix.org. Il s’agit de la source des paquets maintenue par le projet Synapse pour Debian et Ubuntu. Les versions des paquets évoluent toutes les quelques semaines. Aucun numéro de version n’est donc indiqué ici. Tous les chemins et toutes les options ci-dessous proviennent de la documentation actuelle de Synapse.

Dimensionnement : ce que vous apportent réellement 1 vCPU et 2 GB de RAM

Les pages de dimensionnement publiées, en août 2026, recommandent généralement 1 vCPU et 2 GB de RAM pour un homeserver Synapse. C’est adapté à un cas précis : un serveur privé, quelques utilisateurs, de petites salles et aucune salle publique très active. La documentation de Synapse est claire pour l’autre cas. Elle demande « At least 1GB of free RAM if you want to join large public rooms like #matrix:matrix.org ». Il s’agit de RAM libre, en plus de celle utilisée par Python, Postgres et le kernel.

Une seule salle peut modifier le dimensionnement, en raison du fonctionnement des adhésions. Lorsqu’un utilisateur local rejoint une salle, votre homeserver devient un participant à part entière de cette salle. Il reçoit chaque événement provenant de tous les autres serveurs qui y participent, vérifie la signature de chacun et stocke localement l’état de la salle. Une grande salle publique compte des milliers de membres répartis sur des centaines de serveurs. Votre serveur effectue donc ce travail en continu, même si votre utilisateur ne rouvre jamais la salle. Quitter la salle plus tard ne supprime pas l’historique déjà stocké.

La majeure partie de la RAM de Synapse est utilisée par les caches. La section caches contient un global_factor qui redimensionne tous les caches en même temps, et la variable d’environnement SYNAPSE_CACHE_FACTOR définit le même paramètre. Augmenter cette valeur utilise davantage de RAM pour éviter les requêtes vers la base de données. La réduire utilise davantage de CPU et de temps Postgres afin d’économiser de la RAM. Postgres a aussi besoin de sa propre mémoire. Sur un serveur doté de 2 GB, les deux se disputent donc les mêmes mégaoctets.

Deux règles pratiques pour une petite offre. Ajoutez du swap : le swap ne rendra pas Synapse plus rapide, mais il évite que le kernel tue le processus pendant une adhésion importante. Surveillez ensuite le disque dès la première semaine. Les deux éléments qui augmentent sans limite sont le media store et les tables d’état des salles, et tous deux sont stockés sur le disque.

Pourquoi Postgres, et pourquoi SQLite cesse d’être une option

Le paquet Debian démarre avec SQLite. C’est acceptable pour un premier démarrage, mais pas pour un serveur utilisé par d’autres personnes. SQLite n’autorise qu’un seul processus d’écriture à la fois. Le trafic de fédération et les requêtes des clients écrivent au même moment. Une requête légère attend alors derrière une requête lente. Le symptôme signalé par les utilisateurs est que l’application se bloque aléatoirement pendant quelques secondes.

La deuxième raison est structurelle. Les processus worker de Synapse sont la méthode prise en charge pour utiliser plusieurs cœurs de processeur, et les workers nécessitent Postgres. Rester sur SQLite empêche donc aussi bien d’améliorer les performances que de suivre la voie de mise à niveau.

La migration ultérieure est prise en charge, mais elle entraîne une interruption de service. Effectuez-la avant d’avoir des utilisateurs. Synapse fournit synapse_port_db, qui copie une base SQLite dans une base Postgres préparée :

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

Si vous préférez exécuter la base de données dans un conteneur à côté de Synapse, consultez les compromis présentés dans exécuter votre base de données dans Docker ou sur l’hôte.

Installer Synapse sur Ubuntu 24.04

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

Sur Ubuntu 24.04, lsb_release -cs affiche noble et le dépôt matrix.org publie une suite noble. N’utilisez pas le paquet matrix-synapse des dépôts Ubuntu. Le projet Synapse le déconseille, car ces builds sont en retard sur ses versions et contiennent des failles de sécurité connues.

L’installateur demande un nom de serveur et écrit la réponse dans /etc/matrix-synapse/conf.d/server_name.yaml. Répondez avec attention. server_name est la partie située après les deux-points dans chaque identifiant utilisateur (@alice:example.com) et elle est intégrée à chaque salon créé par votre serveur. La modifier ultérieurement ne déplace rien : elle produit un homeserver différent. Utilisez votre domaine nu, example.com, même lorsque Synapse s’exécute lui-même sur matrix.example.com. La délégation relie les deux, et c’est l’objet de la section suivante.

Le paquet exécute Synapse avec l’utilisateur matrix-synapse, conserve ses données sous /var/lib/matrix-synapse et lit /etc/matrix-synapse/homeserver.yaml, puis chaque fichier de /etc/matrix-synapse/conf.d/. Placez vos propres paramètres dans de petits fichiers sous conf.d. Les mises à niveau du paquet ne les modifient pas.

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

Un démarrage normal active les listeners, puis le service reste silencieux. L’unité systemd redémarre le service quelques secondes après chaque arrêt. Une configuration rejetée par Synapse se manifeste donc par une unité qui démarre puis s’arrête en boucle. Les dernières lignes du journal indiquent la clé refusée.

Pointer Synapse vers Postgres

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

La locale n’est pas un détail esthétique. Synapse refuse de démarrer avec une base de données créée avec des valeurs COLLATE et CTYPE différentes, sauf si vous définissez allow_unsafe_locale dans la configuration de la base de données. La procédure de réparation documentée consiste ensuite à effectuer un dump, puis à recharger les données dans une base de données correctement créée. Configurez-la correctement dès le départ.

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

Conservez exactement une clé database: dans l’ensemble de vos fichiers de configuration. Remplacez le bloc SQLite dans homeserver.yaml au lieu d’ajouter une deuxième copie sous conf.d. Vous éviterez ainsi toute ambiguïté sur la configuration active. Redémarrez ensuite Synapse, puis vérifiez qu’il utilise bien Postgres :

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

Un nombre indique que Synapse a créé son schéma dans cette base de données. Une erreur indiquant qu’une relation est introuvable signifie qu’il écrit encore dans le fichier SQLite. Le fichier de configuration que vous avez modifié n’est donc pas celui qui est chargé.

Reverse proxy, TLS et fichiers .well-known nécessaires à la fédération

Synapse écoute en HTTP simple sur le port 8008, lié à localhost. Le TLS et le port public sont gérés par un reverse proxy placé devant lui.

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

x_forwarded: true indique à Synapse de faire confiance à l’en-tête X-Forwarded-For défini par le proxy. Sans cet en-tête, chaque client semble provenir de 127.0.0.1. La limitation de débit voit alors un seul utilisateur local extrêmement actif et applique la limite à tout le monde.

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

La documentation de Synapse contient un avertissement concernant ce bloc, qui a déjà fait perdre plusieurs jours à de nombreuses personnes. N’ajoutez aucun chemin après le port dans proxy_pass, pas même un seul /. nginx canonicalise alors l’URI. Cela modifie les octets signés par le serveur émetteur. Les requêtes de fédération échouent donc lors de la vérification de la signature, tandis que les requêtes client ordinaires continuent de fonctionner.

client_max_body_size doit être au moins égal à la valeur de max_upload_size de Synapse. Si nginx utilise une valeur plus petite, les téléversements qui la dépassent sont rejetés par nginx avec 413 Request Entity Too Large avant que Synapse ne les reçoive. Aucun message dans les journaux de Synapse ne permet alors d’expliquer l’échec.

Pour le certificat, suivez Certbot et Let's Encrypt sur Ubuntu 24.04. Si vous n’avez pas encore choisi le proxy, la comparaison des reverse proxies indique lequel peut gérer le TLS pour vous.

La délégation permet à server_name de rester example.com pendant que Synapse s’exécute sur matrix.example.com. Servez deux fichiers depuis le domaine racine :

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

Le fichier serveur indique aux autres homeservers où envoyer le trafic de fédération. La fédération peut ainsi utiliser 443 au lieu du port par défaut 8448. Le fichier client indique aux clients Matrix quelle URL fournit @alice:example.com. L’en-tête Access-Control-Allow-Origin est important pour le fichier client, car les clients exécutés dans un navigateur le récupèrent cross-origin. Sans cet en-tête, le navigateur bloque la réponse et le client indique qu’il ne trouve pas votre homeserver.

Les deux fichiers doivent être servis via un TLS valide depuis example.com lui-même. Vérifiez-les, puis vérifiez ce que voit le réseau extérieur :

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

La première commande renvoie le JSON que vous avez écrit. La seconde renvoie un objet JSON qui contient le nom de l’implémentation du serveur et sa version. Cela prouve que le proxy atteint Synapse sur le chemin de fédération. Exécutez ensuite un test du domaine avec le testeur de fédération Matrix à l’adresse https://federationtester.matrix.org. Il suit le même chemin qu’un véritable serveur distant.

Fédérer ou ne pas fédérer : décidez-le volontairement

La fédération est au cœur de Matrix, mais elle représente aussi l’essentiel de son coût. Un homeserver qui fédère accepte des connexions de serveurs que vous ne connaissez pas, reçoit leurs événements, met leurs médias en cache et stocke l’état de chaque salon auquel vos utilisateurs accèdent. Il s’agit d’une décision liée au modèle de menace, pas d’un comportement par défaut.

Activez la fédération lorsque vos utilisateurs doivent pouvoir contacter des personnes sur d’autres homeservers, ou lorsque l’identité portable justifie le choix de Matrix. N’activez pas la fédération lorsque le serveur est destiné à une seule équipe et que tous les comptes vous appartiennent. Un serveur fermé stocke moins de données, en reçoit moins et présente beaucoup moins d’intérêt pour les abus.

Pour restreindre la fédération sans la désactiver, Synapse utilise une allow list :

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

La documentation recommande également de filtrer le listener de fédération avec le firewall, afin que le trafic indésirable soit bloqué au niveau du réseau plutôt qu’à l’intérieur de Python. Pour désactiver complètement la fédération, supprimez federation de la liste resources du listener, ne publiez pas /.well-known/matrix/server et laissez le port 8448 fermé.

Si vous exécutez Matrix pour fournir une messagerie privée à une équipe et que la fédération n’en a jamais fait partie, comparez le coût d’exploitation aux autres alternatives auto-hébergées à Slack avant de choisir Synapse. Rocket.Chat avec Docker Compose fournit une messagerie d’équipe sur une machine moins puissante, car il n’a jamais besoin de stocker l’état des salons d’une autre organisation.

Le dépôt de médias remplit discrètement le disque

Les fichiers téléversés par vos propres utilisateurs restent définitivement sur votre disque. Les fichiers publiés par des utilisateurs sur d’autres homeservers sont téléchargés et mis en cache sur votre disque dès qu’un de vos clients les affiche. Synapse génère également des miniatures pour les images : une seule photo devient donc plusieurs fichiers. Par défaut, rien n’expire.

Trouvez le store et mesurez sa taille :

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

Mesurez le chemin affiché par votre propre configuration. Le paquet Debian conserve les données de Synapse sous /var/lib/matrix-synapse ; le store s’y trouve donc généralement. Définissez ensuite une politique de rétention dans conf.d :

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Lisez attentivement ces deux lignes, car elles ne définissent pas le même type de paramètre. remote_media_lifetime expire un cache. Les éléments supprimés peuvent être téléchargés de nouveau depuis le serveur qui possède le fichier. local_media_lifetime supprime définitivement les téléversements de vos propres utilisateurs lorsqu’ils atteignent cet âge. Une équipe qui partage des documents dans le chat et s’attend à les retrouver l’année prochaine les perdra. De nombreux serveurs définissent uniquement la valeur distante.

Pour effectuer un nettoyage ponctuel, l’API d’administration attend un timestamp Unix en millisecondes :

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache supprime les médias distants mis en cache et consultés pour la dernière fois avant ce timestamp. POST /_synapse/admin/v1/media/delete?before_ts=<ms> supprime les médias locaux selon la même règle. Lancez d’abord la purge distante, puis mesurez de nouveau, car sur un serveur fédéré, le cache distant représente généralement la plus grande part.

Deux paramètres consomment le même espace disque. max_upload_size limite la taille d’un téléversement individuel et doit rester cohérent avec client_max_body_size dans nginx. url_preview_enabled: true oblige votre serveur à récupérer les pages distantes afin que les clients puissent afficher des aperçus de liens. Cela consomme de la bande passante et stocke des miniatures de contenus que vous n’avez pas téléversés.

Fermez les inscriptions avant que quelqu’un ne trouve votre homeserver

Les scanners détectent un homeserver ouvert en quelques jours. Dès que la création de comptes est libre, votre serveur devient une source de spam dans chaque salon avec lequel il fédère, et les administrateurs en face bloquent tout votre domaine. Cette atteinte à la réputation perdure après le nettoyage, car les listes de blocage sont gérées manuellement.

Synapse est livré avec les inscriptions fermées. enable_registration vaut par défaut false et registration_requires_token vaut par défaut false. Synapse refuse également de démarrer lorsque les inscriptions sont activées sans étape de vérification, sauf si vous définissez en plus enable_registration_without_verification: true. Ce refus est volontaire. Ne l’activez donc pas simplement pour faire disparaître une erreur au démarrage.

Créez manuellement les comptes souhaités :

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

L’outil vous demande le nom d’utilisateur, le mot de passe et si le compte est un administrateur du serveur. Il lit registration_shared_secret dans la configuration que vous lui indiquez avec -c. S’il signale qu’il ne trouve pas de secret partagé, indiquez avec -c le fichier qui le contient.

Lorsque la création manuelle des comptes ne suffit plus, les registration tokens constituent une solution intermédiaire. Un token est une chaîne qu’un nouvel utilisateur doit fournir lors de son inscription. Chaque token peut aussi définir un nombre maximal d’utilisations :

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

Si vous omettez token du corps de la requête, Synapse en génère un et le renvoie. GET /_synapse/admin/v1/registration_tokens répertorie les tokens actifs. Les deux appels nécessitent l’access token d’un compte administrateur du serveur. Vous l’obtenez en vous connectant avec le compte administrateur créé précédemment.

Une organisation qui gère déjà les comptes ailleurs peut supprimer entièrement les mots de passe locaux, car Synapse peut déléguer l’authentification à un fournisseur OIDC (OpenID Connect), par exemple Authentik comme fournisseur SSO auto-hébergé. Les arrivées et les départs sont alors gérés au même endroit.

Une sauvegarde qui peut réellement reconstruire le serveur

Une sauvegarde de Synapse comporte trois éléments. Si l’un d’eux manque, la restauration produit un serveur inutilisable.

• La base de données Postgres, qui contient chaque événement, chaque compte et chaque salon.
• Le répertoire du media store, qui contient tous les fichiers téléversés.
• /etc/matrix-synapse, qui contient votre configuration et la clé de signature du serveur.

La clé de signature est l’élément le plus souvent oublié. Il s’agit de la clé privée avec laquelle votre homeserver signe les événements. Les serveurs distants vérifient ensuite ces événements avec la clé publique correspondante. Exécutez grep signing_key_path /etc/matrix-synapse/homeserver.yaml pour voir où se trouve la vôtre. Si vous la perdez, vous restaurez un serveur qui ne peut pas prouver qu’il s’agit du même serveur que celui déjà connu par vos salons.

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

Effectuez d’abord le dump de la base de données, puis copiez le media store. Les fichiers multimédias sont écrits une seule fois et référencés par leur ID. Une copie du media store réalisée après le dump peut donc contenir uniquement des fichiers supplémentaires, jamais des fichiers manquants. Dans l’ordre inverse, la base de données restaurée peut pointer vers un fichier que votre sauvegarde n’a jamais capturé.

Transférez les trois éléments hors du VPS. restic avec des snapshots hors site convient bien à ce scénario, car le media store constitue la partie la plus volumineuse et change très peu entre deux exécutions. La déduplication permet donc de conserver des snapshots de petite taille.

Répétez ensuite la restauration, car une sauvegarde que vous n’avez jamais restaurée ne constitue qu’une hypothèse. Préparez un second VPS, installez le même package, restaurez la configuration, créez la base de données avec le même encodage et la même locale, pg_restore le dump dans celle-ci, recopiez le media store, puis connectez-vous. Notez la durée de l’opération. Cette durée correspond à votre véritable temps de reprise.

Lorsque les tables d’état grossissent : compaction

Synapse stocke l’état des salons sous forme de groupes d’état. Sur un serveur fédéré, state_groups_state devient souvent le plus gros objet de la base de données. Mesurez avant toute modification :

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

Si cette table représente la majeure partie de votre base de données, le projet fournit un compresseur dédié, rust-synapse-compress-state. Celui-ci réécrit la hiérarchie des groupes d’état pour utiliser moins de lignes, sans modifier la signification de l’état des salons. Il est compilé avec Rust :

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c indique le nombre de groupes d’état traités simultanément, et -n le nombre de lots traités par cette exécution. Le compresseur automatique enregistre sa progression. L’exécution suivante reprend donc au même point, ce qui permet de la planifier sans risque. Sa documentation précise que les modifications sont appliquées dans des transactions sur des tables en ajout seulement. Il peut donc fonctionner pendant que Synapse est actif. Faites malgré tout une sauvegarde de la base de données avant la première exécution.

Un détail de Postgres surprend souvent dans ce cas. La suppression de lignes rend l’espace disponible pour une réutilisation par Postgres, mais pas par le système de fichiers. df peut donc ne pas diminuer après une compaction importante. VACUUM FULL restitue cet espace au système de fichiers. Cette opération prend un verrou exclusif sur la table et nécessite un espace disque libre à peu près égal à la taille de la table. Planifiez-la donc pendant une maintenance plutôt que de la lancer sans préparation.

Vérifications indiquant que le serveur est sain

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

Un serveur est sain si l’unité est active et ne redémarre pas en boucle, si le fichier de délégation renvoie votre valeur m.server, si le endpoint de version de la fédération renvoie du JSON et si les deux valeurs de taille peuvent être comparées à celles du mois dernier. Les tailles sont la vérification souvent oubliée. Un disque saturé peut arrêter un serveur Synapse sans avertissement : un volume plein empêche Postgres d’écrire, puis Synapse échoue pour chaque requête qui accède à la base de données.

FAQ

De combien de RAM un serveur Matrix Synapse a-t-il besoin ?

Pour un homeserver privé avec quelques utilisateurs, de petits salons et aucun grand salon public, 2 GB sont généralement suffisants. C’est aussi la recommandation de la plupart des pages de dimensionnement publiées en août 2026. La documentation de Synapse demande au moins 1 GB de RAM libre supplémentaire si vos utilisateurs rejoignent de grands salons publics comme #matrix:matrix.org, car votre serveur stocke alors l’état de ce salon et traite son trafic en continu. Ajoutez du swap avec une offre de 2 GB afin qu’une seule grosse opération de synchronisation ne fasse pas tuer le processus par le kernel.

Dois-je utiliser PostgreSQL au lieu de SQLite ?

Au-delà de quelques utilisateurs, oui. SQLite n’autorise qu’un seul writer à la fois. Le trafic de federation et les requêtes des clients se bloquent donc mutuellement sous charge, et les requêtes restent parfois suspendues plusieurs secondes. Les processus worker de Synapse, qui constituent la méthode prise en charge pour utiliser plusieurs cœurs CPU, nécessitent Postgres. Une migration ultérieure est possible avec synapse_port_db, mais elle impose une interruption de service. Créez donc la base de données avec --encoding=UTF8 --locale=C --template=template0 avant d’avoir des utilisateurs.

Pourquoi l’utilisation de l’espace disque de Synapse continue-t-elle d’augmenter ?

Deux éléments sont concernés : un répertoire et une table. Le media store conserve chaque fichier envoyé dans les salons auxquels votre serveur participe, y compris les copies en cache des médias d’utilisateurs distants et les miniatures générées. Rien n’expire tant que vous n’avez pas défini media_retention. La table state_groups_state augmente avec l’état des salons sur un serveur qui participe à la federation, et rust-synapse-compress-state permet de la réduire. Mesurez les deux éléments avec du -sh sur votre media_store_path et avec SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); avant de décider lequel traiter.

Comment empêcher des inconnus de s’inscrire sur mon homeserver ?

Laissez enable_registration avec sa valeur par défaut, false, et créez les comptes avec register_new_matrix_user. Lorsque cette méthode ne suffit plus, définissez enable_registration: true avec registration_requires_token: true, puis distribuez les tokens créés avec POST /_synapse/admin/v1/registration_tokens/new. Ne définissez pas enable_registration_without_verification: true uniquement pour supprimer le refus de démarrage de Synapse : un homeserver ouvert devient une source de spam, et les autres administrateurs finissent par bloquer tout votre domaine.

Mon homeserver doit-il participer à la federation ?

La federation est un choix d’exposition, pas un réglage par défaut. Activez-la si vos utilisateurs doivent joindre des personnes sur d’autres homeservers. Désactivez-la si le serveur ne sert qu’une seule équipe, car un serveur qui ne participe pas à la federation stocke moins de données, reçoit moins de trafic et attire beaucoup moins d’abus. Entre ces deux options, federation_domain_whitelist limite la federation aux domaines partenaires nommés. La documentation de Synapse recommande également de filtrer le federation listener avec le firewall, au lieu de compter uniquement sur ce contrôle au niveau applicatif.