Transfer files and text from the terminal with the Relayium CLI

Last updated: 2026-09-01

The Relayium CLI is a single small binary that moves files and ephemeral text from your terminal — encrypted end to end, self-hostable, and free and open source under the AGPL-3.0. It handles copying files to a server, pushing a build between machines, sending an archive across networks, and moving a URL, command, or code snippet without first saving it as a file.

In the direct modes — push, pull, sync, daemon direct, send / receive and text — the file bytes travel directly between the two ends and never pass through Relayium's servers, so there is nothing metered and nothing to pay. Two modes are not direct: up, which stores an encrypted copy under your account and draws on four separate plan limits — monthly traffic, the storage you hold live at once, retention, and a rolling daily upload quota — and Device Inbox, which queues an encrypted task until a machine of your own comes back for it. This guide gets you installed and through your first transfer, then points you at the deeper how-tos for each mode.

Install in one command

What you need

A macOS, Linux or Windows machine with a terminal. Prebuilt binaries cover x86-64 and arm64 on all three.
curl, for the one-line install on macOS and Linux — curl --version prints a version. On Windows, download the .zip from the releases page instead.
A writable install directory. The script uses /usr/local/bin when it can write there and ~/.local/bin otherwise, and its last lines name the one it chose.
Nothing else for push, pull or daemon direct. Only minting a pairing code with send or text, and uploading with up, need a free Relayium account.

On macOS or Linux, one command downloads a prebuilt binary for your OS and puts it on your PATH:

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

Prefer to pick the file yourself? Download a binary from the releases page.
Have Go installed? Clone the repo and run: go build ./cmd/relayium (from the server directory).
Then run relayium --help to see every command, and relayium version to check the build.

The seven ways it moves files and text

Two questions decide which one you want: can the machine on the other end be offline right now, and is it a machine you administer? Nothing below is a blanket promise — each mode states the account it needs, whether the far end can be offline, where the bytes go, and what it actually verifies.

relayium up / relayium down (Cloud) — the far end can be offline. up encrypts on this machine, uploads only the ciphertext and prints a link; down fetches and decrypts it on any other machine, with no account. Uploading needs relayium login and draws on your plan's monthly traffic, storage cap, retention ceiling and daily upload quota, and the key rides only in the link's #k= fragment, which never reaches Relayium: the encrypted copy stays stored until its retention expires, but losing the link loses the only key that can decrypt it.
Device Inbox — the far end can be offline, and in the CLI this is the RECEIVE side only: a browser or a native app sends into a folder on a machine you own, and there is no CLI command that sends into an inbox. Both ends sign in to the same account, and someone at the receiving machine has to choose a folder and turn receiving on there. To move files between two of your own servers, use serve with push or sync instead.
relayium text — ephemeral encrypted messages between two terminals that are both online at the same time. Minting the code needs relayium login; joining with a code someone handed you needs no account, and Relayium servers keep no message bodies.
relayium send / relayium receive — to another person across networks, using a short pairing code the sender's CLI mints (sign in once with relayium login; the receiver never does). A minted code is good for five minutes, so start the receiving machine's command within that window. Relayium's CLI send/receive and text modes are direct-only P2P: as they are built today they carry no ICE and no TURN, so if the two ends cannot establish a direct connection the session fails rather than falling back to a relay. That is a property of these modes rather than of Relayium as a whole — the apps and the web page relay a cross-network transfer by design, over ciphertext the relay cannot read.
relayium push / relayium pull — to a machine you can already ssh into. The bytes travel over your own SSH connection and never reach Relayium's servers, and neither side needs a Relayium account. Neither push nor pull resumes: a destination that already exists is refused before any bytes are sent, so reach for relayium sync when a run may be interrupted.
relayium serve + relayium push relayium:// (daemon direct) — straight between two machines you own, over pinned TLS 1.3. No relay, no SSH, no pairing code. The receiving host's authorized_fingerprints file is the whole trust decision, and being signed in to a Relayium account grants no one filesystem access.
relayium sync — one-way incremental mirroring over the same transports as push: files whose size and modification time are unchanged are skipped. It is the mode that continues a partial file at the destination on a later run, and it verifies the files it does transfer — but a one-way mirror is a copy of the current state, not a versioned backup.

Send ephemeral text

Run relayium text on one machine to mint a pairing code and wait, then join from the other machine with the printed code:

relayium text

relayium text 483920

Minting the code needs relayium login; joining with a code needs no login.
Both machines must stay online. Messages are end-to-end encrypted, and Relayium servers never store their bodies.
Relayium's CLI send/receive and text modes are direct-only P2P: as they are built today they carry no ICE and no TURN, so if the two ends cannot establish a direct connection the session fails rather than falling back to a relay. That is a property of these modes rather than of Relayium as a whole — the apps and the web page relay a cross-network transfer by design, over ciphertext the relay cannot read.
Either endpoint can still copy or retain received text.
Each message can be at most 65,536 UTF-8 bytes. Use relayium send for anything larger.

Your first transfer

The quickest thing to try is copying a folder to a server you can SSH into. Relayium uses your existing SSH access, so there is nothing to configure on the remote and no account to create:

Check the CLI is on your PATH. It prints a version string, not "command not found".
```
relayium version
```
Check you can already reach the server the ordinary way. push reuses exactly this access, so an ssh that works settles the connection and authentication prerequisite — it does not promise the transfer itself, which still needs write permission and free space at user@your-server:backups/.
```
ssh user@your-server true
```
Push the folder. The last argument is host:path — the colon is what marks it remote, and a trailing slash means "into this directory".
```
relayium push ./photos user@your-server:backups/
```
Confirm the files arrived where you expected. push ./photos reproduces photos/ under the destination, so the folder name comes along.
```
ssh user@your-server ls backups/photos
```

What a successful run looks like

With relayium on the far end, push prints one line per completed file and exits 0. Against a bare server it prints the tar-stream summary instead — both are success.

relayium push ./photos user@your-server:backups/
  photos/IMG_0413.jpg (2314518 bytes)
  photos/IMG_0414.jpg (1998233 bytes)
echo $?
# 0

If relayium is installed on the remote too, push uses the native protocol: the batch is checked for collisions before any bytes are sent, and each file is verified by SHA-256 and staged before it is installed. It still does not resume — a re-run after an interrupted push is refused, because the files that landed now exist. Use relayium sync where you need that.
push falls back to a plain tar stream when relayium isn't on the remote, so it works even against a bare server — that fallback is push-only.
Pull the same files back with: relayium pull user@your-server:backups/ ./restore — pull always needs relayium on the remote (it has no tar fallback), so install it there first.

When the first command doesn't work

Four things go wrong on a first run more often than everything else put together. None of them needs guesswork — each has a command whose output decides it.

Symptom, check, fix

"relayium: command not found", right after the install script said it succeeded.

command -v relayium
# (prints nothing)

The binary is installed, but its directory isn't on your PATH. The script's last lines name the directory it used and print the exact export PATH line to add; run them, then open a new shell and try relayium version again.

push exits immediately with "push destination must be remote (host:path)".

relayium push ./photos user@your-server backups/
# push destination must be remote (host:path)

The destination lost its colon, so relayium read it as a local path. Write it scp-style, with no space between the host and the path: user@your-server:backups/

pull fails against a server that push worked fine against.

ssh user@your-server command -v relayium
# (prints nothing)

pull has no tar fallback, because the remote is the sender in that direction — it needs relayium installed there. Install it on the server with the same one-line command and run the pull again.

Two machines join the same code and one prints "the other side is running `relayium text`, not `relayium send`/`relayium receive`".

# a message session: BOTH ends run text
relayium text
relayium text 483920

The two ends ran different commands. Use relayium text on both machines for messages, and relayium send on one with relayium receive on the other for files; the mismatch is refused before anything is dialed, so nothing was sent.

Free, and private by design

There is nothing to pay for the direct modes above: push / pull, daemon direct, send / receive and text move their bytes straight between the two ends, and sync uses those same transports. Among them the only sign-in is the one that mints a pairing code, for send or for text. The CLI connects the two ends directly, so your files are never uploaded to a server in the middle — the only thing that ever touches Relayium is a tiny rendezvous handshake in send / receive and in text, used to introduce the two ends, never the file itself. The two modes that go through your account work differently: Cloud up stores an encrypted copy under your account, so it needs a sign-in and counts against your plan's monthly traffic allowance, its storage cap, its retention ceiling and its daily upload quota; Device Inbox queues an encrypted task for a machine of your own, and both ends have to be signed in to the same account.

Every transfer is encrypted end to end, and on the native protocol every file a run transfers is verified with a SHA-256 hash on arrival — the zero-dependency tar fallback is the exception, and verifies nothing per file. Resume is narrower than the rest: relayium sync continues a partial file on a later run, relayium down reconnects and continues within the run that started it, and push, pull, send and receive do not resume at all. It runs on macOS, Linux and Windows, and the whole thing is open source and self-hostable.

Frequently asked questions

Does the CLI cost anything?

The CLI itself is free and open source, and the direct modes — push, pull, daemon direct and send / receive — cost nothing to use: those file and text bytes never pass through a Relayium relay, so there is nothing to meter. The commands that draw on your plan are up and down, which write and read an encrypted copy held under your account. up counts against four separate limits — your monthly traffic allowance, the cap on how much you keep stored at once, your plan's retention ceiling, and a rolling daily upload quota — and down counts against the traffic allowance as it reads the copy back. Paid plans raise all of them.

Do I need a Relayium account?

To mint a pairing code with send or text, and for cloud up. push / pull uses your own SSH and daemon direct uses public-key trust, so neither needs an account. A server mints pairing codes only for a signed-in account, so the creator runs relayium login once; joining with a code you were handed needs no login. A receive user never signs in.

Which operating systems are supported?

Prebuilt binaries are published for macOS, Linux and Windows on both x86-64 and arm64. The install script covers macOS and Linux; on Windows, download the .zip from the releases page.

Do my files pass through Relayium's servers?

Not with the direct modes. With push, pull, daemon direct and send / receive the file bytes travel directly between the two ends, and only send / receive contacts our servers at all — for a small rendezvous handshake, never the file contents. Two modes are the deliberate exceptions, and in both the server holds only ciphertext it cannot read: up uploads an encrypted copy to your account's storage, and Device Inbox — receive-only in the CLI, through relayium inbox — queues an encrypted copy that a browser or native app sent to a machine of your own until that machine downloads it.

Install the free, open-source Relayium CLI and make your first direct transfer.

Get the CLI