Server-to-server transfers with the Relayium CLI (daemon direct)

Last updated: 2026-07-08

When both machines are yours and each knows the other's address, SSH is extra friction and a rendezvous is pure overhead. Daemon direct is built for exactly this: one server listens, the other pushes straight to it over a pinned TLS 1.3 connection. No relay, no SSH, no pairing code — trust is public-key and set up once.

This guide covers starting the listener, pushing to it, approving a new pusher on first contact, automating it, and running the listener as a systemd service.

Start the listener (on the receiver)

On the receiving server, serve listens for pushes and writes them into a directory. It's long-running by default; add --once to accept a single transfer and exit. You don't pre-share anything — no fingerprints to copy up front:

# on the RECEIVER
relayium serve --dir ~/inbox      # add --once for a single transfer; --port to change 9031

The listener processes connections one at a time and lands files under --dir.
The default port is 9031; change it with --port and open it on your firewall.

Push to it (on the sender)

From the sending server, push to the receiver's relayium:// address. The first connection pins the receiver's fingerprint; every connection after that verifies it, and a changed fingerprint is refused rather than silently accepted — so a swapped key or a man-in-the-middle is caught, not trusted. On the very first push, the sender waits a moment while the receiver approves it (next step).

# on the SENDER
relayium push ./build.tar.zst relayium://receiver.example.com

# non-default port
relayium push ./build.tar.zst relayium://receiver.example.com:9040

No relay and no fallback: if the listener isn't reachable, the push fails — file bytes never route through anyone else.
The same transfer engine as the other modes: resumable, with a per-file SHA-256 check.

Approve the sender on first push (on the receiver)

The first time a new machine pushes to your listener, serve (in a terminal) shows you where it's from and its fingerprint and asks you to approve it — like SSH's first-connect prompt, but on the receiving side:

# on the RECEIVER, when a new sender pushes:
Incoming push from 203.0.113.7:54021
  fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y

Answer y and that fingerprint is remembered in authorized_fingerprints; every later push from the same machine then goes through silently.
The fingerprint is a machine's stable identity (it survives restarts and IP changes), so approving is a one-time step per pusher.
The pusher, in turn, learns the listener's key on first connect (trust on first use) and pins it in known_hosts.

Automate it (or run without a terminal)

Because an approved fingerprint is remembered, later pushes need no prompt — so relayium push drops straight into cron, a deploy script, or CI for encrypted, integrity-checked, resumable server-to-server sync. When serve runs without a terminal (a systemd service, a pipe) it can't prompt, so it rejects unknown pushers; pre-authorize them instead. Get the fingerprint from the pusher's relayium id, or copy it from the "rejected unauthorized peer …" line in the serve log, then:

# on the RECEIVER: pre-authorize a sender without a prompt
relayium authorize 74318e3b...

Identity and trust files live in ~/.config/relayium/ (override with --config-dir, e.g. /etc/relayium for a service).
authorize is idempotent — running it again for the same fingerprint is a no-op.

Run the listener under systemd

For an always-on inbox, run serve as a systemd service. Point --config-dir at a fixed location like /etc/relayium so the identity is stable across restarts, and let systemd keep it alive:

# /etc/systemd/system/relayium-serve.service
[Unit]
Description=Relayium daemon-direct listener
After=network-online.target

[Service]
ExecStart=/usr/local/bin/relayium serve --dir /srv/inbox --config-dir /etc/relayium
Restart=always
User=relayium

[Install]
WantedBy=multi-user.target

systemctl enable --now relayium-serve to start it and bring it up on boot.
Keep /etc/relayium/id.key readable only by the service user — relayium refuses to load a key with loose permissions.

Frequently asked questions

How is daemon direct different from push over SSH?

push over SSH tunnels the transfer through your SSH connection and needs an SSH account on the remote. Daemon direct needs no SSH and no account — the two servers authenticate each other by certificate fingerprint over pinned TLS, which is lighter when both machines are yours.

Do I have to copy fingerprints around by hand?

No. In a terminal, serve prompts you to approve each new pusher on its first push — showing its address and fingerprint — and remembers it, so later pushes are silent. You only reach for relayium id or relayium authorize for non-interactive setups like a systemd service, where there's no one to answer the prompt.

Where are the identity and trust files?

In ~/.config/relayium/ by default (override with --config-dir). id.key / id.crt are this host's persistent identity, known_hosts holds fingerprints of listeners you've pushed to, and authorized_fingerprints is the listener's allow-list of pushers.

What happens if a fingerprint changes?

The push refuses and warns. The listener's key is pinned in known_hosts on first use, so a later change — a re-keyed host, or a man-in-the-middle — is rejected rather than silently accepted. Remove the known_hosts line only if you intentionally rotated the key.

Is there any relay fallback?

No. Daemon direct assumes a reachable listener address; if the connection can't be made, it fails. Nothing is ever proxied through Relayium — that's the point of this mode.

Wire up two of your own servers for direct transfers — no relay, no SSH, no pairing code.

Get the CLI