Croc Is an Open-Source CLI File Transfer Tool

There's a particular kind of friction that developers know well: the moment you need to send a large file to someone on a different OS, different network, different everything — and every tool you reach for fails you in a slightly different and infuriating way. AirDrop doesn't cross platforms. WeTransfer links expire. SCP requires a server, a port, and a friend patient enough to follow instructions. Email has size limits. Discord is, as Andras from BetterStack puts it in a recent video, where you go "if you're desperate."

The video is a walkthrough of croc, a free, open-source CLI tool built by Zack Scholl, and it makes a case that's harder to dismiss than the genre usually produces: that the file transfer problem isn't solved, and that croc actually solves it.

The Diagnostic Is the Interesting Part

Before getting to croc itself, Andras spends time articulating why the existing landscape is broken despite being enormous. The argument centers on three properties a file transfer tool needs simultaneously: speed, security, and simplicity. Most tools achieve two. None of the obvious ones achieve all three.

"Look at the pattern. WeTransfer is simple, but slow and only as secure as its link. SCP is fast and secure, but nobody's non-technical friend is going to know how to use SCP right off the bat. So, almost nothing hits all three pillars."

That framing is worth sitting with for a moment, because it's not just a product pitch — it's a lens that reveals something real about why enterprise IT ends up with a dozen different file transfer solutions in use simultaneously, and why developers keep reaching for USB sticks in 2025.

The speed argument is the most technically precise. The conventional upload-then-download model — where you push a file to a server and the recipient pulls it down — is, as the video explains, mathematically suboptimal. If your upload is slower than your download (as is common on asymmetric connections), sequential transfer means your effective throughput is constrained by the upload leg first and then the download leg second. You never use both pipes at once.

Croc's answer to this is a full-duplex relay: both sides are active simultaneously, which removes that sequential bottleneck. And if the two machines are on the same local network, croc detects that and skips the relay entirely, transferring locally at whatever the LAN can handle.

PAKE: Security That Doesn't Depend on You Picking a Good Password

The security pillar is where croc's architecture gets genuinely interesting. A lot of tools that offer "encrypted transfers" put the burden on the user to choose a strong shared password. That's a reasonable design, but it has a known failure mode: people don't pick strong passwords. The security of the transfer becomes a function of the weakest human in the loop.

Croc uses Password Authenticated Key Exchange — PAKE — which works differently. The code phrase croc generates isn't itself the encryption key. It's an input into a cryptographic handshake between the two machines, which use it to derive a much stronger key on the fly. The security of the final key doesn't depend on the strength of the phrase in the way a static password would.

"Both sides use this phrase in a back-and-forth cryptographic exchange to generate a much stronger key on the fly. If someone tries to intercept that exchange with the wrong phrase, the whole thing just fails, so no data moves and everyone knows something's wrong."

That failure mode is notable. An interceptor doesn't get degraded security — they get nothing. The transfer simply doesn't happen. That's a meaningfully better property than "transfer completes but attacker can brute-force the key later."

The Relay Question Is the One Worth Asking

Croc's architecture requires a relay server — something that brokers the connection between sender and receiver, handling NAT traversal and keeping both sides talking. By default, that relay is a public server operated by croc's creator, Zack Scholl.

This is where the conversation gets more layered, and Andras handles it honestly rather than glossing over it.

"It's still a third-party server sitting in the middle of a transfer by default, and if you're at a company with data residency rules or you have a policy against routing traffic through infrastructure you don't control, that's going to be a blocker."

The end-to-end encryption means the relay operator can't read your files — only encrypted bytes pass through. But "can't read" and "no exposure" aren't the same thing. Connection metadata is visible. The relay knows who's talking to whom, when, and roughly how much data is moving. For personal use, most people will reasonably conclude this doesn't matter. For regulated environments, it might.

The self-hosting path exists and reportedly isn't complicated — croc includes a built-in relay command and a Docker image for this purpose. But the default matters. Most users never change defaults. And this is infrastructure controlled by a single person, not an organization with an SLA or a succession plan. That's not a knock on Scholl — it's just the honest structural reality of a widely-used open source tool that runs on volunteer infrastructure. We've seen this pattern before, and it's worth noting what it requires of users: a degree of trust that most of them will extend without thinking about it.

What the Demo Actually Shows

The user experience Andras demonstrates is genuinely minimal. On the sending side: croc send [filename]. Croc prints a randomly generated code phrase. On the receiving side: run croc, enter the phrase when prompted, confirm with Y. That's it. No account creation, no browser tab, no configuration.

The demo also includes interrupted transfer recovery — killing the connection mid-transfer and resuming it, which picks up where it left off rather than starting over. For large files over unreliable connections, that's not a nice-to-have; it's the difference between a tool you'll actually use and one you'll abandon after one bad experience.

Installation is a single command on both Windows and Mac, with documentation on the GitHub repository covering additional platforms.

The Broader Observation

What croc represents — beyond any specific feature — is a category of open source tooling that quietly solves real problems without anyone's marketing budget behind it. Scholl built something with a coherent technical philosophy and shipped it. It works cross-platform, it traverses NAT, it encrypts properly, it doesn't require an account.

The fact that most developers haven't heard of it isn't a mystery. It's just how open source works. The tools that get discovered are often the ones that get surfaced — by videos like this one, by word of mouth, by a colleague who happened to run into the right problem on the right day.

Whether croc belongs in your toolkit depends on what you're actually doing. For ad-hoc transfers between developers, or across mixed OS environments, the case looks solid. For regulated data or anything where you need auditable infrastructure, the self-hosted relay is worth the extra setup. For transferring files to your non-technical aunt — well, that's still a UI problem that croc's CLI isn't designed to solve.

The three-pillar framework Scholl laid out on his site, and that this video walks through, is useful independent of croc itself. It's a reasonable rubric for evaluating any file transfer tool you're already using. Run your current solution through it. You might be surprised which pillar you've been quietly sacrificing.

Dev Kapoor covers open source software and developer communities for Buzzrag.