Messagerie · sans KYC
Hébergez Matrix (Synapse) sur un VPS offshore
Déployez votre propre homeserver Matrix sur un VPS offshore sans KYC et gardez le contrôle total des clés de votre réseau de chat fédéré, chiffré de bout en bout.
Ce que c'est
Synapse est l'implémentation serveur de référence de Matrix, un protocole ouvert pour le chat, la voix et la vidéo en temps réel, décentralisés et chiffrés de bout en bout. Auto-héberger Synapse vous donne votre propre homeserver, capable de fédérer avec l'ensemble du réseau Matrix ou de rester entièrement privé, avec chaque message, fichier média et compte hébergé sur du matériel que vous contrôlez.
Pourquoi l'héberger en offshore
Les métadonnées de chat (qui parle à qui, quand et depuis où) sont exactement le type de données que les plateformes centralisées et les juridictions qui hébergent leurs serveurs enregistrent et transmettent. Sur un VPS offshore sans KYC payé en crypto, le homeserver qui détient les messages et les clés de chiffrement de votre communauté n'est rattaché à aucune identité réelle et se trouve dans une juridiction respectueuse de la vie privée, hors de portée de votre pays d'origine.
Le déploiement
Une configuration de référence fonctionnelle
Copiez ceci sur une nouvelle instance ChainVPS. Remplacez les paramètres, puis lancez-la.
# ── One-time setup, run in order on Ubuntu 24.04 (Docker + compose-plugin installed) ──
#
# 1. Generate Synapse's config (replace matrix.example.com with your real domain):
# mkdir -p synapse-data pgdata
# docker run --rm -v "$(pwd)/synapse-data:/data" \
# -e SYNAPSE_SERVER_NAME=matrix.example.com \
# -e SYNAPSE_REPORT_STATS=no \
# ghcr.io/element-hq/synapse:latest generate
#
# 2. In synapse-data/homeserver.yaml, REPLACE the generated sqlite `database:`
# block with the postgres block shown at the bottom of this file, and add
# `x_forwarded: true` under the port-8008 listener (you are behind a proxy).
#
# 3. Bring the stack up: docker compose up -d
#
# 4. Create your admin user:
# docker compose exec synapse register_new_matrix_user \
# -u admin -a -c /data/homeserver.yaml http://localhost:8008
#
# 5. Put a TLS reverse proxy (Caddy/nginx) on 443 -> 127.0.0.1:8008 and serve
# /.well-known/matrix/server + /.well-known/matrix/client for federation.
services:
db:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_USER: synapse
POSTGRES_PASSWORD: CHANGE_ME_STRONG_DB_PASSWORD
POSTGRES_DB: synapse
# Synapse REQUIRES the DB to use C locale — this is a hard requirement:
POSTGRES_INITDB_ARGS: "--encoding=UTF8 --locale=C"
volumes:
- ./pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U synapse"]
interval: 10s
timeout: 5s
retries: 5
synapse:
image: ghcr.io/element-hq/synapse:latest
restart: unless-stopped
depends_on:
db:
condition: service_healthy
environment:
SYNAPSE_SERVER_NAME: matrix.example.com
SYNAPSE_REPORT_STATS: "no"
volumes:
- ./synapse-data:/data
ports:
# Client + federation HTTP. Bound to localhost — TLS is terminated by
# your reverse proxy. Never expose 8008 to the internet in the clear.
- "127.0.0.1:8008:8008"
# ── Paste this into synapse-data/homeserver.yaml, replacing the sqlite block ──
# database:
# name: psycopg2
# args:
# user: synapse
# password: CHANGE_ME_STRONG_DB_PASSWORD
# dbname: synapse
# host: db
# port: 5432
# cp_min: 5
# cp_max: 10Pare-feu
Ports à ouvrir
| Port | Protocole | Objectif |
|---|---|---|
| 443 | TCP | Proxy inverse HTTPS : API Element/client + délégation de fédération /.well-known (le seul port devant être exposé sur internet) |
| 8008 | TCP | Écouteur HTTP client+fédération de Synapse — à lier uniquement à 127.0.0.1, le TLS étant géré par le proxy |
| 8448 | TCP | Port de fédération directe optionnel ; nécessaire uniquement si vous n'utilisez PAS la délégation .well-known (nécessite son propre TLS) |
| 5432 | TCP | PostgreSQL — réseau Docker interne uniquement, à ne jamais publier vers l'hôte ou internet |
Dimensionnement optimal
De quel forfait vous avez besoin
VPS Nano / Small (2 vCPU, 2-4 GB RAM)
Serveur personnel ou familial, moins d'une dizaine d'utilisateurs, peu ou pas de fédération. Synapse est gourmand en mémoire — 2 Go constituent le plancher réaliste, 4 Go si vous rejoignez de grands salons publics.
VPS Pro (4 vCPU, 8 GB RAM)
Petite communauté de quelques dizaines à quelques centaines d'utilisateurs avec une fédération active. Ajustez les caches de Synapse et le shared_buffers de Postgres ; le stockage SSD compte pour les médias et la base de données.
Dedicated (8+ cores, 16-32 GB RAM)
Des centaines à des milliers d'utilisateurs, ou appartenance à de très grands salons fédérés. Répartissez Synapse en workers (federation sender, sync, media) et appliquez un tuning dédié à Postgres ; la bande passante illimitée permet de ne pas plafonner le trafic média/fédération.
Meilleurs emplacements : Choisissez un emplacement à protection renforcée pour un serveur de communication : la Suisse et l'Islande offrent des juridictions solides en matière de protection des données et constituent des lieux naturels pour un homeserver détenant métadonnées de messages et clés de chiffrement, tandis que les Pays-Bas et le Luxembourg offrent des routes à faible latence et bien peerées vers l'Europe pour un chat et des appels vocaux en temps réel plus fluides. Matrix fonctionnant en temps réel, privilégiez la région à protection renforcée la plus proche de vos utilisateurs principaux ; la bande passante illimitée et la protection DDoS incluse comptent, car un homeserver fédéré exposé sur internet est une cible permanente.
Verrouillez-le
Liste de vérification du durcissement
- Désactivez les inscriptions ouvertes : définissez enable_registration: false, ou verrouillez les inscriptions derrière registration_requires_token avec des jetons d'invitation individuels — un serveur Matrix ouvert est repéré puis inondé de bots de spam en quelques jours.
- Contrôle de la fédération : utilisez la délégation /.well-known/matrix/server pour que votre server_name reste propre (@user:example.com), et si le serveur est privé, définissez federation_domain_whitelist (ou désactivez entièrement la fédération) pour empêcher les serveurs inconnus de vous atteindre.
- Verrouillez les aperçus d'URL et les médias : url_preview_enabled récupère des URL arbitraires côté serveur (risque de SSRF) — conservez la valeur par défaut de url_preview_ip_range_blacklist pour les plages privées, plafonnez max_upload_size, et exécutez régulièrement une purge/rétention des médias, car le stockage média croît sans limite.
- Resserrez les limites de débit derrière le proxy : définissez x_forwarded: true sur l'écouteur du port 8008 pour que Synapse voie les véritables IP des clients, puis ajustez rc_login, rc_registration et rc_message pour limiter le brute-force et les abus ; la protection DDoS de ChainVPS couvre la couche L3/4 en dessous.
- Sauvegardez PostgreSQL et la clé de signature : effectuez des dumps réguliers de la base et copiez synapse-data/*.signing.key hors site — perdre la clé de signature signifie perdre définitivement l'identité de votre serveur et toute confiance de fédération.
- Maintenez-le à jour : figez puis mettez régulièrement à jour le tag ghcr.io/element-hq/synapse, conservez report_stats: no, et ne publiez jamais les ports 8008 ou 5432 sur internet — seul le port 443 (et éventuellement le 8448) doit être accessible.
Questions
Hébergement Matrix (Synapse) — FAQ
Ai-je besoin de mon propre nom de domaine ?
Oui. Les identifiants d'utilisateur Matrix et la fédération sont liés à un domaine (par ex. @you:example.com). Vous avez besoin d'un domaine dont vous contrôlez le DNS pour pointer vers le VPS et servir les enregistrements de fédération /.well-known. Le domaine peut être enregistré via un bureau d'enregistrement respectueux de la vie privée ; le serveur lui-même reste sans KYC.
Puis-je faire fonctionner Synapse en mode entièrement privé, sans fédération ?
Oui. Définissez un federation_domain_whitelist vide, ou omettez l'écouteur de fédération, afin que votre homeserver ne communique jamais avec le réseau Matrix public. Vos utilisateurs bénéficient tout de même d'un chat, d'appels vocaux et vidéo entièrement chiffrés de bout en bout entre eux, le tout sur votre serveur offshore.
Pourquoi PostgreSQL plutôt que SQLite par défaut ?
Synapse est livré avec SQLite uniquement pour des tests rapides. Il ne gère ni la concurrence ni la charge de fédération et ne peut pas être réparti sur des workers. Tout déploiement réel doit utiliser PostgreSQL créé avec la locale C (le fichier compose ci-dessus s'en charge pour vous) ; migrer plus tard est pénible, donc démarrez directement sur Postgres.
De combien de RAM Synapse a-t-il réellement besoin ?
Plus que ce que l'on imagine. Un serveur mono-utilisateur peu actif tient dans environ 1,5 à 2 Go, mais dès que vous rejoignez de grands salons fédérés, les caches par salon font gonfler la mémoire. Prévoyez 4 Go pour une petite communauté et dimensionnez les caches (caches: global_factor) en fonction de votre RAM plutôt que de les laisser croître sans contrôle.
Quel client mes utilisateurs doivent-ils installer ?
Element (web, bureau, iOS, Android) est le client Matrix standard et se connecte à votre homeserver en saisissant son URL. L'enregistrement /.well-known/matrix/client que vous servez sur le port 443 permet à Element de découvrir automatiquement votre serveur à partir du seul identifiant Matrix d'un utilisateur.
L'hébergement offshore nuit-il à la fédération ou à la qualité des appels ?
Non. La fédération fonctionne via HTTPS standard quel que soit l'emplacement, et la protection DDoS incluse assure la stabilité du serveur exposé publiquement. Pour la voix/vidéo en temps réel, choisissez l'emplacement à protection renforcée le plus proche de vos utilisateurs afin de minimiser la latence ; les Pays-Bas et le Luxembourg sont bien peerés pour le trafic européen.
Plus à auto-héberger
Autres stacks en un clic
Déployer Matrix (Synapse)
dans les 60 prochaines secondes.
Bande passante illimitée · DDoS inclus · 21 cryptomonnaies · sans KYC.