Sending is only half the story — sooner or later you're on the receiving end: a colleague wants to hand you a file across the internet, one of your own machines wants to hand off to another, or you want to reach out and grab something from a server you administer. The Relayium CLI covers all three with a different command for each, and none of them need an account.
Pick receive when someone else is pushing to you by pairing code, serve when you want a standing inbox that trusted machines can push to any time, and pull when you're the one reaching out to a server you can already ssh into.
Three ways to receive, and when each applies
Which command you run depends on who's starting the transfer and how the two machines know each other:
relayium receive <code> [destdir] — someone sends to you across networks using a pairing code you agreed on out of band. Direct peer-to-peer, verified with a SAS code.
relayium serve [--dir D] [--port N] [--once] [--allow-delete] — this machine listens for daemon-direct relayium:// pushes, on port 9031 by default.
relayium pull [user@]host:src <dest> — you reach out over SSH to a server you can already log into and fetch files back.
receive: someone sends you a file across networks
This is the receiving half of relayium send. The other person picks a short code and tells you what it is over any channel you both trust — a call, a chat message — then runs relayium send <path> <code> on their end. You run receive with the same code:
relayium receive 428571
# or into a specific directory
relayium receive 428571 ./downloads
The connection is direct, peer-to-peer, and end-to-end encrypted; both terminals print the same SAS (short authentication string) once connected — compare it with the sender to be sure no one is in the middle.
No destination given: files land in the current directory.
Same direct-only rule as send: if no direct path can be found between the two networks, the transfer fails rather than routing through a relay.
This is the CLI's own pairing-code protocol — it doesn't interoperate with the browser's pairing code or QR flow at relayium.com today; that's a possible future addition, not something you can rely on yet.
The receiver never needs an account, on any network.
serve: turn this machine into a listening drop box
serve works the other way around: instead of you reaching out, other machines push straight to you over relayium:// — built for machines you already trust, like your own laptop pushing to a NAS, or a build server dropping artifacts on a box you own — over a pinned TLS 1.3 connection, no SSH, no rendezvous.
relayium serve
# a specific directory, port, and allowing delete requests
relayium serve --dir ~/incoming --port 9031 --allow-delete
The first time a new machine pushes to you, serve (running in a terminal) shows its address and fingerprint and asks you to approve it once; after that, pushes from the same fingerprint go through silently.
Without a terminal — a systemd service, a script with no TTY — there's no one to ask, so an unrecognized pusher is rejected outright. Pre-authorize it instead, using the fingerprint the pusher prints with relayium id:
Pre-authorize for unattended serve
For a serve that runs unattended (systemd, a background script), have the pusher run relayium id to print its fingerprint, then approve it ahead of time from the receiving side:
relayium authorize <fingerprint>
--dir sets where files land (default the current directory); --once accepts a single transfer and exits; --allow-delete lets an incoming --delete (mirror) request actually remove files here, and is off by default.
--config-dir (default ~/.config/relayium) is where this host's identity and its authorized-fingerprints list live — override it if you're running serve as a dedicated service.
pull: reach out and fetch from a server you can ssh into
pull is the mirror of push: instead of waiting for someone to send you something, you reach out over your existing SSH access and fetch files back.
Unlike push, pull always needs relayium already installed on the remote — there's no tar fallback for pulling from a bare server. If the remote doesn't have it yet, install it there first with curl -fsSL https://relayium.com/install.sh | sh.
Files are verified with a per-file SHA-256 check and resume automatically if interrupted (add --no-resume to disable).
-i and -p behave like ssh's own -i/-p, for a specific identity file or port.
Frequently asked questions
Do I need an account to receive files?
No. All three ways — receive, serve, and pull — are completely free and need no Relayium account, on either end.
Does relayium receive interoperate with the browser's pairing code?
No. The CLI's pairing-code protocol is separate from the browser's join-link and QR flow at relayium.com — they use different handshakes and don't talk to each other today. That's on the roadmap, not something you can rely on yet.
What happens if an unknown machine pushes to my serve listener?
In a terminal, you're prompted to approve it by address and fingerprint on its first push, and the approval is remembered. Without a terminal — a systemd service, a cron job — there's no one to ask, so an unrecognized pusher is rejected; pre-authorize it first with relayium authorize <fingerprint>.
Can I pull from a server that doesn't have relayium installed?
No. pull always needs relayium on the remote end; there's no tar fallback the way there is for push. Install relayium there first.
Where does relayium keep my identity and trusted peers?
In ~/.config/relayium by default — override the location with --config-dir on any command that touches identity or trust.
Ready to receive your first transfer? Install the CLI and pick receive, serve, or pull.