A transfer.sh Alternative (Hosted)

transfer.sh is a lovely piece of software: one Go binary, curl a file in, get a URL back, share it. Its whole appeal is that single curl command and the option to self-host. The catch is the same as any self-hosted service — you own the server, the storage backend, the TLS certs, the patching, the monitoring, and the bandwidth bill. The public transfer.sh instance has also been intermittently up and down over the years, so workflows pinned to it have broken in CI without warning. files.link is the hosted answer for people who want the curl-and-link ergonomics without running infrastructure.

You don't get a literal one-liner — uploads take three authenticated calls: POST /v1/files/{folderId} returns {success, urls:[{url,id,...}]}; you PUT the bytes to that presigned URL; you POST /v1/files/confirm-upload with {ids:[...]}. In exchange for the extra two calls you get API-key auth (raw key in the Authorization header, no Bearer prefix), per-account quotas so a random script can't run up your bill, and global CDN delivery instead of single-origin downloads from wherever your box happens to live.

The migration is mostly about who runs the box. If you had a self-hosted transfer.sh behind nginx, you can decommission the VM, the cert renewal cron, and the storage volume, and replace curl --upload-file ./file https://transfer.sh/file with a tiny three-step shell function that registers, PUTs, and confirms. If you were leaning on the public instance in a pipeline, you swap an unreliable free endpoint for a funded prepaid account that won't vanish mid-run.

Be honest about what you give up. Self-hosting transfer.sh keeps every byte inside infrastructure you control, which matters for data sovereignty, air-gapped environments, or pure principle — files.link is a hosted service, so your data lives with our cloud infrastructure provider, not on your hardware. transfer.sh is also open source, so you can audit and patch it; files.link is a commercial service you trust rather than read.

Pick self-hosting when control and auditability outrank convenience. Pick files.link when you'd rather pay for usage than pay for the hours you'd otherwise spend being a part-time sysadmin for a file-sharing box.