Send a file to someone across networks with the Relayium CLI

Last updated: 2026-08-07

Sometimes the other machine isn't yours and you can't SSH into it — a file for a colleague in another office, a build for a client, an archive for a friend across the country. relayium send and receive move it directly between the two of you across networks, using nothing but a short pairing code that your CLI mints when you send.

The connection is peer-to-peer and end-to-end encrypted. Only a tiny rendezvous handshake passes through Relayium to introduce the two ends; the file bytes never do.

Before you start

Everything below is the relayium CLI, so install it first if you haven't. On macOS or Linux, one command drops a prebuilt binary on your PATH:

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

• Prefer to pick the file yourself, or on Windows? Grab a binary from the releases page — relayium.com/cli lists every install option (or go build -o relayium ./cmd/relayium if you have Go).
• relayium --version confirms it's installed. Skip this and the commands below just print 'command not found'.

Send, then pass on the code it prints

Sign in once with relayium login, then just send. The CLI mints a pairing code, prints it along with the exact command the other end runs, and waits. Pass that code along out of band — say it over a call, drop it in a chat:

1. On the sending machine, sign in once. Skip this if relayium whoami already prints your account email.

   relayium login

2. From the directory holding the file, start the send. The CLI mints the code, prints the command for the other end, and then waits.

   relayium send ./release.zip

3. Read the six digits it printed to the other person out of band. They stop working five minutes after they were minted.

4. On the receiving machine, in the directory where the files should land, run the command the sender was shown. Add a directory to land somewhere else.

   relayium receive 483920

   relayium receive 483920 ./downloads

5. Leave both terminals running until the receiving shell returns to its prompt. This is one live session: closing either end stops the transfer.

# on the SENDER
Code: 483920   (valid 5 minutes)
On the other machine:  relayium receive 483920
  not installed there?  curl -fsSL https://relayium.com/install.sh | sh
waiting for the receiver…
verification code (SAS): 271044 — not the pairing code; compare it on both ends to rule out a substituted endpoint
path: direct

• The code is 6 decimal digits — any of 0-9, leading zeros included — and it expires 5 minutes after it is minted.
• The code is just a shared secret to meet on; it isn't sent to anyone but the rendezvous, and it introduces the two ends only.
• Both ends must be the CLI — a browser can't join a CLI pairing code. Sending to someone who only has a browser? Use relayium up instead, which gives you a download link.

Verify with the SAS code

When the two ends connect, both terminals print the same 6-digit SAS (short authentication string) derived from their pinned TLS certificate fingerprints. Compare it out of band — read it aloud on the call — to confirm the fingerprints were not substituted and the rendezvous service did not impersonate either endpoint. The SAS authenticates the endpoints; it does not prove every network hop.

For the strongest protection, add --verify: the transfer then waits for you to confirm the codes match before a single byte moves.

relayium send --verify ./release.zip

Direct only — free, or it fails

The transfer races a direct connection between the two ends. When one can be established — which is the common case for at least one side with a reachable address — the file streams straight across, encrypted, at full speed and at no cost.

Relayium CLI send/receive and text are direct-only P2P: they never relay file or message bytes through TURN or any other Relayium server. If the two ends cannot establish a direct connection, the session fails rather than falling back to a relay.

If you hit this, the reliable answer is daemon direct between two reachable servers, push over SSH, or a stored link from relayium up.

• Direct connection succeeds → free, full-speed, end-to-end encrypted.
• Both ends can be anywhere geographically — the sender just runs send, and the receiver runs receive with the code it printed.

When it doesn't work

Four failures account for nearly every unsuccessful attempt. Each one has a line you can read or a command you can run that decides it, so you never have to guess which end is at fault.

Frequently asked questions

Where does the pairing code come from?

Relayium mints it. Run relayium send ./release.zip (after relayium login) and the CLI prints a 6-digit code good for five minutes, plus the exact command the other end runs. You can't choose it yourself — the server only accepts codes it issued.

Is the file uploaded anywhere?

No. The file streams directly between the two of you, end-to-end encrypted. Only a small rendezvous handshake passes through Relayium to introduce the ends — never the file.

What if we can't connect?

If both ends are behind strict NAT with no reachable address, the direct connection can't be made and the transfer fails — the CLI has no relay fallback, by design. Use daemon direct between two reachable servers, or push over SSH, when a direct path isn't available.

How do I know it's really the right person on the other end?

Both terminals print an identical 6-digit SAS code derived from their pinned TLS certificate fingerprints. Compare it out of band; a match confirms the fingerprints were not substituted and the rendezvous service did not impersonate either endpoint. It authenticates the endpoints, not every network hop. Add --verify to require that confirmation before any bytes move.

Keep reading

• Receive files from the command line
• Transfer files and text from the terminal with the Relayium CLI
• Relayium vs croc: encrypted file transfer from the terminal
• Send files between two computers over the internet
• Relayium