Why I open-source storage libraries

The first time I built a resumable upload flow, it took two weeks. The second time, one. The third time, I extracted it into a library and called it resumable-s3-multipart-upload. The fourth time, I imported the library and moved on to the actual product.

The pattern

Every small product team I've worked with has needed the same five things:

• Resumable uploads for files larger than the user's patience.
• Signed URL access for files that shouldn't be public.
• Adapter-based adapters so the storage layer isn't glued to one vendor.
• Audit-friendly access logs so you can answer "who downloaded this and when."
• Guest flows that don't require a full account to recover access.

These are not novel problems. They're not even interesting problems. They're the unsexy middle layer that every team rebuilds slightly differently and usually gets slightly wrong.

What the libraries do

I split them into three concerns, not because the code demands it but because the failure modes are different:

1. resumable-s3-multipart-upload — bytes in.
2. protected-download-gateway — bytes out, behind authorization.
3. customer-access-portal — the layer that says "yes, this email can see this invoice" without inventing a new auth system.

Each one is adapter-based. Each one ships Vitest coverage. Each one documents the production concerns (CORS, abandoned upload cleanup, MIME validation, auth scoping) that nobody mentions in the README.

What they're not

They're not a framework. They're not a platform. They're not trying to compete with UploadThing or Mux or any of the well-funded options. They're the code I would have wanted to copy-paste two years ago, packaged so the next person can copy-paste it too.

If you're rebuilding the same flow for the third time, see the projects page.