croc

Last reviewed Aug 26, 2026 · 946 words

croc send report.pdf on one machine, croc 4729-brave-lemon-orbit on the other, and the file arrives encrypted, resumable, and through any NAT, with no account and no size limit. That is the entire user manual. What is left to decide is whether the traffic goes through the project's public relay, which is the default, or through one you run, which takes a single Go binary, about 32 MB of RAM, and 5 open ports. Self-hosting the relay is the cheapest privacy upgrade in the file-sync category and the only part of croc that needs a server at all.

The two-command workflow

Install is a single binary written in Go, available through Homebrew, Scoop, Chocolatey, most Linux package managers, or the project's install script:

curl https://getcroc.schollz.com | bash
croc send ~/backups/vault-2026-08.tar.gz

The sender prints a code phrase. The receiver types croc and enters the phrase when prompted, confirms the file list, and the transfer starts. Folders are sent as-is, multiple files in one go, and an interrupted transfer picks up where it stopped if you rerun both sides with the same code. croc send --text "the wifi password" sends a string instead of a file, which covers the "how do I get this onto that machine" case without a file at all.

If both machines are on the same LAN, croc discovers the peer locally and moves the bytes directly, at whatever your switch allows. Otherwise it falls back to the relay, and that is where the self-hosting question starts.

What the relay can and cannot see

The relay is a rendezvous point. Both sides connect out to it, it pairs them by the code phrase, and it forwards packets. The code phrase is never sent; instead both ends run a password-authenticated key exchange over it, so the relay learns a session identifier and nothing that would let it derive the key. The file contents, names, and sizes are encrypted before they leave the sender.

So the public relay at croc.schollz.com sees your IP address, the peer's IP address, timing, and the volume of ciphertext. For most people that is acceptable. For a company moving client data, or anyone who just prefers not to route through a stranger's server, it is enough reason to run your own. The catalogue lists "public relay by default" as a con, and that is the honest framing: safe against reading, not against observation.

Your own relay is one process and 5 ports

croc relay --ports 9009,9010,9011,9012,9013 --pass "a-long-shared-secret"

Port 9009 handles the pairing handshake and the four ports after it carry the parallel transfer streams, so open all 5 in your firewall. The --pass flag stops random internet users from using your relay as a free file-transfer service, which they will otherwise do. A schollz/croc Docker image exists if you would rather run it as a container with a restart policy; the process uses next to no memory and does no disk I/O, so it fits on the smallest VPS you have or on the box behind your reverse proxy that already has a public IP.

Clients then need to know about it. Pass --relay relay.example.com:9009 --pass "a-long-shared-secret" on each command, or set CROC_RELAY and CROC_PASS in the environment once and forget them. A relay on a Tailscale node works too, which gets you a private rendezvous point with no public port, at the cost of every peer needing the VPN client.

The code phrase and your shell history

Recent croc versions prompt for the code phrase on the receiving side instead of taking it as a command-line argument. The reason is mundane: an argument ends up in shell history and in the process list, visible to any other user on a shared machine for the duration of the transfer. If you have scripts that call croc <code> directly, the --classic flag restores the old behaviour, and there is a persistent toggle for it. I would leave the new default alone for interactive use and use --classic only inside automation on machines you control.

Two other flags worth knowing: --yes skips the confirmation prompt for scripted receives, and --code your-own-phrase on the sender lets you pick the phrase, useful when you are reading it aloud over a phone call.

When croc is the wrong tool

It is command-line only, and that is not going to change. If the other end of the transfer is a relative with a phone, LocalSend has a GUI on every platform and does LAN discovery without any typing, though it does not cross networks. If you want two folders kept in sync continuously rather than a one-off send, that is Syncthing's job, not croc's. And if you were using WeTransfer for links you can email to someone who will download it later, croc cannot do that either; both sides must be online at the same time. The WeTransfer alternatives page covers the asynchronous options.

What I'd do

Install croc on every machine you administer and use it for every one-off transfer between two terminals you control. Run croc relay with a password on the VPS or public-facing box you already have, set CROC_RELAY and CROC_PASS in your shell profile, and never think about the public relay again. For anything involving a non-technical person on the other end, hand them LocalSend instead and keep croc for yourself.