transfer.sh

Last reviewed Aug 26, 2026 · 852 words

The trap with transfer.sh is that a default deployment is an anonymous, unauthenticated upload endpoint on the public internet, and the public transfer.sh instance was itself shut down partly because of what people uploaded to it. Self-hosting fixes that only if you put a limit on who can write to it. Do that first, and what you get is the most convenient way to move a file off a headless server that exists: one curl command, a short URL back, no client software anywhere.

Why you would run it instead of a file-sync app

Nextcloud and Syncthing solve a different problem: keeping folders in step between machines you own. transfer.sh solves "this 2 GB log bundle is on a box with no browser and it needs to reach a colleague in the next 5 minutes". Nothing else in the file-sync category is as friendly to a shell script, and the whole binary is written in Go, runs in about 64 MB of RAM, and stores files as plain objects in a directory or an S3 bucket. If your use case is phone-to-laptop across a living room, PairDrop or LocalSend are better fits and need no server at all.

A deployment that is not an open drop box

services:
  transfer:
    image: dutchcoders/transfer.sh:latest
    command:
      - --provider=local
      - --basedir=/data
      - --temp-path=/tmp
      - --listener=:8080
      - --purge-days=7
      - --purge-interval=1
      - --max-upload-size=2000000
      - --http-auth-user=me
      - --http-auth-pass=change-this
    volumes:
      - ./data:/data
    ports:
      - "8080:8080"
    restart: unless-stopped

Three of those flags do the safety work. --http-auth-user and --http-auth-pass put basic auth on uploads, so the download links stay shareable but nobody can push files without the credential. --max-upload-size is in kilobytes, so the value above is roughly 2 GB. --purge-days with --purge-interval (in hours) deletes files after a week without a cron job. Put the whole thing behind Caddy for TLS; transfer.sh does not terminate HTTPS itself. For the S3 backend swap --provider=s3 with --s3-endpoint, --bucket, and the access keys, which lets a MinIO bucket hold the objects and gives you lifecycle rules for expiry instead of the purge flags.

The curl one-liners you will actually use

Upload, get a URL back:

curl -u me:change-this --upload-file ./dump.tar.gz https://tx.example.com/dump.tar.gz

The response body is the download URL, so $(curl ...) drops straight into a script or a Slack webhook. Two request headers control the lifetime: -H "Max-Downloads: 1" makes the link single-use and -H "Max-Days: 2" overrides the server purge window for that file, in either direction. Uploading with --upload-file "-" accepts stdin, which is what makes the tool composable: pg_dump mydb | gzip | curl --upload-file - https://tx.example.com/mydb.sql.gz. Add /inline/ before the path on a download URL and the browser renders the file instead of downloading it, which is convenient for a screenshot or a log.

The encryption is client-side, and that is the honest option

The README's encryption example is a pipe through GPG on your side: gpg -ac -o- secret.pdf | curl --upload-file - https://tx.example.com/secret.pdf, and the recipient runs curl https://tx.example.com/.../secret.pdf | gpg -o- > secret.pdf and types the passphrase. The server never sees plaintext, which is a stronger guarantee than any server-side option could give, and it costs one extra command. For anything you would not want on a stranger's disk, use it; a download link is a bearer token and it will end up in chat logs and browser history.

Maintenance reality: expect stillness

The catalogue flags sparse recent development and that matches my experience: releases arrive rarely, issues sit, and the web page the binary serves is a landing page rather than an upload interface. That is tolerable because the surface area is tiny (upload, download, expire) and the Go binary keeps building, but it does mean you should not expect new storage providers or a redesigned UI. If a maintained project with a real browser upload form matters more than curl ergonomics, Picoshare is the closest neighbour; it trades the command-line elegance for a web UI and requires a login for every upload. My WeTransfer replacement notes cover the wider field.

What I'd do

Run the Compose file above on the same host as your reverse proxy, basic auth on, a 7-day purge, and a 2 GB cap. Put the credential in a ~/.netrc entry on the machines you upload from so the command shrinks to curl -n --upload-file. Use Max-Downloads: 1 by default for anything sent to one person and GPG for anything sensitive. Check the container once a quarter for a new tag and otherwise leave it alone; a 64 MB service that has done one job well since 2014 does not need babysitting.