transfer.sh

TL;DR

• What it is: A Go-based file sharing server you run yourself, designed for command-line file uploads via curl or wget
• Who it’s for: Sysadmins, developers, and power users who want one-line file sharing from the terminal with no third-party dependency
• Cost savings: Free to self-host; replaces commercial file transfer services that run $10–50+/month; beats WeTransfer’s 2GB limit and 7-day retention on free accounts
• Key strength: Single-command file sharing from any terminal — no install, no account, just curl with --upload-file and your file
• Key weakness: The public instance at transfer.sh should be considered gone for practical purposes; you need to run your own, and the project’s maintainer explicitly recommends this

---

What is transfer.sh

transfer.sh is a Go-based file sharing server that you deploy yourself. Upload a file with curl, get back a URL. Share that URL. The recipient downloads the file with curl or a browser. That is the entire product.

The project has 15,810 GitHub stars and is licensed under MIT. It was originally built by Dutch Coders (dutchcoders) and supports multiple storage backends: local filesystem, Amazon S3, Google Drive, and Storj. You run one Docker container, configure a storage backend, and have a private file transfer endpoint.

The simplicity is the point. There is no web dashboard for senders, no account system, no organization features. It is file hosting with an HTTP API. The README demonstrates the core workflow:

Upload a file:

curl -v --upload-file /home/user/hello.txt https://transfer.sh/hello.txt

Get back a URL like https://transfer.sh/1lDau/hello.txt. The recipient downloads it:

curl https://transfer.sh/1lDau/hello.txt -o /tmp/hello.txt

The original public service at transfer.sh has had availability issues over time, and the project’s official maintainer position is clear: “if you want to use the software you should host your own installation.” This review focuses on the self-hosted tool, not the public service.

---

Why people choose it over top alternatives

vs. WeTransfer

WeTransfer is the most commonly cited alternative for non-technical users. It has a clean web UI, 2GB file limit on the free tier, and 7-day retention. It works fine for GUI-based workflows. transfer.sh wins in one specific scenario: when you are already in a terminal, want to share a file with another person in a terminal, and do not want to open a browser. curl --upload-file is faster than any web UI when you are in SSH on a remote server.

vs. Send (formerly Firefox Send)

Send (by Tim Visee, the community continuation of Firefox Send) is the strongest direct alternative. It offers end-to-end encryption, auto-expiring links, and a web interface. AlternativeTo lists it as the best overall alternative, with 84 community likes. The key difference: Send focuses on security with client-side encryption; transfer.sh focuses on command-line simplicity with server-side optional encryption. For sensitive files between non-technical users, Send is the better default. For fast internal file movement where you trust the network, transfer.sh’s simplicity wins.

vs. Wormhole

Wormhole is a peer-to-peer transfer tool — files go directly between sender and receiver without server storage. It supports up to 10GB with end-to-end encryption. The limitation is both parties need to be online simultaneously for the transfer. transfer.sh stores the file and lets the recipient download whenever they choose. For async transfers, transfer.sh is more practical.

vs. SCP/SFTP

For sysadmins, SCP is often the baseline comparison. scp /home/user/report.pdf user@server:/tmp/ works for direct server-to-server transfers. transfer.sh adds a shareable link layer — useful when you want to give a link to someone who does not have SSH access to your server. The use cases are complementary rather than competitive.

---

Features: what it actually does

Upload operations

• Single file upload via curl --upload-file
• Multiple files as a tar archive
• Custom filename via flag
• Generates a unique URL per upload

Download controls

• Max-Downloads header: set a one-time download link
• Max-Days header: set expiration in days
• File expiration via seconds flag
• Direct download link via /get/ URL scheme
• Inline file display via /inline/ URL scheme

Encryption

• Client-side encryption with GPG before upload (recommended)
• Server-side AES256 encryption via X-Encrypt-Password header
• Server-side decryption via X-Decrypt-Password header
• Note from README: server-side encryption should only be used on your own instance

File deletion

• X-Url-Delete response header provides a deletion URL
• DELETE request to that URL removes the file

Storage backends

• Local filesystem
• Amazon S3
• Google Drive
• Storj (decentralized storage)

Web interface

• Basic drag-and-drop web upload interface
• File preview in browser for supported formats

Configuration parameters

• HTTPS redirect, TLS listener, custom listener port
• Force HTTPS, rate limiting
• Max file size, temp path configuration
• Purge days and max age
• VirusTotal integration for file scanning

---

Pricing math

Option	Cost	Limits
transfer.sh (self-hosted)	Free + server cost	No enforced limits (your storage)
VPS for hosting	~$5–10/month	Adequate for personal/team use
S3 storage backend	~$0.023/GB/month	Pay only for what you store
WeTransfer Free	$0	2GB per transfer, 7-day retention
WeTransfer Pro	~$12/month	200GB transfers, 1 year retention
Wormhole	$0	10GB, peer-to-peer
Send (self-hosted)	Free	Configurable limits

For a developer who regularly transfers large files (>2GB) or wants permanent URLs with no third-party dependency, self-hosting transfer.sh on a $5–10/month VPS with local or S3 storage is the most cost-effective path. The engineering overhead is minimal — it is a single Docker container.

---

Deployment reality

The Docker one-liner from the README:

docker run --publish 8080:8080 dutchcoders/transfer.sh:latest --provider local --basedir /tmp/

This starts transfer.sh on port 8080, storing files in /tmp. Files in /tmp do not survive container restarts. For any persistent use, mount a host volume:

docker run --publish 8080:8080 \
  -v /data/transfer:/data \
  dutchcoders/transfer.sh:latest \
  --provider local \
  --basedir /data

For S3 backend (recommended for durability):

docker run --publish 8080:8080 \
  dutchcoders/transfer.sh:latest \
  --provider s3 \
  --aws-access-key YOUR_KEY \
  --aws-secret-key YOUR_SECRET \
  --bucket your-bucket-name

The configuration parameters for production use worth setting:

• --max-upload-size to cap file sizes
• --purge-days for automatic file deletion
• --force-https for HTTPS redirect
• A reverse proxy (nginx, Caddy) for TLS termination

One practical convenience: create a shell alias in ~/.zshrc or ~/.bashrc. Wrapping the curl command so you can call transfer /home/user/report.pdf and receive a URL in return makes it feel native.

The main deployment pitfall is HTTPS. The X-Encrypt-Password feature for server-side encryption is explicitly only safe to use on your own instance over HTTPS. Running transfer.sh on HTTP exposes both file content and encryption passwords in transit.

---

Who should use transfer.sh

Best fit

• Sysadmins and developers who want a private, curl-friendly file endpoint
• Teams that transfer files between servers frequently and want a shareable link layer
• Anyone who wants to self-host a file drop endpoint that colleagues can access without accounts
• Developers who want a simple, lightweight alternative to S3 presigned URLs for internal file sharing
• People building tooling that needs programmatic file sharing (CI/CD artifacts, build outputs, logs)

Not the right tool if

• You need end-to-end encryption for sensitive files — use Send instead
• Your recipients are non-technical users who need a GUI — use WeTransfer or Nextcloud
• You need compliance certifications (SOC 2, HIPAA) — use an enterprise MFT platform
• You need an authenticated upload system where only specific users can send files
• You want a managed service with no operational overhead — just use WeTransfer or FileSend

---

Alternatives worth considering

• Send — Self-hosted, end-to-end encrypted, auto-expiring links. Better security model than transfer.sh, still command-line compatible. Top alternative for security-focused use cases.
• Nextcloud — Full file storage platform. Transfer.sh is a single endpoint; Nextcloud is a full suite with WebDAV, sharing, and collaboration. Overkill if you only need file drops.
• Minio — S3-compatible object storage. More infrastructure-grade than transfer.sh, but gives you an S3 API for programmatic access.
• SFTPGo — Open-source SFTP/FTP/WebDAV server with web UI. Better for structured file transfer with accounts and audit logs.
• oshi.at — A community-noted alternative with “everything that transfer.sh has and more.” Anonymous, self-hostable, Tor-compatible.

Sources

This review synthesizes 5 independent third-party articles along with primary sources from the project itself. Inline references throughout the review map to the numbered list below.

1. [1] tecmint.com (2019-01-15) — “Transfer.sh – Easy File Sharing from Linux Commandline” — deployment (link)
2. [2] 2daygeek.com (2017-05-08) — “Transfer.sh - Easy and Fast Way to Share Files From The Command-Line” — deployment (link)
3. [3] dotlinux.net (2026-03-22) — “Transfer.sh – Easy File Sharing from Linux Commandline” — deployment (link)
4. [4] alternativeto.net (2026) — “transfer.sh Alternatives” — comparison (link)
5. [5] couchdrop.io (2026) — “Managed File Transfer Platforms Comparison” — comparison (link)
6. [6] GitHub repository — official source code, README, releases, and issue tracker (https://github.com/dutchcoders/transfer.sh)

References [1]–[6] above were used to cross-check claims about features, pricing, deployment, and limitations in this review.