Cas d'usage · Homeserver Matrix · Mis à jour 2026

Votre propre homeserver Matrix.
De bout en bout. Fédéré. Nordique. Non-demandable.

Synapse + Postgres + Element sur un Ravelin à $23.90/mo. Votre homeserver relaye et fédère ; il ne peut pas lire son propre trafic E2E ; la juridiction nordique signifie que personne ne peut poliment lui demander de commencer à essayer.

Choisissez le bon palier Passer à la recette Docker Compose

En résumé

01
Ravelin à $23.90/mo porte confortablement un Synapse bien fédéré à ~100 salons — Postgres, Redis, les workers Synapse, le cache d'état des salons, tout sur la même machine.
02
Le chiffrement de bout en bout est structurel — le homeserver relaye du ciphertext qu'il ne peut pas déchiffrer. L'inscription admin sans KYC signifie que l'opérateur ne porte pas de trace écrite non plus.
03
Juridiction nordique + no-logs-by-design + uplink illimité. Le bavardage de fédération pour un ensemble de salons actifs représente un vrai volume ; il ne facture pas en plus ici.

Pourquoi s'en donner la peine

Pourquoi auto-héberger le homeserver tout court.

Rejoindre matrix.org est la bonne réponse pour la plupart des gens. Faire tourner votre propre homeserver est la bonne réponse quand votre handle, votre appartenance aux salons et les métadonnées de vos messages ne devraient pas vivre sur le panneau administratif de quelqu'un d'autre. Le protocole est fédéré, le chiffrement est de bout en bout ; la pièce manquante est « qui contrôle la machine à laquelle mon compte est ancré », et la réponse change matériellement le modèle de menace.

Le modèle de fédération de Matrix est généreux : tout homeserver peut parler à tout autre homeserver, les salons s'étendent entre serveurs, le chiffrement suit l'utilisateur, et aucun répertoire central n'est requis pour participer. Une fois votre homeserver en marche et validé contre le federation tester, votre compte est un citoyen de première classe du réseau — le même que @user:matrix.org ou @user:mozilla.org, simplement sur votre domaine.

L'histoire opérationnelle de Synapse est balisée : template Docker Compose upstream, Postgres pour l'état, Redis pour le pool de workers, workers shardés optionnels pour la fédération haut volume. Rien n'est nouveau ; tout est documenté ; les modes de défaillance sont connus.

La bonne question n'est pas « auto-héberger ou matrix.org » dans l'abstrait — c'est « est-ce que je veux mon identité de fédération ancrée à une machine que j'administre ». Si la réponse est oui, le reste de cette page est la recette.

Dimensionnement

Le bon palier NordBastion pour le job.

Pour un homeserver communautaire avec ~100 salons (mélange de petits DM et d'une poignée de salons publics bien peuplés fédérés vers l'extérieur), le Ravelin ($23.90/mo, 8 vCPU, 16 GB, 480 GB NVMe) est le bon palier. Le chemin de données Python de Synapse est gourmand en RAM sous des bursts de fédération — un salon populaire rejoint par un serveur de 50k utilisateurs produit un pic transitoire de résolution d'état qui veut de la marge. 16 GB absorbent cela confortablement.

Au-delà de ~1000 salons actifs ou dès que le trafic de fédération pousse Synapse à avoir besoin de son mode workers shardés, le palier Bulwark vous donne les cœurs pour faire tourner des workers federation_sender, synchrotron et event_persister dédiés — l'histoire de scaling horizontal de Synapse au sein d'une seule machine. À ce stade vous voulez aussi réfléchir à si Postgres devrait être sur son propre VPS ; nous pouvons parler d'une architecture à deux machines.

Pour un homeserver personnel — votre compte, quelques DM, deux ou trois petits salons privés — un Garrison ($11.90/mo, 4 vCPU, 8 GB, 240 GB NVMe) suffit largement. Conduit sur un Sentinel est techniquement possible pour une configuration mono-utilisateur, mais Synapse sur un Garrison vous donne la marge pour grandir sans migration.

Ce qu'aucune de ces options n'est : une offre Matrix managée à mille locataires. NordBastion est conçu pour l'opérateur qui fait tourner son propre homeserver pour des gens qu'il connaît — pas pour vendre des comptes Matrix à des inconnus.

Mise en place

Du VPS fraîchement provisionné au premier salon fédéré. Six étapes, environ quatre-vingt-dix minutes.

Un croquis squelette — la doc Synapse upstream element-hq reste la référence faisant autorité pour le tuning homeserver.yaml et le mode workers.

01

Docker + Compose

Le moteur Docker officiel + le plugin Compose v2. Element-HQ publie une image Synapse maintenue que vous pouvez épingler par tag.
```
curl -fsSL get.docker.com \
  | sh
apt install \
  docker-compose-plugin
```
02

Générer homeserver.yaml

Le mode « generate » one-shot de l'image Synapse écrit une config de démarrage indexée sur votre server_name. Désactivez l'inscription ouverte dans le même passage.
```
docker run --rm \
  -v ./data:/data \
  -e SYNAPSE_SERVER_NAME=example.org \
  matrixdotorg/synapse:latest \
  generate
```
03

Câbler Postgres + Redis

Postgres est le store de production ; SQLite est uniquement pour les tests. Redis est requis pour le pool de workers même si vous démarrez en mono-processus.
```
# ajouter à docker-compose.ymlpostgres: postgres:15
redis:    redis:7-alpine
# puis dans homeserver.yaml : driver de base psycopg2
```
04

Publier well-known

Deux petits fichiers JSON à /.well-known/matrix/{client,server} sur votre domaine apex. Servis en application/json avec CORS Access-Control-Allow-Origin : *.
```
# /.well-known/matrix/server
{"m.server": "matrix.example.org:443"}
# /.well-known/matrix/client
{"m.homeserver":{"base_url":"https://matrix.example.org"}}
```
05

Valider la fédération

federationtester.matrix.org vérifie well-known, la chaîne de certificats, le handshake TLS, le handshake de version, et l'échange de clés. N'invitez pas d'utilisateurs tant qu'il n'est pas au vert.
```
# collez server_name dans :# federationtester.matrix.org
# tous les checks doivent être au vert
```
06

Battre monnaie d'admin via secret partagé

registration_shared_secret dans homeserver.yaml + CLI register_new_matrix_user = un compte admin sans jamais ouvrir l'inscription publique.
```
docker compose exec synapse \
  register_new_matrix_user \
  -a -c /data/homeserver.yaml \
  http://localhost:8008
```

Pourquoi cet hébergeur pour ce job

Pourquoi NordBastion spécifiquement pour un homeserver Matrix.

Sans KYC

Les admins d'infra E2E ne devraient pas porter de trace écrite.

Le chiffrement de bout en bout est une revendication forte. Elle est minée à l'instant où l'hébergeur du relais sait, depuis le KYC côté facturation, exactement quelle personne morale a monté ce homeserver. L'inscription sans KYC avec facturation crypto uniquement garde les métadonnées administratives du relais aussi opaques que les métadonnées de payload du relais : « le solde prépayé derrière cet e-mail », fin de l'histoire.

Juridiction nordique

Ceinture et bretelles.

Le chiffrement de bout en bout de Matrix empêche déjà arithmétiquement le relais de lire les payloads. La juridiction nordique ajoute une seconde couche : pas de mandat de rétention de données forçant l'hébergeur à logger les métadonnées de connexion, pas de législation de scanning côté client activée, et un warrant canary publié qui décrit ce qui se passerait si quelqu'un essayait de changer les maths (nous ne le pouvons pas). Deux couches de « non » battent une.

1 Gbps illimité

La fédération, c'est du volume.

Un homeserver fédéré dans quelques salons publics bien peuplés pousse beaucoup de petits événements de fédération — chaque join, chaque changement d'état, chaque réception de message est un fanout deliver-to-N-servers. L'agrégat n'est pas énorme mais il est soutenu, et tout hébergeur qui facture au GB-sortant rend l'opérateur nerveux. L'uplink illimité supprime la surcharge cognitive : fédérez autant que le protocole le demande ; la facture est la même.

Verdict

Faites-le tourner sur un Ravelin. Désactivez l'inscription ouverte. Laissez la fédération faire le reste.

Auto-héberger un homeserver Matrix est l'un des gestes de souveraineté les plus propres qu'un petit groupe puisse faire pour sa messagerie. Pour le prix d'un seul siège d'outil de chat SaaS vous obtenez un homeserver fédéré, chiffré de bout en bout dont les handles survivent à toute plateforme, dont la modération est la vôtre, et dont l'hébergement est dans une juridiction sans mandats de rétention de données ni législation de scanning côté client activée.

NordBastion est tranché sur les parties qui comptent pour ce job précis — inscription admin sans KYC, juridiction nordique, uplink illimité — et délibérément ordinaire pour le reste. Docker est Docker. Synapse est Synapse. Element-HQ livre l'image ; nous livrons la machine.

Prenez une soirée, parcourez les six étapes, validez contre le federation tester, battez monnaie de l'admin. Le homeserver survit à la soirée pendant des années.

FAQ · Matrix sur un VPS

Les questions qui se posent en premier.

Les huit questions sur lesquelles les admins Matrix luttent réellement avant docker compose up. La délégation well-known est la question deux pour une raison.

Pourquoi du E2E si le serveur est déjà à moi ?

Parce que le serveur est une machine et que les messages vivent pour toujours. Quiconque a accès au disque — un accident de snapshot, une image forensique, un co-admin devenu rogue, un successeur quand vous finissez par passer la main — voit du texte en clair si le salon n'est pas chiffré. Le chiffrement de bout en bout garde le homeserver utile (il relaye, il fédère, il présente l'UI) tout en rendant la charge utile des messages arithmétiquement illisible à tout sauf aux clés de device du participant. Auto-hébergement et E2E sont ceinture + bretelles : vous contrôlez le relais ET le relais ne peut pas lire son propre trafic.

Qu'est-ce que la délégation well-known et pourquoi tout le monde s'y prend les pieds ?

Matrix laisse votre domaine côté utilisateur (example.org) différer de votre domaine côté serveur (matrix.example.org) en servant deux petits fichiers JSON à https://example.org/.well-known/matrix/client et /.well-known/matrix/server. Le client dit à Element quelle URL de homeserver utiliser ; le serveur dit aux pairs fédérants où joindre Synapse pour l'API s2s. Les gens trébuchent sur trois choses : servir les fichiers avec le mauvais Content-Type, CORS qui n'autorise pas les autres instances à les récupérer, ou le fichier serveur pointant sur un port que le pare-feu n'expose pas réellement. Validez avec federationtester.matrix.org avant de publier le salon.

Synapse vs Dendrite vs Conduit — cela importe-t-il pour l'hébergement ?

Synapse (Python, l'implémentation de référence) est ce que 95 % des homeservers publics font tourner ; c'est le pair de fédération le plus testé et le seul qui supporte chaque fonctionnalité que la spec définit. Conduit (Rust, binaire unique, RocksDB) et Dendrite (Go, microservices) sont plus légers — Conduit tourne notoirement sur un Raspberry Pi. Pour un homeserver fédéré public avec des utilisateurs dessus, Synapse est la réponse ; pour un serveur mono-utilisateur de hobbyiste vous pouvez expérimenter Conduit sur un Sentinel. Cet éditorial suppose Synapse.

Comment éviter le spam d'inscription publique ?

Réglez enable_registration: false dans homeserver.yaml et appuyez-vous sur registration_shared_secret pour battre monnaie de comptes via l'API admin pour les gens que vous voulez réellement. Alternativement, enable_registration_without_verification: false combiné à un flux d'invitation par secret partagé en dur. La fédération Matrix est suffisamment grande pour que tout homeserver en inscription ouverte devienne une ferme à comptes spambot en quelques jours ; la réponse canonique est « l'inscription est filtrée par l'admin, la fédération est ouverte ».

Element vs Cinny vs SchildiChat vs autres — le homeserver s'en soucie-t-il ?

Non — l'API Matrix C-S est le contrat protocolaire, et tout client conforme parle à tout serveur conforme. Element est le défaut et le plus testé ; Cinny est un client web plus léger que certains auto-hébergeurs préfèrent embarquer ; SchildiChat est un fork d'Element avec l'UI style Telegram ; FluffyChat cible le mobile-first. Le homeserver ne voit pas et ne se soucie pas du client sur lequel se trouve un utilisateur. Choisissez ce que votre communauté préfère, changez plus tard, aucune migration impliquée.

Comment fonctionne la sauvegarde des clés de bout en bout ?

Chaque utilisateur Matrix a un jeu de clés de device (par device, éphémères) et une clé de cross-signing (par compte, longue durée). La clé maître de cross-signing est ce qui permet à un utilisateur d'ajouter un nouveau device sans tout re-vérifier ; perdez-la et l'utilisateur est verrouillé hors des messages E2E historiques jusqu'à ce qu'il refasse ses clés. La fonctionnalité « Secure Backup » d'Element chiffre la clé de cross-signing avec une passphrase ou une clé de récupération et la stocke côté serveur comme ciphertext opaque — le homeserver détient le blob mais ne peut pas le lire. Documentez l'étape clé-de-récupération pour vos utilisateurs à l'inscription ; c'est l'unique morceau d'UX qui empêche les verrouillages évitables.

Puis-je migrer un salon d'un autre homeserver vers le mien ?

Pas directement — les salons sont des objets fédérés, pas des enregistrements par serveur, donc « déplacer » un salon signifie le faire évoluer (une primitive native Matrix qui crée un salon successeur et stub l'ancien avec une redirection) et inviter le même jeu de participants. L'ID du salon change, l'alias peut suivre. La migration directe de compte utilisateur entre homeservers est un élément ancien de la wishlist Matrix (la portabilité de compte est sur la roadmap de la spec) ; aujourd'hui vous créez un nouveau compte sur votre serveur et demandez aux gens de vous rajouter.

Quelle est l'histoire de gestion d'abus pour un homeserver fédéré ?

Matrix a des primitives de modération par salon (kick, ban, redact, admins de salon) et des primitives de modération par serveur (denylist via l'API module Synapse, le bot MJOLNIR pour les denylists managées, mode allowlist au niveau serveur pour fédération sur invitation uniquement). Pour un homeserver communautaire, l'abonnement à une denylist style MJOLNIR est la réponse standard — vous déléguez l'identification spam/abus à des communautés de denylist maintenues et appliquez la politique localement. Votre souveraineté : vous choisissez quelles denylists suivre.

Lecture suivante

Autres cas d'usage qui partagent le même uplink nordique.

Cas d'usage

Votre propre homeserver Matrix.
De bout en bout. Fédéré. Nordique. Non-demandable.

Pourquoi auto-héberger le homeserver tout court.

Le bon palier NordBastion pour le job.

Du VPS fraîchement provisionné au premier salon fédéré. Six étapes, environ quatre-vingt-dix minutes.

Docker + Compose

Générer homeserver.yaml

Câbler Postgres + Redis

Publier well-known

Valider la fédération

Battre monnaie d'admin via secret partagé

Pourquoi NordBastion spécifiquement pour un homeserver Matrix.

Les admins d'infra E2E ne devraient pas porter de trace écrite.

Ceinture et bretelles.

La fédération, c'est du volume.

Faites-le tourner sur un Ravelin. Désactivez l'inscription ouverte. Laissez la fédération faire le reste.

Les questions qui se posent en premier.

Autres cas d'usage qui partagent le même uplink nordique.

Instance Mastodon

Serveur VPN WireGuard

Relais Tor

Votre propre homeserver Matrix. De bout en bout. Fédéré. Nordique. Non-demandable.

Docker + Compose

Générer homeserver.yaml

Câbler Postgres + Redis

Publier well-known

Valider la fédération

Battre monnaie d'admin via secret partagé

Les admins d'infra E2E ne devraient pas porter de trace écrite.

Ceinture et bretelles.

La fédération, c'est du volume.

Faites-le tourner sur un Ravelin. Désactivez l'inscription ouverte. Laissez la fédération faire le reste.

Les questions qui se posent en premier.

Autres cas d'usage qui partagent le même uplink nordique.

Instance Mastodon

Serveur VPN WireGuard

Relais Tor

Votre propre homeserver Matrix.
De bout en bout. Fédéré. Nordique. Non-demandable.