transfer.sh Alternative: The Same curl -T Upload, Still Working in 2026

Change the hostname and your old transfer.sh command works again. Same curl -T, no key, no signup:

$ curl -T yourfile.zip https://ul.sto.care
{"url":"https://dl.sto.care/mjrxiq1odb","expiresAt":"2026-10-04T20:19:21.615Z"}

The only difference you have to handle is the response. transfer.sh printed a bare URL; ul.sto.care returns JSON. If a script consumed that output, pipe it through jq -r .url and you are done. Everything below is detail.

What transfer.sh actually does today

I tested it rather than guessing. On 1 October 2026 at 21:06 UTC, both a plain GET and a curl -T upload to transfer.sh failed to connect. Exact output:

# Run on 1 October 2026, 21:06 UTC
$ curl -sS --max-time 20 -o /dev/null -w 'http_code=%{http_code}\n' https://transfer.sh
curl: (7) Failed to connect to transfer.sh port 443 after 297 ms: Couldn't connect to server
http_code=000

$ curl -sS --max-time 20 -T yourtest.txt https://transfer.sh/test.txt
curl: (7) Failed to connect to transfer.sh port 443 after 243 ms: Couldn't connect to server

# DNS still resolves. Nothing is listening.
$ dig +short transfer.sh A
144.76.136.153
$ curl -v https://transfer.sh 2>&1 | grep refused
* connect to 2a01:4f8:200:1097::2 port 443 ... failed: Connection refused
* connect to 144.76.136.153 port 443 ... failed: Connection refused

That is curl exit code 7, not a 404 or a 503. DNS still publishes an A and an AAAA record, so the domain looks healthy to a registrar check, but nothing accepts a TCP connection on 443 or on 80. From your script's point of view the upload hangs for a moment and then dies with "Couldn't connect to server."

This is not new. transfer.sh posted a shutdown notice on Hacker News in 2018, came back, and has been intermittently reachable ever since. That pattern is the real problem. A service that is up most of the time is fine for a manual share and bad for a cron job, because the failure shows up as a broken pipeline on a Tuesday rather than as a clear end-of-life announcement you can plan around.

One thing worth separating: the project is not dead, the hosted instance is unreliable. The source at github.com/dutchcoders/transfer.sh has roughly 15.9k stars, is not archived, and had commits as recent as 28 September 2026. If you liked transfer.sh because of what the code does, self-hosting is a real option and I cover it below.

Migrating a script

Two edits. First, the hostname, and drop the trailing filename path segment: ul.sto.care takes the name from the local file, so https://transfer.sh/report.pdf becomes just https://ul.sto.care. Second, parse the JSON.

# Before: transfer.sh printed a bare URL
LINK=$(curl -sT "$1" https://transfer.sh/"$(basename "$1")")

# After: ul.sto.care returns JSON, so pull .url out
LINK=$(curl -sT "$1" https://ul.sto.care | jq -r .url)

Most people have this buried in a shell function copied off a blog post years ago. Here is the drop-in version, including a jq-free fallback for machines where you cannot install anything:

# Drop-in replacement for the classic transfer() helper
transfer() { curl -sT "$1" https://ul.sto.care | jq -r .url; }

$ transfer build.tar.gz
https://dl.sto.care/mjrxiq1odb

# No jq on the box? grep it out instead.
transfer() { curl -sT "$1" https://ul.sto.care | grep -o 'https://dl[^"]*'; }

If the string is scattered across a repo, CI config, Makefiles and docs, do it in one pass:

# Preview which files mention transfer.sh
$ grep -rln 'transfer\.sh' .

# Swap the domain everywhere, in place
$ grep -rl 'transfer\.sh' . | xargs sed -i 's|https://transfer\.sh|https://ul.sto.care|g'

# macOS sed needs an empty backup suffix
$ grep -rl 'transfer\.sh' . | xargs sed -i '' 's|https://transfer\.sh|https://ul.sto.care|g'

Run the grep -rln first and read the list. A blind sed -i across a repo will happily rewrite prose in your README and strings in your test fixtures too.

Piping from stdin keeps working, which is the other thing people relied on. The edge buffers the body and supplies the Content-Length, so a streamed body is accepted:

# Piping works, same as it did with transfer.sh
$ pg_dump mydb | curl -T - https://ul.sto.care
{"url":"https://dl.sto.care/mjrxiq1odb","expiresAt":"2026-10-04T20:19:21.615Z"}

The full curl upload guide has more recipes, including a CI step that publishes a build artifact.

What you lose, what you gain

Being straight about this matters more than winning a comparison.

What you lose

• Per-upload expiry control. transfer.sh accepted Max-Days and Max-Downloads request headers. sto.care has no equivalent. Every curl upload expires after 72 hours and allows 10 downloads, full stop.
• Large uploads on the API. The curl endpoint caps at 100 MB. transfer.sh advertised much more. For bigger files the sto.care web app handles up to 25 GB with 7-day links, but that is a browser flow, not a one-liner.
• Built-in encryption and the extras. transfer.sh had optional password encryption, a virus scan hook, and tar or zip bundling of multiple files. sto.care does none of that. Encrypt before upload if you need it.
• Self-hosting. transfer.sh is open source and you can run your own. sto.care is a hosted service only.

What you gain

• It answers. That is the entire pitch. The command in the first code block is a real captured response, not a doc sample.
• Machine-readable output. JSON with url and an ISO 8601 expiresAt beats scraping a bare URL out of stdout, and errors come back as {"message": "..."} with a sane status code.
• Still no account. No key, no token, no email. 10 uploads per IP per UTC day is the only gate.

The other routes

Self-host transfer.sh

The honest best answer if you want Max-Days, Max-Downloads, your own storage backend and no third party in the path. It is a Go binary with a Docker image, and the cost is that you now operate a server with a public upload endpoint on it.

# The code is still maintained: 15.9k stars, last push 2026-09-28
$ git clone https://github.com/dutchcoders/transfer.sh
$ docker run -p 8080:8080 dutchcoders/transfer.sh:latest \
    --provider local --basedir /tmp/

# Check the repo README for current flags and storage providers.

0x0.st

Community-run, 512 MB cap, retention scaled by file size up to about a year. Better than sto.care when your file is between 100 MB and 512 MB or you need the link to outlive 72 hours. It uses curl -F multipart, not curl -T, so it is not a drop-in swap for a transfer.sh script. It is also a hobby project funded by donations, so do not build a production pipeline on it. See the 0x0.st comparison for the detail.

filepost and the commercial APIs

These work and they are reliable, but every one of them starts with "sign up and get a key." If you were using transfer.sh precisely because there was nothing to sign up for, a key is a real cost: it is a secret to store, rotate and leak in CI logs.

# 0x0.st: multipart form, not curl -T, 512 MB cap
$ curl -F '[email protected]' https://0x0.st
https://0x0.st/aBcD.pdf

# filepost and most commercial APIs want a key first
$ curl -H 'Authorization: Bearer YOUR_KEY' -T report.pdf https://example-api/upload

file.io belongs in the same bucket and has its own history of changing terms; the file.io comparison walks through what moved.

FAQ

Is transfer.sh down?

On 1 October 2026 at 21:06 UTC it refused connections on both 443 and 80 while still resolving in DNS, and curl exited 7. It has been intermittent for years rather than cleanly dead, so test before you assume your script is at fault: curl -sS --max-time 20 -o /dev/null -w '%{http_code}' https://transfer.sh.

What is the best transfer.sh alternative for curl -T?

curl -T yourfile https://ul.sto.care. Same flag, no key, no signup. 100 MB per file, 10 uploads per IP per UTC day, links live 72 hours, 10 downloads each. Add | jq -r .url where your script expected a bare URL.

Does sto.care support Max-Days and Max-Downloads?

No. Expiry is fixed at 72 hours and downloads are capped at 10 per file, with no header to change either. If per-upload control is a requirement, self-host transfer.sh instead.

Can I still self-host transfer.sh?

Yes. The repo is active, not archived, and had commits in late September 2026. The hosted instance being unreachable says nothing about the code.

What about files bigger than 100 MB?

Use the sto.care web app, which takes up to 25 GB and keeps links alive for 7 days, free and with no account. Or use 0x0.st up to 512 MB from the terminal.

Swap it and move on

One line, and the thing you had working in 2019 works again:

$ curl -T yourfile.zip https://ul.sto.care
{"url":"https://dl.sto.care/mjrxiq1odb","expiresAt":"2026-10-04T20:19:21.615Z"}

Every status code, limit and error shape is in the open upload API docs. No key to request first.