Primary question: Do you regularly transfer files between computers that sit on separate networks and cannot open inbound ports?
RepoDaily adoption score
RepoDaily rates this as 90/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
4 source(s) across 3 source category/categories, plus a RepoDaily-specific evidence module when available.
5 workflow step(s), 4 next-action step(s), and 5 command/install signal(s) were detected.
Trending momentum is +737 stars, with maintenance/release/issue signals counted when present.
Risk is marked low, with 5 security note(s) and 4 explicit skip condition(s).
2 opportunity lens item(s), 4 alternative(s), and 3 type-specific section(s) support differentiation.
License source or license wording is present.
2 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
croc is a command-line file-transfer tool written in Go that lets any two computers exchange files and folders through a public relay. The sender runs `croc send`, receives a short receive code, and shares that code with the recipient — who runs `croc` on their own machine, types the code, and gets the file. Neither side needs to open a port, configure a firewall rule, or stand up a local server. The relay brokers the connection; the actual payload stays end-to-end encrypted via PAKE (Password-Authenticated Key Exchange), so the relay operator cannot read the contents in transit.
What sets croc apart from scp, rsync, or cloud-drive uploads is that it collapses an entire category of friction. With scp you need SSH credentials and a reachable IP. With rsync you need the same plus an understanding of flags. With cloud storage you need an account, a browser, and enough patience for an upload-then-download round trip. croc handles all of these in a single binary that runs on Windows, Linux, and macOS, supports multiple files and folders, resumes interrupted transfers, connects IPv6-first with IPv4 fallback, and can route traffic through a proxy such as Tor for users who need that level of network obfuscation.
The module path in go.mod — `github.com/schollz/croc/v10` — signals that this project has gone through ten major versions, reflecting years of iteration on the transfer protocol, the relay logic, and the CLI surface. The codebase leans on several libraries from the same author: `schollz/pake/v3` for the key exchange, `schollz/peerdiscovery` for local network detection, and `schollz/cli/v2` for the command interface. It also pulls in `golang.org/x/crypto` for core primitives and `skip2/go-qrcode` for QR-code generation, which suggests mobile-friendly receive flows. The Go 1.25.0 toolchain requirement means the project tracks recent Go releases rather than pinning to an older baseline.
The README includes a prominent sponsorship banner stating that the project's future depends on community support. The MIT license covers the code, and the default relay is operated by the maintainer, though users can self-host a relay via Docker or a standalone binary. For anyone considering croc as a daily driver, the sustainability question is not about code quality but about relay hosting costs and maintainer bandwidth — a concern the sponsorship banner makes explicit rather than hiding.
Why it is trending now
- 737 period stars and rank 11 indicate renewed attention driven by developers seeking zero-config file transfer that does not route through a US-based cloud provider
- Installs in one command on virtually every platform: Homebrew, Scoop, Winget, Chocolatey, pacman, dnf, portage, Nix, Conda, Termux, FreeBSD pkg, and a curl install script
- End-to-end encryption via PAKE means the relay cannot decrypt payloads — a property most browser-based file-sharing services cannot claim
- Resuming interrupted transfers is built in, so a dropped connection on a large file does not mean starting over
- IPv6-first with IPv4 fallback and optional Tor proxy support address network environments where NAT or censorship blocks direct connections
- Docker image published at docker.io/schollz/croc with a relay mode makes self-hosting a private relay a single `docker run` command
Problem it solves
- SSH-based transfers (scp, sftp, rsync) require reachable IPs, key management, and often port-forwarding — none of which are available when one machine sits behind carrier-grade NAT or a hotel network
- Cloud-storage sharing requires an account on both sides, a browser upload, a shared link, and a separate download step — overkill for sending a 500 MB log file to a colleague
- Browser-based tools like Snapdrop require both devices on the same local network and offer no end-to-end encryption guarantee
- Resuming a partially transferred file is missing from most ad-hoc tools, forcing a full re-upload after a network hiccup
How it works
- The sender runs `croc send path/to/file` on their machine. croc generates a short random receive code (e.g., `4231-some-words`) and displays it.
- croc establishes a connection to a relay server and performs a PAKE key exchange so that sender and receiver derive a shared session key without ever transmitting the key itself.
- The recipient runs `croc` on any other computer, enters the code, and the PAKE handshake completes — encrypting all subsequent file data end-to-end.
- The file data flows through the relay, but the relay only sees ciphertext. If the transfer is interrupted, croc can resume from where it left off rather than restarting.
- By default croc uses the maintainer-operated relay, but users can point at a self-hosted relay via flags or environment variables for full control of the network path.
Product demo and interface preview
Install and Command Surface
- Quick install (any OS): `curl https://getcroc.schollz.com | bash`
- macOS: `brew install croc` (Homebrew) or `sudo port install croc` (MacPorts)
- Windows: `scoop install croc`, `choco install croc`, or `winget install schollz.croc`
- Linux distros: `pacman -S croc` (Arch), `dnf install croc` (Fedora), `emerge net-misc/croc` (Gentoo), `nix-env -i croc` (Nix)
- Mobile and BSD: `pkg install croc` on Termux (Android) and FreeBSD
- Conda/pixi: `pixi global install croc` or `conda install --channel conda-forge croc`
- Docker (POSIX shells): a shell function wraps `docker run --rm -it --user "$(id -u):$(id -g)" -v "$(pwd):/c" docker.io/schollz/croc "$@"`
- NixOS: add `pkgs.croc` to `environment.systemPackages` in configuration.nix
Self-Hosted Relay via Docker
The published Dockerfile builds from `golang:1.25-alpine` and produces a final `alpine:latest` image that runs as `USER nobody`, which is a sensible non-root default for a network-facing relay. The image exposes five TCP ports — 9009, 9010, 9011, 9012, and 9013 — covering the relay listener and additional ports croc uses for data channels.
The CMD is `relay`, so `docker run docker.io/schollz/croc` starts a relay out of the box. A health check pings the ports via `nc -z` every 30 seconds with a 10-second timeout and 3 retries, using the `CROC_PORTS` or `CROC_PORT` environment variable (default 9009) to determine which port(s) to probe. Anyone deploying this behind a load balancer should map all five exposed ports and ensure the health check target is covered.
Dependency Architecture
The go.mod file for module `github.com/schollz/croc/v10` declares Go 1.25.0 and reveals the project's design through its dependencies. `schollz/pake/v3 v3.1.1` implements the Password-Authenticated Key Exchange that underpins end-to-end encryption — the sender and receiver derive a shared key from the receive code without ever sending the key over the wire.
`schollz/peerdiscovery v1.7.6` provides local network peer detection, likely used to discover croc instances on the same LAN for faster local transfers without the relay. `schollz/cli/v2 v2.2.1` is the command-line framework (a fork of urfave/cli), `schollz/progressbar/v3 v3.19.1` drives the transfer progress display, and `skip2/go-qrcode` generates QR codes — probably for scanning a receive code from a phone. The inclusion of `magisterquis/connectproxy` aligns with the README's claim that croc can use a proxy like Tor.
Who should pay attention?
Good fit if
- You need to send a large file to someone on a different network and neither of you can open ports
- You want end-to-end encryption without setting up SSH keys or GPG
- You transfer files to machines behind carrier-grade NAT, hotel Wi-Fi, or corporate firewalls
- You need to resume interrupted transfers without restarting from byte zero
- You want a self-hostable relay so file traffic never touches a third-party cloud
Skip for now if
- You only ever copy files between machines on the same LAN with SSH already configured — rsync or scp is more efficient
- You need scheduled, automated, or batch transfers between known hosts — a proper sync tool fits better
- Your compliance regime requires an audit trail of who downloaded what and when — croc's receive code model has no server-side accounting
- You need fine-grained access control, expiry policies, or password-protected links — croc's model is point-to-point, not a sharing portal
Risks and cautions
MIT-licensed single binary with no account requirements and a public relay you can replace with a self-hosted Docker container. The main risk is relay availability if you depend on the default relay.
- MIT license (Copyright 2017-2025 Zack) imposes no commercial restrictions
- No user accounts, no telemetry mentioned in the README, and the relay source is the same codebase
- Self-hosting a relay is documented via Docker with a published image at docker.io/schollz/croc
- The README explicitly flags that the project's future depends on community sponsorship, so long-term relay hosting is the primary sustainability question
- End-to-end encryption via PAKE (schollz/pake/v3) means the relay cannot decrypt file contents in transit
- Optional Tor proxy support (magisterquis/connectproxy dependency) allows network-level obfuscation
- Docker image runs as USER nobody with a non-root relay process
- No account or registration is required to send or receive files
- The receive code is the only shared secret — if it is intercepted before the transfer completes, an attacker could receive the file instead of the intended recipient
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
Magic Wormhole | You want a mature, Python-based tool with the same PAKE-over-relay concept and a larger contributor base | Free, MIT-licensed |
wormhole-william | You want a Go-based Magic Wormhole client that is compatible with the wormhole protocol but written in Go | Free, MIT-licensed |
rsync over SSH | Both machines have SSH access and you need efficient delta-syncing for repeated transfers | Free, pre-installed on most Unix systems |
Snapdrop | Both devices are on the same local network and you prefer a browser-based AirDrop-style interface | Free, GPL-3.0 |
What this trend reveals
Replace ad-hoc cloud uploads for log sharing
Support engineers and SREs who share multi-gigabyte log bundles with vendors or customers can replace the upload-to-S3-share-a-link pattern with `croc send`, which avoids provisioning storage buckets and automatically encrypts the payload.
Send a test log file with `croc send` and measure total wall-clock time from send to receive against your current S3-upload-plus-link workflow.
Self-host a relay for regulated environments
Organizations that cannot route file transfers through a maintainer-operated relay can deploy the Docker image (`docker run docker.io/schollz/croc relay`) on their own infrastructure, keeping all relay traffic inside their network boundary.
Deploy the relay container, map ports 9009–9013, configure croc clients with `--relay` pointing at the private relay, and confirm a transfer completes.
RepoDaily verdict
croc solves a genuinely annoying problem — moving files between two machines on different networks — with a clean PAKE-encrypted relay model, a single Go binary, and install paths for every major package manager. The MIT license and self-hostable Docker relay keep the adoption risk low. The main caveat is sustainability: the maintainer is upfront about relying on sponsorship, so anyone who adopts croc for repeated use should consider sponsoring or self-hosting the relay.