Ejecuta Relayium como un servicio de recepción siempre activo

Última actualización: 2026-08-06

relayium serve --once atiende una única transferencia entrante y luego se cierra — perfecto para un pull ocasional. Pero si quieres que una máquina sea un punto de recepción permanente — un servidor doméstico en el que las copias de seguridad aterrizan cada noche, una máquina de compilación a la que CI envía artefactos, un NAS al que tu teléfono puede mandar fotos en cualquier momento — querrás que serve esté en ejecución todo el tiempo, en lugar de iniciarlo a mano para cada transferencia.

Esta guía cubre cómo iniciar un proceso a la escucha de larga duración, aprobar quién puede enviar, autorizar pares de antemano para los casos en que no hay nadie ante la terminal, ejecutarlo con systemd, y permitir que un remitente que usa sync --delete refleje las eliminaciones.

Antes de empezar

Todo lo de abajo es la CLI de relayium, así que instálala primero si aún no la tienes. En macOS o Linux, un solo comando deja un binario precompilado en tu PATH:

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

• ¿Prefieres elegir el archivo tú mismo, o estás en Windows? Coge un binario de la página de releases — relayium.com/cli lista todas las opciones de instalación (o go build -o relayium ./cmd/relayium si tienes Go).
• relayium --version confirma que está instalada. Sáltate esto y los comandos de abajo solo imprimirán « command not found ».

Iniciar el proceso a la escucha

serve escucha envíos daemon directo (relayium://host:port) a través de una conexión TLS 1.3 con anclaje y escribe lo que recibe en un directorio. No hace falta compartir nada de antemano para iniciarlo — ninguna huella que copiar, ningún servidor que registrar:

relayium serve --dir ~/inbox
relayium serve --dir /srv/drop --port 9040   # puerto distinto del predeterminado
relayium serve --dir ~/inbox --allow-delete  # permitir que un remitente con sync --delete refleje las eliminaciones

1. Elige dónde deben caer los archivos y arranca el receptor. Hasta aquí no hace falta compartir nada de antemano.

   relayium serve --dir ~/inbox

2. Desde la máquina emisora, empuja algo hacia este host por su dirección relayium://.

   relayium push ./report.pdf relayium://drop.example.com:9031

3. De vuelta en el receptor, responde a la petición de aprobación. Una y escribe esa huella en authorized_fingerprints, y los envíos posteriores de la misma máquina ya no vuelven a preguntar.

4. Comprueba que el archivo aterrizó de verdad en --dir y no en el directorio desde el que lanzaste serve.

   ls -l ~/inbox

$ 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 establece dónde aterrizan los archivos (por defecto, el directorio actual).
• --port establece el puerto de escucha (por defecto, 9031); ábrelo en tu cortafuegos si el remitente está en otro lugar.
• Sin --once, serve sigue en ejecución y aceptando envíos hasta que lo detengas o un gestor de procesos lo reinicie — eso es lo que lo convierte en un servicio siempre activo.

Aprobar quién puede enviar

La primera vez que un par nuevo envía algo, serve — si se está ejecutando en una terminal — te muestra de dónde vino el envío y su huella, y te pide que lo apruebes, igual que SSH pregunta por un host desconocido en la primera conexión:

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

• Responde y una vez y esa huella se escribe en authorized_fingerprints; cada envío posterior desde la misma máquina pasa sin ninguna solicitud.
• Una huella identifica a una máquina, no a una dirección de red, así que sigue siendo válida aunque cambie la IP del remitente.
• Este paso es interactivo por diseño — necesita a alguien ante el teclado, algo que dejará de cumplirse en cuanto serve pase a systemd (siguiente).

Autorizar pares de antemano para configuraciones no interactivas

Cuando serve no tiene una terminal en la que preguntar — un servicio systemd, un proceso en segundo plano, una tubería — no puede preguntar, así que rechaza cualquier huella que aún no reconozca. En su lugar, autoriza los pares con antelación. En la máquina que va a enviar, ejecuta relayium id para imprimir su huella; en el receptor, añádela antes de que llegue el primer envío:

# en la máquina que va a ENVIAR: imprime su huella
relayium id

# en este RECEPTOR siempre activo: autorízala de antemano
relayium authorize 74318e3b...

1. En la máquina que va a empujar, imprime su huella. Son 64 caracteres hexadecimales e identifican a la máquina, no a su dirección.

   relayium id

2. Autorízala en este receptor, con el mismo --config-dir bajo el que se ejecutará el servicio. Autorizar con otro usuario, o en la ruta por omisión mientras la unidad usa otra, deja la huella en un archivo que el servicio nunca lee.

   relayium authorize 74318e3b… --config-dir /etc/relayium

• authorize es idempotente — ejecutarlo de nuevo para una huella en la que ya confías no hace nada.
• Los archivos de identidad y de confianza viven bajo --config-dir, cuyo valor por defecto es ~/.config/relayium (id.key/id.crt es la identidad de este host, authorized_fingerprints es la lista de permitidos de pares).

Ejecutarlo con systemd

Para un servicio que sobreviva a reinicios y caídas, entrega serve a systemd. Apunta --config-dir a una ruta fija para que la identidad del host y su lista de pares permitidos permanezcan intactas entre reinicios:

# /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

1. Autoriza a todos los pares que deban poder empujar, antes incluso de que exista el servicio. No puede preguntar, así que rechaza todo lo que no sea ya de confianza.

2. Escribe la unidad de arriba en /etc/systemd/system/relayium-serve.service, con --config-dir apuntando a la misma ruta fija bajo la que autorizaste.

3. Recarga systemd y arranca el servicio, habilitándolo para que vuelva tras un reinicio.

   sudo systemctl daemon-reload

   sudo systemctl enable --now relayium-serve

4. Comprueba que está en marcha y que la advertencia que lo rechaza todo no aparece en su registro. Solo la segunda comprobación es específica de este montaje.

   systemctl is-active relayium-serve

   journalctl -u relayium-serve -n 20 --no-pager

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

• Antes de habilitar el servicio, ejecuta relayium authorize <fingerprint> para cada par que deba poder enviar — el servicio en sí no puede preguntar.
• systemctl enable --now relayium-serve lo inicia y hace que vuelva a levantarse en cada arranque.
• Mantén /etc/relayium/id.key legible solo por el usuario del servicio; relayium se niega a cargar una clave con permisos más laxos.

Ejecutarlo al arranque en macOS (launchd)

macOS no tiene systemd — su gestor de servicios es launchd. Para mantener serve en ejecución en un Mac (por ejemplo, un Mac mini que dejas encendido como punto de recepción), instálalo como LaunchDaemon para que se inicie en el arranque, antes de que nadie inicie sesión. Define UserName para que se ejecute como tú y no como root, y da a --dir y --config-dir rutas absolutas para que sus archivos de identidad y de confianza permanezcan en tu propio ~/.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 no da ninguna terminal a serve, así que no puede preguntar — ejecuta primero relayium authorize <fingerprint> para cada emisor, igual que con systemd. La huella proviene del relayium id de esa máquina.
• KeepAlive reinicia serve si se cae; RunAtLoad junto con un LaunchDaemon en /Library/LaunchDaemons lo inicia en el arranque sin necesidad de iniciar sesión — la opción idónea para un Mac mini sin monitor.
• ¿Prefieres un servicio a nivel de sesión? Coloca el mismo plist (quitando la clave UserName) en ~/Library/LaunchAgents/ y cárgalo con launchctl bootstrap gui/$(id -u) <path> — se inicia al iniciar sesión en lugar de en el arranque.
• Si el cortafuegos de aplicaciones de macOS está activado, permite las conexiones entrantes para relayium (Ajustes del Sistema → Red → Cortafuegos), o los envíos a tu puerto quedarán bloqueados.

Permitir que un remitente con sync --delete refleje las eliminaciones

Por defecto, serve solo añade o actualiza archivos — un remitente que ejecuta sync --delete contra él sigue copiando los archivos nuevos y modificados, pero cualquier eliminación que solicite se omite, y se registra una advertencia en el receptor. Inicia serve con --allow-delete para optar por un reflejo real, en el que los archivos eliminados en el lado del remitente también se eliminan aquí:

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

• --allow-delete es una opción del lado del receptor; el remitente todavía tiene que solicitarla con sync --delete.
• Sin ella, nunca se elimina nada en esta máquina, sin importar lo que solicite un remitente.

Cuando no funciona

En cuatro de estos cinco fallos el servicio sigue en marcha y parece sano: un receptor que lo rechaza todo sigue siendo un receptor. Cada uno se zanja con una línea que leer o una orden que ejecutar.

Preguntas frecuentes

¿En qué puerto escucha serve por defecto?

9031. Cámbialo con --port tanto en el proceso a la escucha (serve --port N) como en el destino del emisor (relayium://host:N).

¿Tengo que aprobar cada envío a mano?

Solo el primer envío de una huella dada, y únicamente cuando serve se ejecuta con una terminal conectada. Después se recuerda. Ejecutar serve de forma no interactiva (systemd, una tubería) omite por completo la solicitud y rechaza los pares desconocidos — autorízalos de antemano con relayium authorize en su lugar.

¿Puede un remitente eliminar archivos en mi receptor siempre activo?

Solo si iniciaste serve con --allow-delete y el remitente está ejecutando sync --delete. Sin --allow-delete, las eliminaciones se omiten en silencio y todo lo demás se transfiere igualmente.

¿Es gratis ejecutar un receptor siempre activo?

Sí. relayium serve forma parte de la CLI gratuita y autoalojable — sin cuenta, sin nivel de pago, en ninguno de los dos lados de la conexión.

¿Dónde guarda serve su identidad y su lista de pares?

En ~/.config/relayium por defecto (id.key/id.crt para la identidad de este host, authorized_fingerprints para la lista de permitidos). Apunta --config-dir a un lugar fijo, como /etc/relayium, para un servicio systemd.

¿Cómo ejecuto serve al arranque en macOS?

macOS no tiene systemd — usa launchd. Instala serve como LaunchDaemon en /Library/LaunchDaemons (se inicia en el arranque; define UserName para ejecutarlo como tú), o como LaunchAgent en ~/Library/LaunchAgents (se inicia al iniciar sesión). Esta guía incluye un plist listo para editar; no hay servicio de Homebrew. Autoriza de antemano a los emisores con relayium authorize, ya que launchd no da a serve ninguna terminal en la que preguntar.

Sigue leyendo

• Recibir archivos desde la línea de comandos
• Configurar Device Inbox en un servidor Linux siempre encendido
• Transferencias de servidor a servidor con la CLI de Relayium (daemon directo)
• Automatiza copias de seguridad cifradas del servidor con una tarea cron
• Relayium