Auto-héberger Matrix sur un VPS.
Synapse + Element. Fédéré. Chiffré de bout en bout.
Matrix, c'est ce à quoi l'e-mail ressemblerait s'il avait été conçu pour le chat à l'ère des protocoles ouverts. Synapse comme homeserver, Element comme client, PostgreSQL comme stockage, Caddy comme porte d'entrée — et un graphe de salons fédérés qu'aucune entité en particulier ne possède.
- 01
Synapse est le homeserver par défaut en 2026 — l'implémentation de référence validée en production, avec toutes les fonctionnalités. Conduit et Dendrite sont valides pour des cas d'usage plus restreints.
- 02
Passez à PostgreSQL dès le premier jour ; le SQLite par défaut est pour les tests uniquement et s'effondre au-delà d'une poignée d'utilisateurs. Prévoyez de l'espace disque pour les téléchargements médias — les salons fédérés les accumulent rapidement.
- 03
L'inscription fermée est la valeur par défaut sûre. L'inscription publique est un vrai travail de modération ; ne l'activez que si vous êtes prêt à vous en charger.
Matrix en cinq phrases. Ce que vous déployez réellement.
Matrix est un protocole ouvert pour la communication en temps réel. Un homeserver est un serveur qui exécute le protocole ; les utilisateurs appartiennent chacun à un homeserver, identifiés comme @alice:example.com — le même schéma que l'e-mail. Les salons sont les unités de conversation ; un seul salon peut avoir des membres de nombreux homeservers différents, et l'état du salon est répliqué sur tous les homeservers participants. Les salons privés chiffrent chaque message avec des clés par appareil (Olm/Megolm) afin que le serveur ne voie que du texte chiffré. L'ensemble du réseau est un graphe de homeservers se fédérant leur état de salon mutuellement.
Les propriétés intéressantes : aucune autorité centrale ne peut fermer Matrix (le protocole est ouvert et tourne partout), les utilisateurs sur différents serveurs se parlent de façon transparente (fédération), les salons privés ont un vrai chiffrement de bout en bout (pas un chiffrement en transit de style publicitaire), et un utilisateur peut changer de homeserver tout en conservant son identité en gérant le sien. Le compromis est la complexité opérationnelle — gérer un homeserver demande plus de travail que de se connecter à Discord — et un écosystème de clients soignés plus restreint que les plateformes propriétaires.
Ce que vous déployez dans ce guide : Synapse (le homeserver), PostgreSQL (sa base de données), Element Web (le client navigateur, hébergé depuis votre propre domaine) et Caddy (le reverse proxy + TLS automatique). Optionnellement un backend de stockage de médias et les endpoints well-known pour la découverte de fédération. L'ensemble de la stack correspond à deux fichiers Docker Compose et une configuration Caddy.
Dimensionnement. Synapse est gourmand en mémoire.
Synapse garde l'état par salon en mémoire, et rejoindre un grand salon fédéré (par exemple #matrix:matrix.org avec 60 000 membres) tire une grande partie de cet état dans votre homeserver. Le résultat est que même un Synapse mono-utilisateur peut utiliser 2–3 Go de RAM en régime permanent si l'utilisateur est dans des salons fédérés très actifs. Prévoyez en conséquence.
Utilisateur unique, fédération modeste. 2 vCPU, 4 Go de RAM, 40 Go de SSD. Le <a href="/fr/vps/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">niveau Ravelin (5,90 $/mois)</a> chez NordBastion est parfaitement dimensionné. Le disque croît d'environ 10 Go par an pour un utilisateur unique actif ; prévoyez la marge nécessaire.
Petite équipe, 5–20 utilisateurs. 4 vCPU, 8 Go de RAM, 100 Go de SSD. Le tier Iron (24,90 $/mois) gère cela sans difficulté. Faites tourner PostgreSQL sur le même VPS ; la base de données tient dans la RAM disponible.
Homeserver public, 100+ utilisateurs. Au-delà de 100 utilisateurs actifs, Synapse bénéficie de processus worker (expéditeur de fédération, lecteur de fédération, workers de lecture client séparés) et d'un PostgreSQL optimisé. Les tiers Iron ou Granite gèrent cela, mais la complexité opérationnelle croît de façon non linéaire — à cette échelle, vous êtes un admin Matrix en plus d'un utilisateur logiciel.
Réalité disque. Les téléchargements médias (images, vidéos, fichiers) provenant de salons fédérés s'accumulent sur votre homeserver car la fédération Matrix télécharge les médias en local pour les servir. Un homeserver public très actif peut ajouter 1 Go de médias par semaine. La configuration media_retention de Synapse permet d'élaguer les contenus anciens ; révisez-la une fois par trimestre.
L'installation Docker Compose. Synapse, PostgreSQL, Element.
Démarrez un VPS Debian 12 fraîche, pointez trois enregistrements DNS dessus : matrix.example.com (le nom d'hôte du homeserver), element.example.com (le client web) et example.com lui-même si vous souhaitez la forme courte d'identifiant @alice:example.com. Connectez-vous en SSH en tant qu'utilisateur sudo.
1. Installer Docker et Compose. curl -fsSL https://get.docker.com | sh — Docker Engine inclut Compose v2 dans le même paquet.
2. Générer la configuration Synapse. mkdir -p ~/synapse/data && docker run -it --rm -v ~/synapse/data:/data -e SYNAPSE_SERVER_NAME=example.com -e SYNAPSE_REPORT_STATS=no matrixdotorg/synapse:latest generate — ceci écrit homeserver.yaml. Éditez-le : changez la base de données de SQLite vers PostgreSQL, définissez l'URL média, mettez enable_registration: false pour commencer (vous créez les utilisateurs via la CLI admin pour l'instant).
3. Écrire le docker-compose.yml. Trois services : postgres (postgres:16, volume persistant, locale C), synapse (matrixdotorg/synapse:latest, monte ~/synapse/data, dépend de postgres), element (vectorim/element-web:latest, monte un config.json pointant vers https://matrix.example.com). Mappez uniquement synapse:8008 et element:80 vers localhost ; ne liez pas 0.0.0.0.
4. Fronter avec Caddy. Deux sites Caddyfile : matrix.example.com proxifie vers 127.0.0.1:8008 (Synapse) sur les ports 443 et 8448 (le port de fédération) ; element.example.com proxifie vers 127.0.0.1:8001 (Element Web). Caddy récupère automatiquement les certificats Let's Encrypt.
5. Découverte de la fédération (.well-known). Ajoutez deux fichiers JSON statiques sur example.com lui-même : /.well-known/matrix/server retournant {"m.server": "matrix.example.com:443"} et /.well-known/matrix/client retournant {"m.homeserver": {"base_url": "https://matrix.example.com"}}. Cela permet aux identifiants courts @alice:example.com de se résoudre correctement. Vérifiez avec le Federation Tester sur federationtester.matrix.org.
6. Créer votre premier utilisateur. docker exec -it synapse register_new_matrix_user -u alice -p <password> -a -c /data/homeserver.yaml http://localhost:8008
Element, marque, politique d'inscription. Les décisions qui restent.
Configuration d'Element. Element Web lit un config.json qui pointe vers votre homeserver, définit le thème par défaut, la marque et la liste des « salons suggérés » pour les nouveaux comptes. Définissez default_server_config.m.homeserver.base_url sur https://matrix.example.com, la marque sur le nom de votre projet, et désactivez le champ brand_url suggérant matrix.org. Les nouveaux utilisateurs atterrissent sur Element Web pointé vers votre serveur, pas celui de quelqu'un d'autre.
Politique d'inscription. Trois modes : fermé (seul l'admin peut inscrire des utilisateurs via le CLI ; la posture de modération la plus propre), basé sur des jetons (vous générez des jetons d'inscription via l'API admin et les partagez ; mieux pour un petit groupe), ouvert (n'importe qui peut s'inscrire ; activez uniquement si vous avez l'intention d'exploiter un homeserver public avec des outils de modération). Commencez fermé et n'assouplissez que si vous avez une raison.
Liste de blocage de fédération. Synapse prend en charge federation_domain_whitelist (liste blanche uniquement) et des blocages par serveur via l'API admin. Pour la plupart des homeservers publics, la valeur par défaut est « se fédérer avec tout », avec des blocages réactifs des serveurs abusifs en cas de besoin. Le bot Mjolnir automatise cela si vous devenez une cible.
Sauvegardes. Dump nightly PostgreSQL + tarball ~/synapse/data, envoyé hors serveur via rclone vers un second VPS ou un bucket B2. Les deux sont nécessaires ; la base de données contient l'état des salons et les comptes, le répertoire de données détient les clés de signature et les médias. Tests de restauration chaque trimestre, comme pour toute sauvegarde.
La réalité de la modération. Ce que l'auto-hébergement signifie vraiment.
Gérer un homeserver Matrix signifie accepter que l'hébergeur est responsable de ce que le serveur fait. Sur un homeserver privé sur invitation uniquement, cette responsabilité est faible — vous connaissez chaque utilisateur. Sur un homeserver public, la responsabilité évolue avec la base d'utilisateurs.
Abus entrant. Un salon public fédéré peut être entraîné dans des actions d'abus coordonnés, des dépôts d'images ou du harcèlement. Synapse expose des points d'API admin pour bannir un utilisateur (de tous les salons), bloquer un homeserver (plus de fédération) et forcer un serveur à quitter un salon. Le bot Mjolnir regroupe ces fonctionnalités dans un workflow de modération en salon ; le fork Draupnir en est la continuation activement maintenue.
Abus sortant. Un compte utilisateur compromis peut publier du contenu abusif dans des salons fédérés, ce qui nuit à la réputation de votre serveur auprès du reste du réseau. Deux mesures d'atténuation : limiter le débit par utilisateur (les limites par défaut de Synapse sont raisonnables) et exiger une vérification par e-mail pour les nouveaux comptes (ce qui élève la barre pour les inscriptions automatisées).
Posture juridique. Dans l'UE, un rôle de fournisseur d'infrastructure confère de solides protections en matière de responsabilité pour les intermédiaires (article 14 de la directive sur le commerce électronique, article 6 du DSA) — vous n'êtes pas responsable du contenu des utilisateurs tant que vous répondez aux notifications et retraits. Les juridictions nordiques prolongent cela avec des protections constitutionnelles explicites de liberté de la presse. Le même homeserver exploité dans une juridiction sans protections pour les intermédiaires est opérationnellement plus risqué ; choisissez l'emplacement de l'hébergeur en conséquence.
La valeur par défaut sûre. Inscription sur invitation uniquement, fédération activée avec blocages réactifs, Mjolnir / Draupnir installé mais inutilisé jusqu'à nécessité, conditions d'utilisation publiées sur le site du homeserver avec une politique d'utilisation acceptable claire. Cette posture gère 95 % des opérateurs sans effort supplémentaire.
Pourquoi l'hébergeur importe. Le chiffrement protège le contenu, l'hébergeur protège les métadonnées.
Matrix E2EE protège les corps des messages — le serveur ne détient que du texte chiffré pour les salons privés. Ce qu'il ne protège pas, ce sont les métadonnées : quels homeservers se fédèrent entre eux, quels utilisateurs sont dans quels salons, quand ils sont en ligne, à quelle fréquence ils envoient des messages, quels sont leurs appareils. Ce graphe de métadonnées réside sur le homeserver et les homeservers avec lesquels il se fédère, et est techniquement hors de portée de la couche de chiffrement.
Un homeserver fonctionnant sur un VPS lié à une identité KYC relie le graphe de métadonnées à l'identité légale de l'opérateur. Une assignation à comparaître adressée au fournisseur d'hébergement expose les métadonnées de fédération — qui parle à qui, quand, dans quels salons — sans jamais avoir à casser le chiffrement.
La posture de NordBastion est l'inverse : <a href="/fr/doctrine/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">inscription sans KYC</a>, paiement en crypto, juridictions constitutionnelles nordiques. Le homeserver est le vôtre ; le lien entre le homeserver et un nom réel n'existe pas ; le régime juridique qui touche au disque dispose de protections explicites de la liberté de la presse. La combinaison correspond au modèle de sécurité de Matrix lui-même — aussi bien la couche cryptographique de contenu que la couche opérationnelle des métadonnées sont défendues.
Questions, réponses.
Huit questions qui se posent lors de la gestion d'un homeserver Matrix en 2026.
Qu'est-ce que Matrix et en quoi est-il différent de Discord ou Slack ?
Matrix est un protocole de communication en temps réel fédéré et à standard ouvert — pensez SMTP pour le chat. N'importe qui peut faire tourner un homeserver (Synapse, Dendrite, Conduit), les utilisateurs sur différents homeservers se parlent de façon transparente, chaque message dans un salon privé est chiffré de bout en bout par défaut, aucune entreprise centrale ne contrôle le réseau. Discord et Slack sont centralisés, propriétaires, et la société héberge chaque conversation. Le compromis : Matrix a une complexité opérationnelle légèrement plus élevée et un écosystème de clients soignés plus restreint, mais vous possédez chaque octet.
Synapse, Dendrite ou Conduit — quel homeserver ?
Synapse est le serveur de référence, écrit en Python, le plus complet en fonctionnalités et le choix validé en production. Il est gourmand en mémoire. Dendrite est la réécriture Go plus récente, beaucoup plus légère, manquant quelques fonctionnalités de modération avancées mais comblant rapidement l'écart. Conduit est la troisième option, un homeserver en Rust axé sur la faible empreinte en ressources, adapté à un homeserver mono-utilisateur sur un VPS bon marché. Choisissez Synapse par défaut sauf raison spécifique — la documentation, les outils de modération et les ponts tiers supposent tous Synapse.
De quel VPS ai-je besoin pour un homeserver Matrix ?
Utilisateur unique fédérant vers le réseau Matrix plus large — 2 vCPU, 4 Go de RAM, 40 Go de SSD est le plancher pratique. Petite équipe (5–20 utilisateurs) — 4 vCPU, 8 Go de RAM, 100 Go de SSD. Les tiers Ravelin ou Iron couvrent les deux cas. La ressource dominante est la RAM (Synapse garde beaucoup d'état de salon en mémoire) et le disque (les téléchargements médias et l'historique des salons fédérés croissent continuellement).
Devrais-je activer la fédération ?
Presque toujours oui — c'est tout le point de Matrix. La fédération permet à vos utilisateurs de parler à n'importe qui sur matrix.org, mozilla.org, kde.org et les milliers d'autres homeservers. Les exceptions : un serveur d'équipe interne privé où vous ne voulez pas que quiconque découvre des salons ; un modèle de menace élevé où les schémas de trafic de fédération divulguent des informations ; un serveur hébergeant des sujets sensibles où vous souhaitez un contrôle strict des membres. Désactiver la fédération plus tard est possible ; la réactiver vous rend découvrable.
Les salons privés sont-ils chiffrés de bout en bout par défaut ?
Oui — chaque client Element active E2EE par défaut pour les nouveaux messages directs et les salons privés. Le chiffrement est Olm/Megolm par salon avec vérification d'appareil croisé. Le serveur ne voit que du texte chiffré pour le corps du message. Les salons publics sont non chiffrés par conception (puisque n'importe qui peut les rejoindre, le chiffrement ne protégerait rien). Les salons publics fédérés sont visibles de tous — ce qui est le but d'un salon public.
Quelle est la réalité de la modération lors de la gestion d'un homeserver public ?
C'est un vrai travail. Si vous autorisez l'inscription publique, votre homeserver se fédérera à des salons de spam, sera entraîné dans des salons de coordination d'abus, et surfacera occasionnellement du contenu répréhensible provenant de serveurs fédérés. Gérer un homeserver public nécessite la volonté d'appliquer des bannissements au niveau serveur, de bloquer des serveurs hostiles par fédération et de répondre aux signalements d'abus. Pour la plupart des opérateurs, la posture correcte est l'inscription fermée (sur invitation uniquement) — chaque utilisateur est quelqu'un que vous connaissez, et la surface d'abus tombe à presque zéro.
Puis-je utiliser mon homeserver Matrix comme remplacement Slack / Discord au travail ?
Oui — Element Server Suite et la combinaison sous-jacente Synapse + Element Web couvrent le jeu de fonctionnalités « chat d'équipe avec salons persistants, fils de discussion, réactions, réunions vocales/vidéo ». Le principal écart par rapport à Slack concerne les intégrations tierces (moins d'applications préconstruites) ; le principal écart par rapport à Discord concerne les salons vocaux soignés. Les deux sont faisables mais nécessitent un peu d'effort opérateur. Pour une petite équipe qui valorise la souveraineté des données au détriment du polish, l'échange est clairement valable.
Pourquoi l'hébergeur où je loue le VPS importe-t-il pour un serveur Matrix ?
Parce que le protocole de chat fédéré crée des métadonnées persistantes sur qui-parle-à-qui-quand au niveau du homeserver. Ces métadonnées sont riches (graphe de salons fédérés, événements de fédération, téléchargements médias). Les placer sur un hébergeur avec KYC relie les métadonnées à votre identité ; les placer sur un hébergeur dans une juridiction hostile signifie qu'un acteur étatique peut les contraindre. Un VPS nordique no-KYC aligne la posture de métadonnées de l'hébergeur avec la posture cryptographique du protocole — les deux moitiés de l'histoire de la vie privée.
Un VPS nordique pour votre homeserver. Sans KYC, payé en crypto.
Ravelin (2 vCPU, 4 Go, 5,90 $/mois) couvre un Synapse à utilisateur unique fédérant. Iron (4 vCPU, 8 Go, 24,90 $/mois) est la réponse pour une petite équipe.
Dernière révision · 2026-05-20 · Références · Documentation upstream Synapse, référence de configuration Element, spécification Matrix, DSA article 6 UE · Fréquence · annuellement
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Fediverse instance, Docker Compose, federation-ready in 90 min.
What “no KYC” actually means — and what it does not.
Why Sweden, Finland, Norway and Iceland — the legal floor of each.
XMR end-to-end — wallet, transfer, confirmations, change.