Héberger son serveur SimpleX sur un VPS

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

Pour auto-héberger un serveur SimpleX, vous exécutez un daemon sur un VPS : smp-server, le relais SMP (simplex messaging protocol). Il conserve les files de messages dans lesquelles vos contacts écrivent et qu’ils lisent. 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, et non à l’utilisateur de l’application. Le relais ne conserve ni comptes, ni listes de contacts, ni historique des conversations. Il conserve des files, des données chiffrées non distribuées et un certificat qui l’identifie. Vous devez assurer la disponibilité du service, prévoir un peu d’espace disque et prendre en compte les métadonnées qui transitent par votre serveur.

Chaque commande, chemin, port et flag 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 d’origine est indiquée à côté.

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

SimpleX n’utilise ni noms d’utilisateur, ni numéros de téléphone, ni identifiants de compte. Un contact est une queue unidirectionnelle : une adresse sur un relay, vers laquelle un côté écrit et depuis laquelle l’autre lit. Deux de vos contacts ne partagent aucun identifiant qu’un serveur pourrait recouper.

Ces queues 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 tout le rôle d’un SMP relay. Cela signifie aussi que les deux appareils ne se connectent jamais directement l’un à l’autre. Aucun ne découvre donc l’adresse IP (internet protocol) de l’autre. Le relay prend cette exposition en charge.

Le hostname du relay fait partie de l’adresse de la queue. Il figure donc dans chaque lien d’invitation que vous distribuez depuis ce relay. Gardez-le à l’esprit lorsque vous lirez le modèle de menace vers la fin.

Ce qu’un relay peut voir ou non

Le projet présente ce modèle de menace dans protocol/security.md. Il est utile de le lire avant toute installation, car ce relay sera ensuite sous votre contrôle. Même entièrement contrôlé par un attaquant, un relay ne peut pas connaître le contenu ni le type des messages. Il ne peut pas ajouter, dupliquer ou altérer des messages individuels sans être détecté. Il ne peut pas non plus casser le chiffrement de bout en bout au moyen d’une attaque active.

La même page indique ce qu’un relay peut faire. Il peut savoir quand un destinataire de 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 relay, et l’auto-hébergement vous en confie la responsabilité.

Ce qu’il vous faut avant de commencer

• Un VPS sous Ubuntu 22.04 ou 24.04. Le projet publie des binaires de version compilés exactement pour ces deux versions, en x86-64 et 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 que vous modifiez le firewall.
• Un emplacement hors du serveur pour stocker une sauvegarde, car le répertoire de configuration constitue l’identité du serveur.

Sur une instance ARM, utilisez l’artefact 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 précise, pas « latest »

Le projet fournit un script d’installation qui récupère la version actuelle et enregistre une commande simplex-servers-update. Cela fonctionne. Épinglez tout de même la version : si le binaire d’un relais change sans que vous le contrôliez, vous ne pouvez plus analyser correctement les problèmes lorsqu’ils surviennent.

En août 2026, la version actuelle de simplexmq est v6.5.0, publiée le 29 avril 2026. Consultez la page des versions 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 peut donc se connecter directement en tant que smp. Créez vous-même les deux répertoires avant toute autre commande, 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 versions 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 en tant que smp. Ainsi, une compromission du service ne peut pas réécrire le binaire qu’il lance.

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 des queues en mode append-only dans /var/opt/simplex/smp-server-store.log, afin que le relay survive à un redémarrage. Sans ce fichier, un redémarrage supprime toutes les queues, ce qui interrompt le fonctionnement de chaque contact routé par votre serveur.
• --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 --ip si vous n’avez pas de domaine.
• --no-password permet à n’importe qui de créer une queue sur votre relay. 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 du shell et dans la liste des processus pendant son exécution.

L’initialisation génère un certificat et affiche les deux valeurs à 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. La documentation vous demande de déplacer ce fichier vers un stockage hors ligne. La raison est importante : les clients épinglent 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 étant le vôtre. Vous n’aurez besoin de le remettre en ligne que pour renouveler ultérieurement le certificat serveur avec smp-server cert.

Considérez l’initialisation comme une étape unique. L’empreinte présente dans votre adresse provient de l’autorité qu’elle génère. Si vous régénérez cette autorité, vous obtenez une adresse différente et l’adresse que vous avez communiquée ne fonctionnera 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 en amont 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 sont fermés aux processus autres que root. Sans cette ligne, le daemon ne peut pas écouter sur les ports 80 ou 443. Ajoutez-la si vous exposez ces ports. LimitNOFILE=65535 est important, car chaque client abonné conserve une connexion TCP ouverte et que la limite par défaut est très inférieure à ce dont un relais actif a besoin. ExecStopPost copie le journal du store dans un fichier .bak à chaque arrêt. Vous disposez ainsi d’un point de restauration 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 la même pratique que celle décrite dans les comptes dédiés à chaque service sur un VPS. Cela empêche qu’un bug dans un daemon réseau se transforme en 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 aussi 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ébutez avec cet outil, les bases d’ufw sur un VPS expliquent l’ordre des règles et comment éviter de vous verrouiller l’accès.

Un autre contrôle pose souvent problème. La plupart des fournisseurs exécutent un firewall réseau dans le panneau de gestion, séparément d’ufw sur le serveur. Un port peut être ouvert dans ufw, mais être quand même 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 une personne avec le code QR affiché par l’application. La documentation précise que le QR code contient le mot de passe. Toute personne qui le scanne peut donc aussi recevoir des messages via votre serveur.

Un comportement documenté surprend tout le monde. L’ajout de votre serveur dans l’application ne concerne que les contacts créés à 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 relais de fichiers XFTP

XFTP (protocole de transfert de fichiers SimpleX) constitue la partie fichiers du réseau. Il s’agit d’un daemon distinct, avec sa propre adresse. Selon l’annonce XFTP du projet, les relais 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. L’expéditeur peut répartir les chunks d’un même fichier sur plusieurs relais. Votre serveur stocke donc des fragments, 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 anticiper un conflit de port. Le port documenté du serveur XFTP est 443, et la configuration SMP utilise également 443. Deux processus ne peuvent pas écouter sur le même port et la même adresse. Sur un seul VPS, il faut donc modifier l’un des deux services. La solution la plus simple consiste à définir port: 5223 dans la section [TRANSPORT] de SMP et à réserver 443 au relais de fichiers. 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 le quota de manière réaliste. -q '20gb' correspond à l’espace disque dont vous disposez réellement. Le relais de fichiers est le composant qui consomme le plus de disque et de bande passante. Le relais de messages utilise très peu de ces deux ressources.

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 distribués, ainsi que le fichier des statistiques quotidiennes.

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

Sachez précisément ce que contient cette archive. Ce n’est pas une archive de messages : les éléments en file d’attente sont des textes chiffrés avec des clés que le relais 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, y compris ca.key. Toute personne qui récupère ce fichier peut se présenter comme votre relais auprès de vos contacts. Chiffrez-le et conservez-le hors du serveur.

L’intérêt est la restauration. Replacez /etc/opt/simplex sur un nouveau VPS et pointez le même nom DNS vers celui-ci : l’empreinte reste inchangée, donc 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 produit une nouvelle empreinte, donc une nouvelle adresse, et tous les contacts qui passaient par votre relais 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. L’empreinte de cette autorité est incluse dans l’adresse du serveur. Le client compare ce que le serveur présente à cette empreinte enregistrée. C’est ce que le projet décrit comme une 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] indique 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 le seul endroit où un certificat approuvé publiquement est nécessaire. Le démarrage rapide Docker de la documentation place Caddy devant le serveur précisément pour cela et émet automatiquement le certificat.

Accéder au relay via Tor

La documentation contient une section consacrée à Tor. Elle installe Tor depuis le dépôt du Tor Project et ajoute un hidden service 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 relay lui-même 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, mais le serveur reste identifiable à son adresse IP publique. Le nom d’hôte onion indiqué 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 configuration différente. La section exécuter un véritable service onion sur un VPS présente ce compromis. La différence entre les éléments masqués par chaque outil est expliquée dans Tor comparé à un VPN, et 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 et adresses qui se connectent — se trouvent sur une machine que vous contrôlez. Vous définissez aussi la durée de leur conservation. Vous ne faites pas partie d’un vaste ensemble de données qui peut être demandé en une seule fois.

Ce que cela ne vous apporte pas, en termes clairs :

• 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 petit groupe. S’il ne dessert qu’un foyer, le fait de s’y connecter identifie ce foyer, et son nom d’hôte figure dans chaque lien d’invitation que vous envoyez depuis ce relay. Un relay public très utilisé vous dissimule mieux sur ce point précis. C’est le véritable compromis. Un serveur de recherche privé présente la même caractéristique. C’est pourquoi ce que SearXNG masque réellement sur votre propre VPS dépend du nombre de personnes qui partagent l’instance avec vous.
• La disponibilité dépend désormais de vous. Un disque plein ou une machine hors service interrompt la remise 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 d’un VPN WireGuard sur votre propre VPS. Vous choisissez quelle partie voit les métadonnées. Vous ne les faites pas disparaître.

Fonctionnement incorrect

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’utilise 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 permission, 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 joindre 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 du pare-feu 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 indiquée 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 bougé après l’ajout du serveur dans l’application. C’est le fonctionnement prévu. Seuls les nouveaux contacts utilisent le relay nouvellement ajouté. Les contacts existants conservent les queues qu’ils possèdent déjà.

FAQ

L’auto-hébergement d’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 relais ne possède donc jamais les clés, quel que soit son opérateur. L’auto-hébergement modifie les personnes qui peuvent observer les métadonnées associées à ces messages : les files d’attente existantes, le moment où elles sont lues et les adresses IP qui se connectent. Il s’agit d’un choix concernant les métadonnées. Si vous vous auto-hébergez pour obtenir un chiffrement plus robuste, ce chiffrement était déjà présent.

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

Le protocol/security.md du projet précise ces éléments. Un relais ne peut pas lire le contenu ou le type des messages, modifier des messages individuels sans être détecté ni compromettre le chiffrement de bout en bout par une attaque active. Il peut voir si le destinataire d’une file d’attente est en ligne, compter les messages qui transitent par une file, connaître l’adresse IP d’un destinataire, supprimer les prochains messages d’une file ou mentir sur l’état de cette file. Ce sont les pouvoirs dont vous disposez une fois que le relais 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 nécessaire uniquement 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 d’attente résident sur ce relais ne peuvent pas être rétablis depuis le client. Sauvegardez ce répertoire sous forme chiffrée, sur un autre système, et conservez ca.key hors ligne comme l’indique la documentation, car toute personne qui le détient peut usurper l’identité de votre relais.

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

Oui, mais vous devez résoudre un conflit. Le port documenté du serveur XFTP est 443 et la configuration SMP par défaut indique 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 relais de fichiers vers une deuxième adresse IP ou un deuxième VPS. Dimensionnez également le quota de stockage en fonction de l’espace disque réellement disponible, car le relais de fichiers est le composant qui consomme l’espace disque et la bande passante.