Relayium vs magic-wormhole: CLI file transfer

Last updated: 2026-07-12

magic-wormhole has quietly earned a loyal following: run it, get a short human-readable code like 7-crossover-clockwork, read it to the other person, and the file arrives — encrypted the whole way, with no account and no server you have to think about. Relayium's CLI is built around a similar idea, a short code that pairs two computers directly and encrypts everything in between.

They overlap a lot, and where they don't, it's worth being precise about it — including the one place magic-wormhole is genuinely more resilient than Relayium's CLI today.

What they have in common

Both tools solve the same core problem the same honest way: no file staged on a server you don't control, and a short code as the only thing the two ends pass between them out of band. magic-wormhole needs no account at all; Relayium asks only the sender to sign in, so its server can mint that code, and the receiver still doesn't.

End-to-end encrypted: magic-wormhole derives a session key from the wormhole code itself using a PAKE (SPAKE2), so even its own rendezvous server never learns the key; Relayium's send/receive does an X25519 key exchange between the two ends directly and shows a short verification code (SAS) you can compare before any bytes move.
No account to receive, on either tool — and none at all for magic-wormhole.
Free and open source — read the code that touches your files.
Cross-platform: macOS, Linux and Windows.

The one place magic-wormhole is more resilient: it has a relay

This is the honest tradeoff, and it's worth stating plainly rather than glossing over. magic-wormhole ships with a Transit Relay it can fall back to when the two ends can't open a direct connection to each other — for example, both sides sitting behind strict or symmetric NAT with no way to punch through. The relay only ever sees ciphertext, but because it's there, the transfer still completes.

Relayium's send/receive is direct-only: it races a direct connection for a few seconds right after the handshake, and if it can't find one, the transfer fails outright rather than falling back to any relay — Relayium's servers never touch cross-network CLI file bytes at all, by design. In practice that's rare (most home and office networks allow a direct path), but if you're moving files between two machines that are both behind unusually strict NATs, magic-wormhole is more likely to just work. If a direct path can't be found and reliability matters more than avoiding a relay, that's the case for reaching for magic-wormhole — or for using Relayium's push/pull or daemon-direct against a server you can actually reach, which don't depend on that direct P2P hop at all.

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'.

SSH and daemon-direct: talking to a server you already run

Where Relayium's CLI adds real surface area is outside the one-off pairing-code case: two more ways to move files that lean on infrastructure you already have, which magic-wormhole doesn't attempt to cover.

relayium push / pull reuses your existing SSH access, so there's nothing new to trust and no code to share. push even works against a server with no relayium installed at all, falling back to a plain tar stream over the SSH connection — that fallback is push-only; pull always needs relayium on the remote, since it acts as the sender there.

relayium serve turns any machine you own into a daemon-direct target, reachable over pinned TLS 1.3 with no SSH and no code phrase — trust is on the first connection (approved interactively, or pre-authorized for unattended use) and pinned from then on, the same idea as an SSH host key.

relayium push ./photos user@your-server:backups/

relayium serve --dir ~/incoming

relayium push ./build relayium://your-server

Folder sync and a self-hostable server

magic-wormhole sends a batch of files (or a folder, zipped) and exits — send it again to update the other side, with no notion of what should be removed. Relayium's CLI adds relayium sync, an incremental one-way mirror over either transport above: it only moves what changed, --delete removes files on the destination that disappeared from the source (a daemon only honors it if it was started with --allow-delete, so a receiver has to opt in), and --watch keeps re-syncing in real time as files change, with no cron job needed.

Relayium's server is also self-hostable as a single Docker container if you want to run the whole thing yourself rather than rely on relayium.com; point the CLI at it with --server.

relayium sync ./photos user@your-server:backups/photos --delete --watch

Feature comparison at a glance

The differences that matter most, side by side:

No direct path available: magic-wormhole's Transit Relay carries the encrypted stream so the transfer still completes; Relayium's send/receive is direct-only and fails in that case.
Talking to a server: Relayium reuses your SSH access (push/pull) or a pinned-TLS daemon; magic-wormhole has no SSH integration — install it on both ends and share a code.
Folder sync: relayium sync mirrors incrementally with --delete and --watch; magic-wormhole sends a batch (or a zipped folder) and exits, with no mirror or delete semantics.
Verification: both are encrypted end to end; Relayium's send/receive additionally shows a short SAS code both sides compare before the transfer starts.
Self-hosting: Relayium's server is a single Docker image you can run yourself, serving both the CLI and the browser app; the CLI's send/receive can point at it with --server.
License and cost: both free and open source. magic-wormhole needs no account at all; Relayium needs one only for send, to mint the pairing code.

Frequently asked questions

Is Relayium's CLI free?

Yes, completely. There's no paid tier and nothing to meter — every mode connects the two ends directly, and the CLI is open source.

Does it need an account?

send does, and so does cloud up. push/pull uses your own SSH access and daemon-direct uses pinned-TLS certificate trust between your machines, so neither touches a Relayium account. send/receive is the exception: only the server can mint a pairing code, and only for a signed-in account, so the sender runs relayium login once — a send given a code you were handed mints nothing and needs no login. Receiving never needs an account.

What if I'm behind a strict NAT and there's no direct path?

Relayium's send/receive is direct-only and will fail in that case — it doesn't fall back to a relay. magic-wormhole's Transit Relay can still carry the encrypted stream and complete the transfer. If you need it to work no matter what the network looks like, magic-wormhole handles that case today; Relayium's push/pull or daemon-direct against a server you can reach work too, since they don't depend on a direct P2P hop.

Can I use the CLI's pairing code with Relayium's browser app?

Not yet for a live paired transfer — the CLI's send/receive uses its own direct handshake, separate from the browser's WebRTC-based pairing flow, so the two don't interoperate today. To hand a file to someone using only a browser, use Relayium's stored download link or the browser app's own pairing-code mode.

Can I self-host it?

Yes. Relayium's server ships as a Docker image (docker compose up -d --build), and you can point the CLI's send/receive at your own instance with --server https://your-domain.

Install the free Relayium CLI and try push, sync or send — free, and a code-based transfer as quick to start as magic-wormhole.

Get the CLI