Auto-héberger un serveur SimpleX sur un VPS

Ce que fait un serveur SimpleX auto-hébergé

Pour auto-héberger un serveur de chat SimpleX, vous exécutez un daemon sur un VPS : smp-server, le relais SMP (simplex messaging protocol). Il gère les files de messages dans lesquelles vos contacts écrivent et depuis lesquelles ils lisent les messages. Un second daemon facultatif, appelé xftp-server, relaie les transferts de fichiers. Les deux proviennent du même projet, simplexmq, et chacun se compose d’un binaire, d’un fichier de configuration et d’un journal en ajout uniquement.

Ce texte s’adresse à l’opérateur, pas à l’utilisateur de l’application. Le relais ne gère ni comptes, ni listes de contacts, ni historique des conversations. Il contient des files, des données chiffrées non distribuées et un certificat qui l’identifie. Vous prenez en charge la disponibilité du service, un peu d’espace disque et les métadonnées qui transitent par votre serveur.

Chaque commande, chemin, port et option présentés ci-dessous provient de la documentation du projet : la page d’hébergement du serveur SMP, la page du serveur XFTP et le document sur la sécurité du protocole. Lorsqu’un nombre est important, la page dont il provient est indiquée à côté.

Pourquoi un réseau sans identifiants utilisateur a quand même besoin de relais

SimpleX n’utilise ni noms d’utilisateur, ni numéros de téléphone, ni identifiants de compte. Un contact est une file unidirectionnelle : une adresse sur un relais, dans laquelle un côté écrit et que l’autre côté lit. Deux de vos contacts ne partagent aucun identifiant qu’un serveur pourrait utiliser pour les relier.

Ces files doivent tout de même être hébergées quelque part, pour une raison simple. Deux téléphones sont rarement connectés au même moment. Un composant doit accepter un message maintenant et le conserver jusqu’à ce que l’autre appareil le demande. C’est précisément le rôle d’un relais SMP. Les deux appareils ne se connectent donc jamais directement l’un à l’autre. Aucun des deux ne découvre ainsi l’adresse IP (internet protocol) de l’autre. Le relais prend en charge cette exposition à leur place.

Le nom d’hôte du relais fait partie de l’adresse de la file. Il apparaît donc dans chaque lien d’invitation que vous distribuez depuis ce relais. Gardez-le à l’esprit lorsque vous lirez le modèle de menace vers la fin.

Ce qu’un relais peut voir et ne peut pas voir

Le projet présente ce modèle de menace dans protocol/security.md. Il est utile de le lire avant toute installation, car ce relais vous appartiendra après ce guide. Un relais, y compris un relais entièrement contrôlé par un attaquant, ne peut pas connaître le contenu ni le type des messages. Il ne peut pas non plus ajouter, dupliquer ou altérer des messages individuels sans être détecté. Enfin, il ne peut pas casser le chiffrement de bout en bout au moyen d’une attaque active.

La même page indique ce qu’un relais peut faire. Il peut savoir quand le destinataire d’une queue est en ligne. Il peut compter le nombre de messages qui passent par une queue. Il peut connaître l’adresse IP d’un destinataire. Il peut supprimer tous les futurs messages d’une queue ou mentir sur l’état de cette queue.

La séparation est donc claire. La confidentialité relève du client, et l’auto-hébergement ne la modifie pas. Les métadonnées et la disponibilité relèvent de l’opérateur du relais, et l’auto-hébergement vous en confie la responsabilité.

Pré-requis

• Un VPS sous Ubuntu 22.04 ou 24.04. Le projet publie des binaires de release compilés précisément pour ces deux versions, en x86-64 et en aarch64.
• Un nom de domaine avec un enregistrement A pointant vers le VPS, ainsi qu’un enregistrement AAAA si vous utilisez IPv6. La documentation utilise smp1.example.com comme exemple.
• Un accès root ou sudo, ainsi qu’une deuxième session SSH ouverte pendant la modification du firewall.
• Un emplacement hors du serveur pour stocker une sauvegarde, car le répertoire de configuration contient l’identité du serveur.

Sur une instance ARM, utilisez l’asset aarch64 au lieu de x86-64. Rien d’autre ne change dans ce guide, et le choix entre les offres de VPS ARM et x86 dépend du prix et des performances par cœur, pas de la compatibilité de ce logiciel.

Installer une version figée, pas « latest »

Le projet fournit un script d’installation qui récupère la version actuelle et enregistre une commande simplex-servers-update. Il fonctionne. Figez tout de même la version : un relay dont le binaire change sans que vous le décidiez est un relay dont vous ne pouvez pas analyser le comportement en cas de panne.

En août 2026, la version actuelle de simplexmq est v6.5.0, publiée le 29 avril 2026. Consultez la page des releases pour trouver le tag voulu, puis utilisez ce tag partout ci-dessous.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp ne définit aucun mot de passe. Personne ne se connecte donc directement en tant que smp. Créez vous-même les deux répertoires avant toute autre opération, car /etc/opt appartient à root et possède le mode 755. L’utilisateur smp ne peut donc pas y créer son propre répertoire de configuration.

VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-server

Comparez ce hash aux sommes de contrôle SHA2-256 publiées dans les notes de version du même tag. Le projet signe également les sommes de contrôle des releases avec la clé SimpleX Chat FB44AF81A45BDE327319797C85107E357D4A17FC, documentée sur la page du serveur. Vous pouvez ainsi vérifier la signature au lieu de faire confiance à la page depuis laquelle vous avez récupéré le hash.

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

Installez-le volontairement avec root comme propriétaire. Le service s’exécute sous l’utilisateur smp. Une compromission du service ne peut donc pas réécrire le binaire qu’il exécute.

Initialisez le serveur et les deux secrets qu’il affiche

sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"

• --store-log (-l) écrit un journal append-only des files d’attente dans /var/opt/simplex/smp-server-store.log afin que le relais survive à un redémarrage. Sans cette option, un redémarrage supprime toutes les files d’attente, ce qui interrompt le fonctionnement de chaque contact routé par votre relais.
• --daily-stats (-s) écrit les compteurs au format CSV dans /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn ajoute votre domaine au certificat généré. Utilisez plutôt --ip si vous n’avez pas de domaine.
• --no-password permet à n’importe qui de créer une file d’attente sur votre relais. Pour le garder privé, définissez create_password sous [AUTH] dans /etc/opt/simplex/smp-server.ini après l’initialisation, au lieu de transmettre --password ici, car une ligne de commande reste visible dans l’historique de votre shell et dans la liste des processus pendant son exécution.

L’initialisation génère un certificat et affiche les deux valeurs que vous devez conserver. La première est l’empreinte, une chaîne base64 également écrite dans /etc/opt/simplex/fingerprint. La seconde est l’adresse complète du serveur : elle se compose de l’empreinte et de votre nom d’hôte. Copiez les deux maintenant.

L’initialisation crée également /etc/opt/simplex/ca.key, et la documentation vous demande de déplacer ce fichier vers un stockage hors ligne. La raison mérite d’être précisée : les clients enregistrent l’empreinte de cette autorité de certification. Toute personne qui possède ca.key peut donc émettre un nouveau certificat serveur que vos clients accepteront comme le vôtre. Vous n’aurez besoin de ce fichier que pour renouveler ultérieurement le certificat du serveur avec smp-server cert.

Considérez l’initialisation comme une étape unique. L’empreinte incluse dans votre adresse provient de l’autorité qu’elle génère. Si vous régénérez cette autorité, vous obtenez une autre adresse et l’ancienne adresse que vous avez communiquée ne fonctionne plus.

Exécuter le service sous systemd avec un utilisateur non privilégié

Écrivez /etc/systemd/system/smp-server.service exactement comme indiqué dans la documentation :

[Unit]
Description=SMP server systemd service

[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

L’unité fournie par le projet contient également AmbientCapabilities=CAP_NET_BIND_SERVICE. Cette ligne est nécessaire parce que le processus s’exécute sous smp et que les ports inférieurs à 1024 ne sont pas accessibles à un processus non root. Sans cette ligne, le daemon ne peut pas écouter sur les ports 80 ou 443. Ajoutez-la si vous servez ces ports. LimitNOFILE=65535 est important, car chaque client abonné conserve une connexion TCP ouverte et que la limite par défaut est largement insuffisante pour un relais actif. ExecStopPost copie le journal du store dans un fichier .bak à chaque arrêt. Vous disposez ainsi d’un point de retour gratuit.

sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server

Un démarrage correct journalise l’adresse du serveur. Vérifiez ensuite que les sockets sont réellement ouverts :

sudo ss -tlnp | grep -E ':(443|5223)'

Les deux lignes doivent indiquer smp-server. Exécuter le daemon sous son propre compte, sans droits sudo, applique le même principe que celui décrit dans les comptes dédiés par service sur un VPS. Cela empêche qu’un bug dans un daemon réseau permette d’obtenir un shell root.

Quels ports ouvrir et lequel laisser fermé

La documentation en liste trois : 5223/tcp, 443/tcp et 80/tcp. Le port 5223 est le transport SMP. La configuration fournie définit port: 5223,443 sous [TRANSPORT]. Le même protocole répond donc également sur 443, ce qui est important, car de nombreux réseaux restrictifs autorisent les connexions sortantes sur 443 et rien d’autre. Le port 80 est uniquement nécessaire pour la page d’information facultative et sa redirection vers HTTPS.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

N’ouvrez pas 5224. Il s’agit du port de contrôle. La documentation y accède depuis le serveur lui-même avec nc 127.0.0.1 5224. Ce port affiche l’état du serveur et supprime les files d’attente. Il doit donc rester limité à loopback, avec les mots de passe administrateur et utilisateur définis sous [AUTH]. Si vous découvrez cet outil, les bases d’ufw sur un VPS expliquent l’ordre des règles et la manière d’éviter de vous verrouiller hors du serveur.

Un autre contrôle pose souvent problème. La plupart des fournisseurs exécutent un firewall réseau dans le panneau de contrôle, séparément d’ufw sur le serveur. Un port peut être ouvert dans ufw tout en étant bloqué avant de vous atteindre.

L’adresse du serveur dont vos clients ont besoin

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

Cette chaîne constitue toute la configuration côté client. Collez-la dans les paramètres du serveur de l’application, ou faites-la scanner par quelqu’un avec le QR code affiché par l’application. La documentation précise que le QR code contient le mot de passe. Une personne qui le scanne peut donc aussi recevoir des messages via votre serveur.

Un comportement documenté surprend tout le monde. Ajouter votre serveur dans l’application ne concerne que les contacts que vous créez à partir de ce moment. Les contacts existants restent sur les relais où leurs files d’attente ont été créées et ne migrent pas. C’est aussi pourquoi vous ne pouvez pas désactiver un relais le lendemain de son remplacement.

Ajout d’un file relay XFTP

XFTP (SimpleX file transfer protocol) est la partie transfert de fichiers du réseau. Il s’agit d’un daemon distinct avec sa propre adresse. Selon l’annonce XFTP du projet, les relays ne disposent d’aucune métadonnée de fichier : ils voient des chunks individuels de 256kb, 1mb ou 4mb, dont l’accès est autorisé par des identifiants anonymes. Un émetteur peut répartir les chunks d’un même fichier sur plusieurs relays. Votre serveur stocke donc des morceaux, pas des fichiers.

sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"

Sa configuration se trouve dans /etc/opt/simplex-xftp/, son état dans /var/opt/simplex-xftp/ et les chunks de fichiers dans le chemin indiqué par -p. L’unité systemd suit la même structure avec User=xftp et ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS. Init affiche une adresse xftp:// au même format que celle de SMP, avec son propre fingerprint dans /etc/opt/simplex-xftp/fingerprint.

Il faut prévoir un conflit de ports. Le port documenté du serveur XFTP est 443, et la configuration SMP indique également 443. Deux processus ne peuvent pas écouter sur le même port et la même adresse. Sur un même VPS, il faut donc choisir une solution. La plus simple consiste à définir port: 5223 dans la section [TRANSPORT] de SMP et à laisser le port 443 au file relay. En contrepartie, les clients situés sur des réseaux restrictifs ne pourront plus utiliser le fallback sur 443. Les autres solutions sont d’ajouter une deuxième adresse IP au même VPS ou d’utiliser un deuxième VPS.

Définissez la quota en fonction de l’espace réellement disponible. -q '20gb' correspond à un engagement sur l’espace disque dont vous disposez. Le file relay est le composant qui consomme le plus d’espace disque et de bande passante. Le message relay consomme très peu des deux.

Ce qui est stocké sur le disque et ce qu’une sauvegarde restaure

Deux répertoires sont importants. /etc/opt/simplex/ contient l’identité : smp-server.ini, le certificat et la clé du serveur, ca.key et fingerprint. /var/opt/simplex/ contient l’état : smp-server-store.log contient les files d’attente et, lorsque restore_messages: on, les messages non remis, ainsi que le fichier de statistiques quotidien.

sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-server

Il faut bien comprendre ce que contient cette archive. Ce n’est pas une archive de messages : les éléments en file d’attente sont chiffrés avec des clés que le relay n’a jamais détenues, et la configuration [STORE_LOG] fournie avec le logiciel supprime de toute façon les messages après 21 jours. Il s’agit d’une copie de l’identité du serveur, avec notamment ca.key. Toute personne qui récupère ce fichier peut se faire passer pour votre relay auprès de vos contacts. Chiffrez-le et conservez-le hors du serveur.

L’intérêt se voit lors de la restauration. Remettez /etc/opt/simplex sur un VPS neuf, faites pointer le même nom DNS vers celui-ci : l’empreinte reste alors inchangée et toutes les adresses que vous avez distribuées continuent de fonctionner. Si vous perdez ce répertoire, aucune récupération n’est possible : une nouvelle installation crée une nouvelle empreinte, donc une nouvelle adresse, et tous les contacts qui passaient par votre relay sont perdus.

TLS : deux certificats avec des rôles différents

Le transport SMP n’utilise pas d’autorité de certification publique. Init génère une autorité privée et un certificat serveur, puis l’empreinte de cette autorité est incluse dans l’adresse du serveur. Le client compare ce que présente le serveur à cette empreinte enregistrée. C’est ce que le projet décrit comme la protection de la connexion client-serveur contre les attaques de type machine-in-the-middle. Aucun client ACME (automatic certificate management environment) ne doit être exécuté sur ce port. La rotation s’effectue manuellement avec smp-server cert et SMP_SERVER_CFG_PATH défini.

La page d’information facultative utilise l’autre certificat. Sa section [WEB] nomme static_path, https: 443, cert: /etc/opt/simplex/web.crt et key: /etc/opt/simplex/web.key. Un navigateur ne connaît pas votre autorité privée. C’est donc ici qu’un certificat approuvé publiquement est nécessaire. Le guide de démarrage rapide Docker place Caddy devant le serveur précisément pour cela et délivre automatiquement le certificat.

Accéder au relais via Tor

La documentation comprend une section consacrée à Tor. Elle installe Tor depuis le dépôt du projet Tor et ajoute un service onion dans /etc/tor/torrc :

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

Lisez attentivement les deux lignes de mode. « Single hop » et « non-anonymous » signifient que l’emplacement du relais n’est pas masqué. L’adresse onion est rapide et permet aux clients de se connecter sans jamais vous révéler leur adresse IP. En revanche, le serveur reste identifiable via son adresse IP publique. Le nom d’hôte onion fourni par /var/lib/tor/simplex-smp/hostname se place à la fin de l’adresse du serveur, après une virgule. Si vous voulez également masquer l’emplacement du serveur, il s’agit d’une autre configuration. La section exécuter un véritable service onion sur un VPS en présente les compromis. La différence entre les éléments masqués par chaque outil est expliquée dans Tor comparé à un VPN. Elle s’applique directement ici.

Modèle de menace : ce que l’auto-hébergement change

Ce que cela vous apporte. Les métadonnées — files d’attente existantes, moment de leur lecture, adresses qui se connectent — se trouvent sur une machine que vous contrôlez, et vous définissez la durée de leur conservation. Vous ne faites pas non plus partie d’un vaste ensemble de données pouvant être requis en une seule fois.

Ce que cela ne vous apporte pas, clairement :

• Le chiffrement ne change pas. Les messages étaient chiffrés de bout en bout avant que vous mettiez ce système en place, et ils le restent après. L’auto-hébergement concerne les métadonnées, pas la cryptographie.
• Votre fournisseur de VPS voit le trafic vers votre adresse IP et conserve vos informations de facturation. Vous avez déplacé la confiance d’un opérateur de messagerie vers un opérateur d’hébergement. Vous ne l’avez pas supprimée.
• Votre relay forme un groupe restreint. S’il ne sert qu’un foyer, une connexion à ce relay identifie ce foyer, et son nom d’hôte figure dans chaque lien d’invitation que vous envoyez depuis celui-ci. Un relay public très utilisé vous dissimule mieux sur ce point, et c’est le véritable compromis.
• La disponibilité dépend désormais de vous. Un disque plein ou une machine hors service empêchent la distribution des messages, et vos contacts ne peuvent pas contourner votre relay.

Le même raisonnement s’applique à tout service privé que vous installez sur une machine qui vous appartient, qu’il s’agisse de ce relay ou de un VPN WireGuard sur votre propre VPS. Vous choisissez quelle partie voit les métadonnées. Vous ne les faites pas disparaître.

Quand cela ne fonctionne pas

Le service démarre puis s’arrête immédiatement. Consultez sudo journalctl -u smp-server -n 50. Une erreur de bind indique le port qu’il n’a pas pu utiliser. Exécutez ensuite sudo ss -tlnp | grep :443 pour voir quel processus l’occupe déjà. Sur un serveur fraîchement installé, il s’agit généralement de nginx, de Caddy ou du serveur XFTP que vous avez installé il y a une heure.

Init ne peut pas écrire sa configuration. L’exécution de smp-server init avec l’utilisateur smp avant la création de /etc/opt/simplex provoque une erreur de permissions, car /etc/opt appartient à root. Créez d’abord le répertoire avec le propriétaire approprié, puis relancez init.

Les clients ne peuvent pas atteindre le relay. Vérifiez que le nom se résout vers la bonne adresse avec dig +short smp1.example.com. Testez ensuite le port depuis votre ordinateur portable, et non depuis le serveur : nc -vz smp1.example.com 5223. Si la connexion échoue depuis l’extérieur alors que ss indique que le socket est ouvert sur le serveur, le problème vient probablement du firewall réseau du fournisseur. Il s’agit d’un contrôle distinct de ufw.

Un contact ne peut pas se connecter via votre relay. L’empreinte dans l’adresse que vous avez partagée doit correspondre au contenu actuel de /etc/opt/simplex/fingerprint. Si vous avez défini create_password dans [AUTH], l’adresse doit également contenir ce mot de passe. Sinon, le client n’est pas autorisé à créer une queue.

Rien n’a été transféré après l’ajout du serveur dans l’application. C’est le comportement attendu. Seuls les nouveaux contacts utilisent le relay nouvellement ajouté. Les contacts existants conservent les queues qu’ils possèdent déjà.

FAQ

Un héberger soi-même un serveur SimpleX rend-il mes messages plus sécurisés ?

Non, et c’est volontaire. SimpleX chiffre les messages de bout en bout entre les appareils. Le relay ne possède donc jamais les clés, quel que soit son opérateur. L’auto-hébergement change les personnes qui peuvent observer les métadonnées associées à ces messages : les files qui existent, le moment où elles sont lues et les adresses IP qui s’y connectent. C’est un choix concernant les métadonnées. Si vous vous auto-hébergez pour obtenir un chiffrement plus robuste, le chiffrement était déjà présent.

Que peut réellement voir l’opérateur d’un relay SimpleX ?

Le protocol/security.md du projet le précise. Un relay ne peut pas lire le contenu ni le type des messages, modifier des messages individuels sans être détecté, ni casser le chiffrement de bout en bout au moyen d’une attaque active. Il peut voir si le destinataire d’une file est en ligne, compter les messages qui transitent par une file, connaître l’adresse IP d’un destinataire, supprimer les futurs messages d’une file ou mentir sur l’état de cette file. Ce sont les possibilités dont vous disposez une fois que le relay vous appartient.

Ai-je besoin d’un nom de domaine et d’un certificat TLS ?

Vous avez besoin d’un domaine pour disposer d’une configuration utilisable, et smp-server init accepte --ip si vous n’en avez réellement aucun. Vous n’avez pas besoin d’un certificat délivré par une autorité publique pour le port de messagerie : init génère sa propre autorité, et le client vérifie l’empreinte indiquée dans votre adresse smp://. Un certificat approuvé publiquement est uniquement nécessaire pour la page web d’information facultative, configurée avec cert et key dans la section [WEB] de smp-server.ini.

Que se passe-t-il si je perds /etc/opt/simplex ?

Toutes les adresses que vous avez distribuées cessent de fonctionner. Ce répertoire contient l’autorité de certification dont l’empreinte est intégrée à l’adresse de votre serveur. Une reconstruction produit donc une empreinte différente et, par conséquent, un serveur différent. Les contacts dont les files se trouvent sur ce relay ne peuvent pas être rétablis côté client. Sauvegardez le répertoire sous forme chiffrée, hors de ce serveur, et stockez ca.key hors ligne comme l’indique la documentation, car toute personne qui le détient peut usurper l’identité de votre relay.

Puis-je exécuter le relay SMP et le relay de fichiers XFTP sur le même VPS ?

Oui, mais il faut régler un conflit. Le port documenté du serveur XFTP est 443 et la configuration SMP par défaut contient port: 5223,443. Les deux services veulent donc utiliser le même socket. Attribuez le port 443 à l’un des deux : définissez port: 5223 pour le serveur SMP, ou déplacez le relay de fichiers vers une seconde adresse IP ou un second VPS. Dimensionnez également le quota de stockage en fonction de l’espace disque réellement disponible, car le relay de fichiers est le composant qui consomme du disque et de la bande passante.