Faire tourner Relayium en service de réception permanent

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

relayium serve --once traite un seul transfert entrant puis s'arrête — parfait pour un pull occasionnel. Mais si vous voulez qu'une machine soit un point de dépôt permanent — un serveur domestique qui reçoit des sauvegardes chaque nuit, une machine de build vers laquelle la CI pousse des artefacts, un NAS auquel votre téléphone peut envoyer des photos à tout moment — vous voulez que serve tourne en continu, sans avoir à le démarrer à la main à chaque transfert.

Ce guide couvre le démarrage d'un processus à l'écoute de longue durée, l'approbation de qui est autorisé à envoyer, l'autorisation préalable des pairs pour les cas où personne n'est devant le terminal, l'exécution sous systemd, et le fait de laisser un émetteur utilisant sync --delete répercuter les suppressions.

Avant de commencer

Tout ci-dessous passe par la CLI relayium, alors installez-la d'abord si ce n'est pas fait. Sous macOS ou Linux, une commande place un binaire précompilé dans votre PATH :

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

Vous préférez choisir le fichier vous-même, ou sous Windows ? Récupérez un binaire depuis la page des releases — relayium.com/cli liste toutes les options (avec Go, go build -o relayium ./cmd/relayium).
relayium --version confirme l'installation. Sans cela, les commandes ci-dessous affichent seulement « command not found ».

Démarrer le processus à l'écoute

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

La CLI sur les deux machines. relayium version affiche un numéro de version sur chacune ; si le shell répond command not found, elle n'y est pas encore installée.
Un répertoire de réception sur cette machine, et l'espace disque pour ce qui va y atterrir.
Une adresse joignable par l'expéditeur et un port entrant ouvert. Sans --port, serve écoute sur 9031.
Si cette machine doit tourner sans terminal — et c'est tout l'intérêt d'un service — l'empreinte de l'expéditeur, à l'avance. Une section y est consacrée plus bas, et c'est de loin la première raison pour laquelle un récepteur permanent refuse tout.

serve écoute les envois en daemon-direct (relayium://host:port) via une connexion TLS 1.3 avec épinglage et écrit ce qu'il reçoit dans un répertoire. Rien n'a besoin d'être partagé au préalable pour le démarrer — aucune empreinte à copier, aucun serveur à enregistrer :

relayium serve --dir ~/inbox
relayium serve --dir /srv/drop --port 9040   # port autre que celui par défaut
relayium serve --dir ~/inbox --allow-delete  # laisser un émetteur sync --delete répercuter les suppressions

Choisissez où les fichiers doivent atterrir et démarrez l'écouteur. Rien n'a besoin d'être partagé au préalable pour en arriver là.
```
relayium serve --dir ~/inbox
```
Depuis la machine émettrice, poussez quelque chose vers cet hôte par son adresse relayium://.
```
relayium push ./report.pdf relayium://drop.example.com:9031
```
De retour sur le récepteur, répondez à la demande d'approbation. Un y écrit l'empreinte dans authorized_fingerprints, et les envois suivants de la même machine ne demandent plus rien.
Vérifiez que le fichier a bien atterri dans --dir et non dans le répertoire depuis lequel vous avez lancé serve.
```
ls -l ~/inbox
```

À quoi ressemble un écouteur qui fonctionne

serve annonce d'emblée qu'il n'a aucun pair autorisé, demande confirmation au premier envoi d'une machine inconnue, puis reste muet à chaque envoi suivant. L'expéditeur se termine avec 0 et le fichier est dans --dir.

$ relayium serve --dir ~/inbox
no authorized peers yet — you'll be asked to approve each new peer on its first push.
Incoming push from 203.0.113.7:54021
  fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y

--dir définit où les fichiers atterrissent (le répertoire courant par défaut).
--port définit le port d'écoute (9031 par défaut) ; ouvrez-le sur votre pare-feu si l'émetteur se trouve ailleurs.
Sans --once, serve continue de tourner et d'accepter des envois jusqu'à ce que vous l'arrêtiez ou qu'un gestionnaire de processus le redémarre — c'est ce qui en fait un service permanent.

Approuver qui est autorisé à envoyer

La première fois qu'un nouveau pair envoie quelque chose, serve — s'il tourne dans un terminal — vous montre d'où vient l'envoi et son empreinte, puis vous demande de l'approuver, de la même façon que SSH interroge sur un hôte inconnu à la première connexion :

Incoming push from 203.0.113.7:54021
  fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y

Répondez y une fois et cette empreinte est écrite dans authorized_fingerprints ; chaque envoi ultérieur depuis la même machine passe alors sans invite.
Une empreinte identifie une machine, pas une adresse réseau, donc elle reste valable même si l'IP de l'émetteur change.
Cette étape est interactive par conception — il faut quelqu'un devant le clavier, ce qui ne sera plus vrai une fois que serve passera sous systemd (section suivante).

Autoriser des pairs à l'avance pour les configurations non interactives

Quand serve n'a pas de terminal où demander confirmation — un service systemd, un processus en arrière-plan, un pipe — il ne peut pas interroger et refuse donc toute empreinte qu'il ne reconnaît pas encore. Autorisez plutôt les pairs à l'avance. Sur la machine qui va envoyer, exécutez relayium id pour afficher son empreinte ; sur le récepteur, ajoutez-la avant que le premier envoi n'arrive :

# sur la machine qui va envoyer, afficher son empreinte
relayium id

# sur ce récepteur permanent, l'autoriser à l'avance
relayium authorize 74318e3b...

Sur la machine qui poussera, affichez son empreinte. Ce sont 64 caractères hexadécimaux, et ils identifient la machine, pas son adresse.
```
relayium id
```
Autorisez-la sur ce récepteur — avec le même --config-dir que celui sous lequel tournera le service. Autoriser sous un autre utilisateur, ou dans le chemin par défaut alors que l'unité en utilise un autre, écrit l'empreinte dans un fichier que le service ne lit jamais.
```
relayium authorize 74318e3b… --config-dir /etc/relayium
```

authorize est idempotent — l'exécuter à nouveau pour une empreinte déjà approuvée ne fait rien.
Les fichiers d'identité et de confiance se trouvent dans le répertoire indiqué par --config-dir, ~/.config/relayium par défaut (id.key/id.crt sont l'identité de cet hôte, authorized_fingerprints est la liste d'autorisation des pairs).

Exécuter sous systemd

Pour un service qui survit aux redémarrages et aux plantages, confiez serve à systemd. Faites pointer --config-dir vers un chemin fixe pour que l'identité de l'hôte et sa liste de pairs autorisés restent stables d'un redémarrage à l'autre :

# /etc/systemd/system/relayium-serve.service
[Unit]
Description=Relayium always-on receiver
After=network-online.target

[Service]
ExecStart=/usr/local/bin/relayium serve --dir /srv/drop --port 9031 --config-dir /etc/relayium --allow-delete
Restart=always
User=relayium

[Install]
WantedBy=multi-user.target

Autorisez chaque pair censé pouvoir pousser, avant même que le service existe. Il ne peut rien demander, donc tout ce qui n'est pas déjà de confiance est refusé.
Écrivez l'unité ci-dessus dans /etc/systemd/system/relayium-serve.service, avec --config-dir pointant sur le chemin fixe utilisé pour l'autorisation.
Rechargez systemd et démarrez le service, en l'activant pour qu'il revienne après un redémarrage.
```
sudo systemctl daemon-reload
```
```
sudo systemctl enable --now relayium-serve
```
Vérifiez qu'il tourne et que l'avertissement qui refuse tout est absent du journal. Seule la seconde vérification est propre à cette installation.
```
systemctl is-active relayium-serve
```
```
journalctl -u relayium-serve -n 20 --no-pager
```

À quoi ressemble un service qui fonctionne

is-active répond active, et l'avertissement de démarrage sur l'absence de pairs autorisés n'apparaît pas. Cet avertissement est la seule ligne qui vous dit, avant qu'un expéditeur ne se plaigne, que ce service refusera chaque envoi.

$ systemctl is-active relayium-serve
active
$ journalctl -u relayium-serve -n 20 --no-pager | grep -c 'all pushes will be rejected'
0

Avant d'activer le service, exécutez relayium authorize <fingerprint> pour chaque pair qui doit pouvoir envoyer — le service lui-même ne peut pas demander confirmation.
systemctl enable --now relayium-serve le démarre et le fait redémarrer à chaque démarrage de la machine.
Gardez /etc/relayium/id.key lisible uniquement par l'utilisateur du service ; relayium refuse de charger une clé aux permissions trop permissives.

Le lancer au démarrage sous macOS (launchd)

macOS n'a pas de systemd — son gestionnaire de services est launchd. Pour maintenir serve en fonctionnement sur un Mac (par exemple un Mac mini laissé allumé comme point de dépôt), installez-le en tant que LaunchDaemon afin qu'il démarre au démarrage, avant que quiconque ne se connecte. Définissez UserName pour qu'il s'exécute sous votre compte plutôt qu'en root, et donnez à --dir et --config-dir des chemins absolus pour que ses fichiers d'identité et de confiance restent dans votre propre ~/.config/relayium :

<!-- /Library/LaunchDaemons/com.relayium.serve.plist  (replace YOU with your macOS username) -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>              <string>com.relayium.serve</string>
  <key>UserName</key>           <string>YOU</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/relayium</string>
    <string>serve</string>
    <string>--dir</string>         <string>/Users/YOU/inbox</string>
    <string>--port</string>        <string>9031</string>
    <string>--config-dir</string>  <string>/Users/YOU/.config/relayium</string>
    <string>--allow-delete</string>
  </array>
  <key>RunAtLoad</key>   <true/>
  <key>KeepAlive</key>   <true/>
  <key>StandardOutPath</key>    <string>/Users/YOU/relayium-serve.log</string>
  <key>StandardErrorPath</key>  <string>/Users/YOU/relayium-serve.log</string>
</dict>
</plist>

# 1) authorize each pusher first — launchd gives serve no terminal to prompt on:
relayium authorize <fingerprint>     # get the fingerprint from the pusher's  relayium id

# 2) save the plist above to that path, then load it (root-owned, starts at boot):
sudo chown root:wheel /Library/LaunchDaemons/com.relayium.serve.plist
sudo launchctl bootstrap system /Library/LaunchDaemons/com.relayium.serve.plist

# check it's running / follow logs / stop it:
sudo launchctl print system/com.relayium.serve | grep state
tail -f ~/relayium-serve.log
sudo launchctl bootout system/com.relayium.serve

launchd ne donne aucun terminal à serve, il ne peut donc pas demander de confirmation — exécutez d'abord relayium authorize <fingerprint> pour chaque expéditeur, comme avec systemd. L'empreinte provient du relayium id de cette machine.
KeepAlive redémarre serve s'il plante ; RunAtLoad avec un LaunchDaemon dans /Library/LaunchDaemons le lance au démarrage sans connexion — le choix idéal pour un Mac mini sans écran.
Vous préférez un service à portée de session ? Placez le même plist (sans la clé UserName) dans ~/Library/LaunchAgents/ et chargez-le avec launchctl bootstrap gui/$(id -u) <path> — il démarre à votre connexion plutôt qu'au démarrage.
Si le coupe-feu applicatif de macOS est activé, autorisez les connexions entrantes pour relayium (Réglages Système → Réseau → Coupe-feu), sinon les envois vers votre port seront bloqués.

Laisser un émetteur utilisant sync --delete répercuter les suppressions

Par défaut, serve ne fait qu'ajouter ou mettre à jour des fichiers — un émetteur qui exécute sync --delete contre lui voit quand même ses fichiers nouveaux et modifiés copiés, mais les suppressions demandées sont ignorées, avec un avertissement consigné côté récepteur. Démarrez serve avec --allow-delete pour activer un vrai miroir, où les fichiers supprimés côté émetteur le sont aussi ici :

relayium serve --dir /srv/mirror --allow-delete

--allow-delete est une option activée côté récepteur ; l'émetteur doit tout de même la demander avec sync --delete.
Sans cette option, rien n'est jamais supprimé sur cette machine, quoi que demande un émetteur.

Quand ça ne marche pas

Dans quatre de ces cinq pannes, le service continue de tourner et paraît sain — un écouteur qui refuse tout reste un écouteur. Chacune se tranche par une ligne à lire ou une commande à exécuter.

Symptôme, vérification, correction

Le service démarre et reste en vie, mais chaque envoi est refusé.

journalctl -u relayium-serve -n 20 --no-pager
# warning: no authorized peers and no terminal to approve on; all pushes will be rejected.

Un service n'a pas de terminal, il ne peut donc jamais exécuter la demande d'approbation du premier envoi, et tout ce qu'il voit est une empreinte inconnue. Autorisez chaque expéditeur à l'avance : relayium id sur la machine émettrice, relayium authorize <empreinte> ici, avec le même --config-dir que l'unité. Cet avertissement est affiché au démarrage, il figure donc dans le journal dès la première ligne.

Le service ne démarre pas du tout et se plaint de permissions non sûres sur id.key.

stat -c '%a %U %n' /etc/relayium/id.key
# 400 relayium /etc/relayium/id.key

La clé doit être exactement en 0600. Pas 0644 — et, c'est là que ça piège, pas 0400 non plus : la resserrer casse le service aussi sûrement que la relâcher. Faites chmod 600 sur la clé et assurez-vous qu'elle appartient au User= de l'unité.

L'expéditeur signale que la connexion a été refusée.

relayium push ./build relayium://drop.example.com:9031
# hint: if the peer refused the connection, it may not have authorized this host.

Le récepteur ne reconnaît pas cet expéditeur. Lancez relayium id sur l'expéditeur et relayium authorize avec cette empreinte sur le récepteur. Si c'est déjà fait, vérifiez que ça l'a été sous le --config-dir de l'unité : le fichier de confiance est propre à un répertoire, et une empreinte autorisée dans ~/.config/relayium n'existe tout simplement pas pour un service qui lit /etc/relayium.

Les envois passent quand vous lancez serve à la main, mais pas via le service ou pas depuis une autre machine.

sudo ss -tlnp | grep 9031

Deux causes distinctes, une seule vérification pour les séparer. Si rien n'écoute, l'unité n'est pas activée — systemctl is-enabled relayium-serve. Si elle écoute, le port est bloqué : ouvrez 9031 dans le pare-feu de l'hôte et dans tout groupe de sécurité cloud. Un --port non standard doit correspondre au port du relayium://host:N de l'expéditeur.

Les suppressions demandées par un expéditeur sync --delete ne se produisent jamais ici.

journalctl -u relayium-serve | grep -i delete

La suppression se décide côté récepteur et elle est désactivée par défaut : les fichiers nouveaux et modifiés sont toujours copiés, et chaque suppression ignorée est journalisée ici en avertissement. Ajoutez --allow-delete à l'ExecStart de l'unité et redémarrez. Que l'expéditeur le demande ne suffit pas, et cette asymétrie est voulue — un récepteur ne perd pas de fichiers à cause d'une option tapée ailleurs.

Questions fréquentes

Sur quel port serve écoute-t-il par défaut ?

9031. Changez-le avec --port aussi bien sur le processus à l'écoute (serve --port N) que sur la cible de l'émetteur (relayium://host:N).

Dois-je approuver chaque envoi à la main ?

Seulement le premier envoi d'une empreinte donnée, et uniquement quand serve tourne avec un terminal attaché. Ensuite, c'est mémorisé. Faire tourner serve de façon non interactive (systemd, un pipe) supprime totalement l'invite et rejette les pairs inconnus — autorisez-les plutôt à l'avance avec relayium authorize.

Un émetteur peut-il supprimer des fichiers sur mon récepteur permanent ?

Seulement si vous avez démarré serve avec --allow-delete et que l'émetteur exécute sync --delete. Sans --allow-delete, les suppressions sont silencieusement ignorées et tout le reste est transféré normalement.

Faire tourner un récepteur permanent est-il gratuit ?

Oui. relayium serve fait partie de la CLI gratuite et auto-hébergeable — aucun compte, aucun palier payant, des deux côtés de la connexion.

Où serve conserve-t-il son identité et sa liste de pairs ?

Par défaut dans ~/.config/relayium (id.key/id.crt pour l'identité de cet hôte, authorized_fingerprints pour la liste d'autorisation). Pour un service systemd, faites pointer --config-dir vers un emplacement fixe comme /etc/relayium.

Comment lancer serve au démarrage sous macOS ?

macOS n'a pas de systemd — utilisez launchd. Installez serve en tant que LaunchDaemon dans /Library/LaunchDaemons (se lance au démarrage ; définissez UserName pour qu'il s'exécute sous votre compte), ou en tant que LaunchAgent dans ~/Library/LaunchAgents (démarre à la connexion). Ce guide fournit un plist prêt à éditer ; il n'y a pas de service Homebrew. Pré-autorisez les expéditeurs avec relayium authorize au préalable, car launchd ne donne à serve aucun terminal pour demander confirmation.

Transformez n'importe laquelle de vos machines en récepteur permanent et gratuit — envois directs via TLS avec épinglage, sans aucun relais.

Obtenir la CLI