Open Source File Uploader — And the Storage Behind It

Search for an open source file uploader and you land on the same shortlist: Uppy, Dropzone, FilePond, react-dropzone, filepond-plugin-*. They are genuinely good software, they are free, and you should probably use one. What none of them ship — because it isn't their job — is somewhere for the bytes to land. An uploader is a UI plus a transport; it needs an endpoint at the other end that stores the file, gives it a URL, and serves that URL fast to whoever asks.

That missing half is what teams underestimate, and it's where the weekend project turns into a quarter of infrastructure work: a bucket, IAM policies, a presigning endpoint, a CDN distribution, cache rules, signed URLs for the private files, a retention story, and a bill with a separate egress meter on it.

So treat this as a layers question rather than a versus question. files.link is not an open source file uploader and does not pretend to be one — it is a commercial, closed-source storage and delivery service with a plain REST API. It ships no widget, no script tag, and no vendor component in your bundle. You keep Uppy or whichever uploader you already like, and it points at an endpoint of yours that speaks to files.link underneath.

The uploader stays yours to style, localize, and version; the storage, the direct file links, and the global CDN across 450+ edge locations stop being your problem.

The wiring is short. Your backend calls POST /v1/files/{folderId} with the file's metadata and gets back a presigned PUT URL plus a file id; the browser PUTs the bytes straight to that URL, so a 2 GB video never streams through your API process; then POST /v1/files/confirm-upload with the id finalizes it and the file is live on a CDN URL. Auth is the raw API key in the Authorization header — no Bearer prefix, no SDK.

For large files there is a real multipart path too: POST /v1/files/multipart/{folderId}/initiate returns per-part presigned URLs, and /v1/files/multipart/complete finishes the job — which is precisely the shape Uppy's @uppy/aws-s3 multipart plugin expects, so the integration is a getUploadParameters function pointing at your own route rather than a rewrite.

In Next.js that route is a handful of lines in an app-router route handler; in React it's whatever fetch call you already make. The API key stays on the server — only the presigned URL reaches the browser.

Be clear about what you don't get, because picking this pairing on a wrong assumption wastes real time. There is no tus support, so Uppy's @uppy/tus resumable-across-sessions transport does not apply here; multipart lets a large upload retry a failed part, which is not the same guarantee. There is no Companion equivalent either — the piece of Uppy's stack that pulls files from Dropbox, Google Drive, or Instagram via OAuth is a server you'd still run yourself.

No on-the-fly image transformations, no virus scanning, and no upload UI of any kind. And files.link is a paid service on prepaid credits: storage, delivery, and API requests draw from one balance that auto-recharges, rather than a free tier. If your requirement is that every layer be auditable open-source code you can self-host, then the honest answer is MinIO or a bucket you own — not this.

What you're buying instead is the thing that's tedious to keep running. Files get permanent direct links that survive renames and folder moves, private files get no public URL at all and are reached through signed links that expire (10 minutes by default, up to 7 days), delivery is CDN-backed by default rather than a distribution you configure, and there's one prepaid balance instead of separate storage, request, and egress meters to reconcile after the month closes.

If you're weighing a hosted widget product instead of an open-source one, the trade-offs are laid out in the Uploadcare, Filestack, UploadThing and Transloadit comparisons — worth noting that Uppy is maintained by Transloadit, so the free uploader and the paid processing backend are already designed as two layers by the same people. Ours is the same split with a different backend.