Auto-héberger Relayium : gérez votre serveur de transfert de fichiers et de texte

Dernière mise à jour: 2026-08-06

Relayium est sous licence AGPL-3.0 et open source, et le serveur est une image unique et autonome — pas de base de données externe, pas de bucket de stockage tiers, rien à quoi s'inscrire. Si vous préférez tout faire tourner vous-même plutôt que dépendre de relayium.com, ce guide vous fait monter un serveur avec Docker et paramètre la CLI pour qu'elle s'y connecte.

S'auto-héberger vous donne un contrôle total sur l'emplacement de vos données, votre propre domaine et certificat TLS, et aucune dépendance aux décisions opérationnelles de quelqu'un d'autre. Tout ce qui suit s'appuie sur des fichiers réellement présents dans le dépôt — docker-compose.yml, server/.env.example et docs/self-hosting.md — donc rien ici n'est un indicateur ou un réglage qui n'existe pas réellement.

Pourquoi s'auto-héberger

Les transferts en temps réel de Relayium sont chiffrés de bout en bout. Un relais TURN auto-hébergé peut transporter des octets chiffrés et le serveur traite des métadonnées de signalisation, mais aucun des deux ne peut lire ni déchiffrer le contenu en clair des fichiers ; ni le serveur ni le relais ne stockent de copie ou d'historique côté serveur du contenu en temps réel. Le serveur conserve toutefois votre compte et — pour les transferts stockés/basés sur un lien — des blobs chiffrés ainsi qu'une petite base SQLite. S'auto-héberger signifie que ces données vivent sur une infrastructure que vous contrôlez, sous votre propre domaine, sans que les décisions opérationnelles de quelqu'un d'autre n'interviennent.

Le projet étant sous licence AGPL-3.0 et open source (github.com/relayium/relayium), vous pouvez lire exactement ce que fait le serveur avant de lui confier quoi que ce soit, et le forker ou le modifier librement.

Démarrage rapide avec Docker

Ce qu'il vous faut avant l'étape 1

Une machine avec Docker Engine et le plugin Compose. docker compose version affiche un numéro de version ; « docker: 'compose' is not a docker command » signifie que le plugin manque.
Un clone du dépôt. Le fichier compose construit l'image à partir de cet arbre de sources, il lui faut donc le Dockerfile et web/ à côté de lui — il n'existe aucune image précompilée à télécharger.
De l'espace disque pour le volume nommé relayium-data : la base SQLite plus le chiffré des transferts stockés que vous conservez.
Un domaine et un proxy inverse terminant TLS si quelqu'un d'autre que vous doit l'utiliser. Le conteneur ne parle qu'en HTTP clair et ne publie par défaut que sur l'interface de bouclage.
Rien d'autre. Aucune base de données externe, aucun bucket de stockage objet, aucun compte tiers.

La racine du dépôt fournit un Dockerfile et un docker-compose.yml qui construisent une seule image autonome — un binaire Go statique servant l'application web précompilée, donc aucun Node, aucune chaîne d'outils Go ni aucun nginx séparé n'est requis juste pour le faire tourner.

Clonez le dépôt et placez-vous dedans.

git clone https://github.com/relayium/relayium.git

cd relayium

Construisez et démarrez. Le secret de remplacement reste obligatoire même quand le relais est éteint : Compose valide la variable requise du service coturn désactivé par profil au moment où il analyse le fichier, si bien qu'un docker compose up nu refuse de démarrer.
```
RELAYIUM_TURN_SECRET=placeholder docker compose up -d --build
```
Vérifiez que le conteneur est bien resté en vie plutôt que de redémarrer en boucle.
```
docker compose ps
```
Demandez à l'instance si elle peut réellement servir. Utilisez /readyz, pas /healthz — la différence entre les deux est tout l'intérêt de cette vérification, et l'encadré de résultat attendu ci-dessous explique pourquoi.
```
curl -s http://127.0.0.1:8080/readyz
```
Copiez le modèle de configuration et renseignez votre URL publique. RELAYIUM_BASE_URL construit les liens des courriels sortants et décide si les cookies de session portent l'attribut Secure : ce doit donc être votre véritable adresse https://.
```
cp server/.env.example server/.env
```
```
chmod 600 server/.env
```
Placez nginx ou Caddy devant, terminant TLS pour votre domaine et relayant tout — /, /api, /ws, /admin — vers le port 8080. Redémarrez ensuite pour prendre en compte server/.env.
```
docker compose up -d
```

À quoi ressemble une instance qui fonctionne

Le conteneur affiche Up et les deux points d'entrée répondent. C'est ready qui compte : /healthz renvoie ok sans condition, avant même que quoi que ce soit ne soit ouvert, et passe donc aussi sur une instance dont la base ou le répertoire de blobs est inutilisable. /readyz interroge la base SQLite et le répertoire de blobs, et répond 503 dès que l'un des deux est cassé.

$ docker compose ps
NAME                IMAGE                     STATUS          PORTS
relayium-server-1   relayium/relayium:local   Up 12 seconds   127.0.0.1:8080->8080/tcp

$ curl -s http://127.0.0.1:8080/healthz
ok
$ curl -s http://127.0.0.1:8080/readyz
ready

C'est tout le serveur, à l'écoute sur :8080. En production, placez nginx ou Caddy devant pour le TLS — docs/self-hosting.md couvre le chemin Docker et ce qu'il faut proxyfier ; la configuration nginx de production propre à Relayium n'est pas publiée.
La configuration de l'appli provient d'un fichier server/.env optionnel plus le bloc environment: dans docker-compose.yml. Chaque réglage a une clé RELAYIUM_* correspondante — copiez server/.env.example comme point de départ.
Les quatre clés qui comptent pour un déploiement de base : RELAYIUM_ADDR (adresse d'écoute), RELAYIUM_STATIC (chemin vers l'application web compilée), RELAYIUM_DB (chemin du fichier SQLite) et RELAYIUM_BLOB_DIR (où est écrit le texte chiffré des liens stockés). docker-compose.yml définit déjà des valeurs par défaut raisonnables pour ces quatre clés et les persiste dans un volume nommé.

Ajouter un relais TURN pour les transferts entre réseaux

Les transferts sur le même réseau (LAN) et le push/pull basé sur SSH fonctionnent sans rien de plus. Les transferts en temps réel entre réseaux différents (deux appareils derrière des NAT différents) nécessitent parfois un relais TURN pour établir un chemin — le relais ne voit jamais que du texte chiffré, jamais le contenu de vos fichiers.

docker-compose.yml a un profil relay optionnel qui démarre coturn (le serveur TURN) et une petite instance Redis pour la mesure des octets relayés, aux côtés du serveur principal :

Le secret doit parvenir à deux endroits différents, et se tromper échoue sans le moindre bruit. coturn le reçoit par la substitution de variables de Compose, qui ne se résout que depuis le shell ou un .env à la racine du projet. Le serveur, lui, le lit dans son propre environnement — c'est-à-dire server/.env — et un secret vide désactive purement et simplement TURN. Si vous n'en renseignez qu'un seul, vous obtenez un coturn qui tourne mais pour lequel le serveur n'émet jamais d'identifiants : tous les conteneurs se déclarent sains, rien n'est journalisé, et les transferts à travers les NAT stricts continuent d'échouer exactement comme avant.

Générez un seul secret aléatoire suffisamment long. C'est la même valeur partout ci-dessous.
```
openssl rand -hex 32
```
Inscrivez ce secret, ainsi que les adresses de relais vers lesquelles votre domaine pointe, dans server/.env : c'est ce qui active TURN côté serveur.
```
RELAYIUM_TURN_SECRET=<the value from step 1>
RELAYIUM_TURN_URLS=turn:example.com:3478,turns:example.com:5349
```
Exportez ce même fichier dans le shell pour que la substitution de Compose puisse remettre à coturn un secret identique. Le sourcer conserve une source unique et garde le secret hors de la ligne de commande, où ps l'exposerait.
```
set -a; . ./server/.env; set +a
```

Démarrez la pile avec le profil relay.

docker compose --profile relay up -d --build

Ouvrez les ports de relais sur le pare-feu de l'hôte. coturn tourne en réseau hôte, ce sont donc des règles de l'hôte et non de Docker : UDP 3478 et 49152-65535, TCP 3478 et 5349.
Vérifiez que le serveur — et pas seulement coturn — a démarré avec le secret. C'est cette vérification qui attrape le cas silencieux.
```
docker compose exec server env | grep RELAYIUM_TURN
```

À quoi ressemble un relais qui fonctionne

Les deux clés reviennent non vides depuis l'intérieur du conteneur serveur. Que coturn tourne ne prouve rien en soi — le navigateur ne reçoit jamais que des identifiants de relais émis par le serveur.

$ docker compose exec server env | grep RELAYIUM_TURN
RELAYIUM_TURN_SECRET=3f7a…
RELAYIUM_TURN_URLS=turn:example.com:3478,turns:example.com:5349

coturn a besoin de la véritable IP publique de l'hôte et d'une plage de ports UDP ouverte pour fonctionner — docs/self-hosting.md couvre le démarrage via le profil relay de Docker ; la configuration coturn de production propre à Relayium (y compris son script d'installation) n'est pas publiée.
Sans --profile relay ni RELAYIUM_TURN_SECRET, le serveur fonctionne quand même parfaitement — les transferts entre réseaux différents basculent simplement sur STUN seul, ce qui fonctionne pour les NAT les plus simples mais pas pour les plus stricts.

Installez la CLI sur votre machine

Cette dernière étape exécute la CLI relayium sur votre propre ordinateur (pas le serveur), alors installez-la là si ce n'est pas fait. Sous macOS ou Linux :

curl -fsSL https://relayium.com/install.sh | sh

relayium.com/cli liste toutes les options — un binaire Windows, la page des releases, ou go build si vous avez Go.
relayium --version le confirme. Sans la CLI, la commande ci-dessous affiche « command not found ».

Paramétrer la CLI pour votre serveur

Par défaut, la CLI Relayium utilise le serveur de rendez-vous de relayium.com pour send/receive et text entre réseaux différents. Passez --server pour utiliser le vôtre à la place :

Sur une machine qui dispose déjà de la CLI grâce à la section précédente, connectez-vous à votre serveur plutôt qu'à relayium.com. Une URL et un code s'affichent ; approuvez-les dans un navigateur connecté à votre instance.
```
relayium login --server https://your-domain
```
Vérifiez à quel serveur les identifiants enregistrés sont rattachés. whoami ne prend aucune option — il rapporte ce que la connexion a réellement écrit, et c'est précisément ce qui rend la commande utile.
```
relayium whoami
```
Passez le même --server à l'envoi. Sans lui, la CLI génère le code d'appairage sur relayium.com et l'autre extrémité ne le trouvera jamais sur votre instance.
```
relayium send ./report.pdf --server https://your-domain
```

Recevez sur l'autre machine avec le code affiché et le même --server. Les sessions de texte fonctionnent de la même façon.

relayium receive 483920 --server https://your-domain

relayium text --server https://your-domain

relayium text 483920 --server https://your-domain

Comment savoir qu'elle parle bien à votre instance

whoami affiche le compte, suivi entre parenthèses du serveur auquel il est rattaché. Votre propre domaine à cet endroit — et non relayium.com — vaut confirmation.

$ relayium login --server https://your-domain
Open https://your-domain/device and enter code: WDJB-MJHT
logged in as you@example.com

$ relayium whoami
you@example.com (https://your-domain)

Quel que soit le serveur utilisé, la CLI est gratuite — --server ne change que le serveur de rendez-vous. send ou text sans code y génèrent un code, et up y stocke sous un compte ; connectez-vous donc d'abord avec relayium login --server https://your-domain. receive, down et text avec le code affiché ne nécessitent aucune connexion.
Les deux extrémités de text doivent rester en ligne. Les messages utilisent leur propre session P2P directe chiffrée de bout en bout. Le text de la CLI est exclusivement direct et n'utilise pas le relais TURN de l'appli web. Ni Relayium ni votre serveur auto-hébergé ne stockent le corps des messages ou un historique côté serveur, mais chaque terminal ou destinataire peut copier ou conserver le texte après réception.
push/pull (via votre propre SSH) ainsi que serve + le push daemon-direct relayium://host ne touchent jamais relayium.com, auto-hébergé ou non — ils se connectent directement à la machine distante que vous indiquez.

Quand ça ne marche pas

Cinq pannes couvrent presque tous les auto-hébergements ratés. Chacune se tranche par une ligne à lire ou une commande à exécuter, et trois d'entre elles ressemblent à une réussite tant que vous n'avez pas lancé la vérification.

Symptôme, vérification, correction

docker compose up refuse tout net de démarrer, avant même que quoi que ce soit ne soit construit.

docker compose up -d --build
# required variable RELAYIUM_TURN_SECRET is missing a value

Compose substitue les variables de tout le fichier avant de filtrer par profil : la variable requise du service coturn désactivé est donc validée même quand le relais est éteint. Préfixez n'importe quelle valeur de remplacement — RELAYIUM_TURN_SECRET=placeholder docker compose up -d --build — et ne la remplacez par un vrai secret qu'au moment où vous activez réellement le profil relay.

Le conteneur est Up, mais un navigateur sur une autre machine n'y accède pas.

docker compose ps
# PORTS  127.0.0.1:8080->8080/tcp

Cette liaison sur la boucle locale est le comportement par défaut, pour qu'un hôte public n'expose pas du HTTP en clair à Internet. En production, laissez-la et terminez TLS dans un proxy inverse sur le même hôte. Pour une machine purement LAN sans proxy, publiez plus largement avec RELAYIUM_BIND=0.0.0.0 docker compose up -d — cette variable est lue par compose, pas par le serveur.

/healthz répond ok, mais l'inscription échoue et les liens stockés n'apparaissent jamais.

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/readyz
# 503

/healthz renvoie ok sans condition et ne prouve que l'écoute du processus. /readyz interroge la base SQLite et le répertoire de blobs : un 503 signifie donc que l'un des deux est inutilisable — vérifiez que le volume relayium-data est monté et que RELAYIUM_DB et RELAYIUM_BLOB_DIR pointent à l'intérieur.

relayium login affiche une URL de vérification sur localhost, que vous ne pouvez pas ouvrir.

relayium login --server https://your-domain
# Open http://localhost:8080/device and enter code: WDJB-MJHT

Le serveur construit cette URL à partir de RELAYIUM_BASE_URL, dont la valeur par défaut est http://localhost:8080. Renseignez votre véritable adresse https:// dans server/.env, puis redémarrez. Elle décide aussi si les cookies de session portent l'attribut Secure : la laisser fausse n'est donc pas qu'un détail d'apparence.

coturn tourne, mais les transferts entre réseaux à travers un NAT strict échouent toujours — sans rien dans les journaux.

docker compose exec server env | grep RELAYIUM_TURN
# aucune sortie

Le secret a atteint coturn par la substitution de Compose mais n'est jamais parvenu au serveur, dont le secret vide désactive complètement TURN. Inscrivez RELAYIUM_TURN_SECRET et RELAYIUM_TURN_URLS dans server/.env, sourcez-le dans le shell comme à l'étape 3 ci-dessus pour que la substitution voie la même valeur, puis redémarrez le profil relay. Les deux clés doivent revenir non vides à cette vérification.

Questions fréquentes

Dois-je configurer TURN ?

Seulement si vous voulez que les transferts en temps réel entre réseaux différents fonctionnent à travers des NAT stricts. Les transferts sur le même réseau, le push/pull basé sur SSH et le daemon-direct fonctionnent tous sans TURN — TURN sert uniquement au NAT traversal sur le chemin du code d'appairage entre réseaux différents.

La CLI reste-t-elle gratuite si je m'auto-héberge ?

Oui. La CLI reste gratuite avec relayium.com comme avec votre serveur. Un compte sur le serveur visé est requis par send ou text sans code pour en générer un, et par up pour stocker un fichier. receive, down et text avec le code affiché ne nécessitent aucune connexion.

Puis-je utiliser mon propre domaine et mon propre certificat TLS ?

Oui. L'image Docker écoute elle-même en HTTP simple sur :8080 ; placez nginx ou Caddy devant avec votre propre domaine et votre certificat (par exemple via certbot/Let's Encrypt). docs/self-hosting.md couvre ce qu'il faut proxyfier ; la configuration nginx de production propre à Relayium n'est pas publiée, il faudra écrire la vôtre.

Quelles données mon serveur auto-hébergé stocke-t-il ?

Une base SQLite (comptes, sessions) sous RELAYIUM_DB et, pour les transferts stockés/basés sur un lien, des blobs chiffrés sous RELAYIUM_BLOB_DIR que le serveur lui-même ne peut pas déchiffrer. Le serveur ne conserve aucun fichier ni corps de message en temps réel et ne fait que relayer la poignée de main de signalisation ; les appareils destinataires peuvent néanmoins garder les fichiers ou le texte.

Installez la CLI Relayium gratuite et faites-la pointer vers votre propre serveur avec --server.

Obtenir la CLI