Last updated: 2026-07-09
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.
Both tools solve the same core problem the same honest way: no account, no file staged on a server you don't control, and a short code as the only thing the two ends need to agree on out of band.
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.
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 ~/incomingrelayium push ./build relayium://your-servermagic-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 --watchThe differences that matter most, side by side:
Yes, completely. There's no paid tier and nothing to meter — every mode connects the two ends directly, and the CLI is open source.
No. push/pull uses your own SSH access, daemon-direct uses pinned-TLS certificate trust between your machines, and send/receive uses a short code you agree on out of band. None of it touches a Relayium account.
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.
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.
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 — no account, and a code-based transfer as quick to start as magic-wormhole.
Get the CLI