Why I built an open source alternative to WeTransfer
It started with client work
I'm a music producer and photographer.
During university, I shared files constantly. These days, most of my time goes into my job as a platform engineer, but back then I was regularly sending photos, music, and other work to clients.
At first, I used Google Drive.
I'd zip up a set of photos, upload it to Drive, and send the client a link. It worked, but my client work ended up mixed in with my personal files.
I could have created a separate Google account, but that still didn't solve something else I cared about: the delivery didn't feel like mine.
Most of my branding lived on the invoice. I wanted the experience of receiving the actual work to feel connected to my brand too.
Then, around 2019, I discovered WeTransfer.
Upload the files. Enter an email address. Send. That was it.
I loved how simple it felt. Sending files didn't feel like managing cloud storage. It felt like delivering something to someone.
Then I started thinking about ownership
Fast-forward to July 2025.
WeTransfer updated its Terms of Service with language that appeared to give it broad rights over uploaded content, including language related to machine learning. The reaction from users was immediate, and the wording was later changed.
For me, though, the episode raised a bigger question. Who ultimately controls the files I send?
At the same time, WeTransfer's pricing had become harder for me to reason about following its acquisition by Bending Spoons.
That left me thinking about a few things:
Can I own my own data? Can sending files to clients still feel delightful? Can I use my own storage? Can the cost be predictable? And can I avoid being locked into a platform whose incentives might change later?
Existing alternatives
There are already good file-sharing tools.
MASV focuses heavily on moving large files. ProjectSend and Erugo provide self-hosted file-sharing platforms. Mozilla also had Firefox Send before shutting it down.
| Tool | How you run it | What it optimises for | Your own storage |
|---|---|---|---|
| WeTransfer | Hosted only | Simple one-off sending | No |
| MASV | Hosted only | Moving very large files fast | No |
| ProjectSend | Self-hosted | A client file platform | Yes, it's your server |
| Erugo | Self-hosted | A WeTransfer-style platform | Yes, it's your server |
| Firefox Send | Shut down in 2020 | Links that expired by themselves | No |
| Campsend | Hosted or self-hosted | The delivery itself | Yes, bring your own bucket |
They solve real problems, particularly around storage and data ownership.
But they weren't quite what I wanted.
MASV is a hosted service, so I can't simply point it at infrastructure I already own. ProjectSend and Erugo are more comprehensive platforms, with features that make sense for teams that need them.
I wanted something smaller and more opinionated.
What I wanted
The requirement was simple:
Send work to a client, make the delivery feel like mine, and keep control of the files.
I wasn't trying to build another cloud drive.
I didn't need deeply nested folders, complex permission systems, SSO, or an enormous analytics dashboard.
I wanted a good delivery experience.
So I built Campsend, an open-source, self-hostable file-sharing service focused on delivery rather than storage management. If you want the short version of what that looks like next to the service I started from, I wrote it up as a WeTransfer alternative for client file delivery.
You can see whether a delivery has been opened or downloaded, customise the branding, bring your own storage, and use Campsend through an LLM.
More importantly, you can run it yourself.
I wanted the application to be simple to deploy, so I built it with Rails 8 and SQLite.
Rails 8 was a particularly good fit for that goal. Its newer defaults make it possible to build applications with fewer external services, which means fewer moving parts for someone self-hosting Campsend.
I'll write separately about the Rails and SQLite decisions, because there's more to say there.
What I learned
The first thing I learned is that storage itself is surprisingly cheap.
While building Campsend, I compared services such as Cloudflare R2 and Amazon S3. Raw storage can cost only a few cents per gigabyte each month, and services such as R2 can make bandwidth costs much easier to predict.
| Cloudflare R2 | Amazon S3 | |
|---|---|---|
| Storage | $0.015 per GB-month | $0.023 per GB-month, first 50 TB |
| Egress to the internet | Free | $0.09 per GB after the first 100 GB a month |
| Free allowance | 10 GB-month of storage | None on Standard |
| 100 GB stored, 100 GB delivered | $1.50 a month | $2.30 a month, plus egress |
The last row is the one that changed how I thought about file-sharing pricing. Storage is a rounding error either way. What varies is what happens when somebody actually downloads the file, and on R2 that part is free.
The second thing I learned is that Rails made this much simpler than I expected.
Authentication, background jobs, database access, storage abstractions, email, and most of the boring application plumbing already had good solutions.
That meant I could spend more of my time on the part I actually cared about: making file delivery reliable and pleasant.
And the final thing I learned is that file sharing doesn't need to become file management.
Sometimes you don't need another workspace.
You don't need fifteen permission levels. You don't need a new folder hierarchy.
You just need to send someone the work.
That was the experience I liked about WeTransfer in the first place, and it's the experience I want Campsend to preserve, while giving you more control over where your files live.
Campsend is open source, and you can either try it or run it yourself from GitHub.
If you build with it, self-host it, or find something that should work differently, I'd love to hear about it.