Relayium vs croc: encrypted file transfer from the terminal

What Relayium and croc have in common

Start with the overlap, because it's substantial: both are single small binaries you install once, both move files over direct connections at no charge, and both are open source — croc under the permissive MIT license, the Relayium CLI under AGPL-3.0 — so you can read every line that touches your files.

• A short code known only to the two ends is enough for them to find each other and agree on a key. croc's code is made up on the spot; Relayium's is minted by its server for a signed-in sender, and the receiver still needs no account.
• Encrypted in transit end to end: the relay or rendezvous point in the middle never sees your file's contents.
• Interrupted transfers can pick back up instead of starting over, and both verify what arrived actually matches what was sent.
• Cross-platform: macOS, Linux and Windows.

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

This is the biggest practical difference. croc is built around a single flow — code phrase in, code phrase out. Relayium's CLI adds two more ways to move files that lean on infrastructure you already have.

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 verification code you check twice

croc sends a batch of files 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.

For a one-off cross-network transfer, relayium send / receive plays the same role as croc's code phrase, pairing two computers by a short code. It's direct peer-to-peer, and it prints a short verification code (a Short Authentication String) on both ends. Comparing it out of band confirms that the pinned TLS certificate fingerprints were not substituted and the rendezvous service did not impersonate either endpoint; it authenticates the endpoints, not every network hop. This mode is direct-only, so if the two ends can't find a direct path it fails rather than falling back to a relay.

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

When croc is the simpler pick

There are real cases where croc is the better tool for the job, and it's worth saying so plainly.

• You just want to hand one file to a friend right now with the fewest moving parts — no server to reach, nothing to set up on either end.
• You're behind a strict NAT with no way to open a direct path: croc's relay carries the encrypted stream regardless, so the transfer completes either way. Relayium's send / receive is direct-only and can fail in that situation (push/pull or daemon-direct to a reachable server still work, since those don't depend on a direct P2P hop).
• You don't need folder mirroring, SSH integration, or a long-running listener — croc is one ad hoc command per side and nothing else to think about.
• You already trust croc's large, established community and its years of real-world use.

Feature comparison at a glance

The differences that matter most, side by side:

• Talking to a server: Relayium reuses your SSH access (push/pull) or a pinned-TLS daemon; croc has no SSH integration — install croc on both ends and share a code phrase.
• Folder sync: relayium sync mirrors incrementally with --delete and --watch; croc sends a batch and exits, with no mirror or delete semantics.
• No direct path available: croc's relay carries the encrypted stream so the transfer still completes; Relayium's send/receive is direct-only.
• Verification: both are encrypted end to end; Relayium's send/receive additionally prints a short code both sides compare before the transfer starts.
• Self-hosting: both are self-hostable — croc's relay is a small standalone binary; Relayium's server also runs the web app, and the CLI's send/receive can point at your own with --server.
• License and cost: croc is MIT-licensed and the Relayium CLI is AGPL-3.0-licensed; both are free for direct transfers. croc needs no account at all; Relayium needs one only for send, to mint the pairing code.