File sharing for people

A transfer.sh alternative with no service to run

Terminal-first sharing, a short secret to hand over, and an expiry. Both are happy to store the object in an S3 bucket.

What transfer.sh is

In its own terms.

A file-sharing service you drive with curl: PUT a file, get a URL back, share it. Written in Go, self-hostable, with pluggable storage backends that include S3. The public instance made it famous; the self-hosted server is what teams actually run.

Side by side

Where they part ways.

	s3nd	transfer.sh
What it is	A CLI, a library and React hooks over your own S3 bucket	Self-hostable upload service with links
Where the data lives	Your bucket: S3, R2, MinIO, Scaleway, Wasabi	Its server’s storage; an S3 backend is available
Both ends online at once	No. The code is redeemed later, until it expires	No
From inside your web app	Yes, through one route on your server	By URL
Accounts	None. The code is the whole handshake	None
Hosting	Your bucket, plus your server when a browser takes part	Self-hosted
Price	Free. You pay your storage provider for a few objects that expire	Free
License	MIT	MIT

The differences

What actually changes.

A server you run versus a bucket you have

transfer.sh is a service in front of storage. The s3nd CLI is the bucket with no service in front; when you do want a server, it is a route inside the API you already deploy.

A URL versus a code

A transfer.sh link carries a random path that is the secret. An s3nd code is eight characters designed to be read aloud, with the confusable letters removed and repaired on the way back.

Files versus files and state

transfer.sh moves files. s3nd moves files and snapshots of application state, with schema versions and conditional writes, from a library as well as a command.

The decision