Run Relayium as an always-on receive service

Last updated: 2026-07-09

relayium serve --once handles a single incoming transfer and exits — fine for a one-off pull. But if you want a machine to be a standing drop point — a home server that backups land on overnight, a build box that CI pushes artifacts to, a NAS your phone can send photos to whenever — you want serve running all the time, not started by hand for each transfer.

This guide covers starting a long-running listener, approving who's allowed to push to it, pre-authorizing peers for the cases where no one's at the terminal, running it under systemd, and letting a sync --delete sender mirror deletions.

Start the listener

serve listens for daemon-direct pushes (relayium://host:port) over a pinned TLS 1.3 connection and writes what it receives into a directory. Nothing needs to be pre-shared to start it — no fingerprints to copy, no server to register:

relayium serve --dir ~/inbox
relayium serve --dir /srv/drop --port 9040   # non-default port
relayium serve --dir ~/inbox --allow-delete  # let a sync --delete sender mirror deletions

--dir sets where files land (defaults to the current directory).
--port sets the listening port (defaults to 9031); open it on your firewall if the sender is elsewhere.
With no --once, serve keeps running and accepting pushes until you stop it or a process manager restarts it — that's what makes it an always-on service.

Approve who's allowed to push

The first time a new peer pushes, serve — if it's running in a terminal — shows you where the push came from and its fingerprint and asks you to approve it, the same way SSH asks about an unknown host on first connect:

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

Answer y once and that fingerprint is written to authorized_fingerprints; every later push from the same machine goes through with no prompt.
A fingerprint identifies a machine, not a network address, so it survives the sender's IP changing.
This is interactive by design — it needs someone at the keyboard, which won't be true once serve moves to systemd (next).

Pre-authorize peers for non-interactive setups

When serve has no terminal to prompt on — a systemd service, a background process, a pipe — it can't ask, so it rejects any fingerprint it doesn't already recognize. Authorize peers ahead of time instead. On the machine that will push, run relayium id to print its fingerprint; on the receiver, add it before the first push arrives:

# on the machine that will PUSH: print its fingerprint
relayium id

# on this always-on RECEIVER: authorize it in advance
relayium authorize 74318e3b...

authorize is idempotent — running it again for a fingerprint you already trust does nothing.
Identity and trust files live under --config-dir, defaulting to ~/.config/relayium (id.key/id.crt is this host's identity, authorized_fingerprints is the peer allow-list).

Run it under systemd

For a service that survives reboots and crashes, hand serve to systemd. Point --config-dir at a fixed path so the host's identity and its authorized-peer list stay put across restarts:

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

Before enabling the service, run relayium authorize <fingerprint> for every peer that should be able to push — the service itself can't prompt.
systemctl enable --now relayium-serve starts it and brings it back on every boot.
Keep /etc/relayium/id.key readable only by the service user; relayium refuses to load a key with looser permissions.

Let a sync --delete sender mirror deletions

By default serve only ever adds or updates files — a sender running sync --delete against it still copies new and changed files, but any deletions it asks for are skipped, with a warning logged on the receiver. Start serve with --allow-delete to opt in to true mirroring, where files removed on the sender's side are removed here too:

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

--allow-delete is a receiver-side opt-in; the sender still has to ask for it with sync --delete.
Without it, nothing is ever deleted on this machine, no matter what a sender requests.

Frequently asked questions

What port does serve listen on by default?

9031. Change it with --port on both the listener (serve --port N) and the pusher's target (relayium://host:N).

Do I have to approve every single push by hand?

Only the first push from a given fingerprint, and only when serve is running with a terminal attached. It's remembered after that. Running serve non-interactively (systemd, a pipe) skips the prompt entirely and rejects unknown peers — pre-authorize them with relayium authorize instead.

Can a sender delete files on my always-on receiver?

Only if you started serve with --allow-delete and the sender is running sync --delete. Without --allow-delete, deletions are silently skipped and everything else still transfers.

Is running an always-on receiver free?

Yes. relayium serve is part of the free, self-hostable CLI — no account, no paid tier, on either side of the connection.

Where does serve keep its identity and peer list?

In ~/.config/relayium by default (id.key/id.crt for this host's identity, authorized_fingerprints for the allow-list). Point --config-dir somewhere fixed, like /etc/relayium, for a systemd service.

Turn any machine you own into an always-on, free receiver — direct pushes over pinned TLS, no relay involved.

Get the CLI