adamwolfe2 picks a lane on storage

The fork drops its dual storage setup and commits fully to Supabase for file handling.

infrastructure

Until now, adamwolfe2's fork could store documents on either Amazon's S3 or Cloudflare's R2 - two competing cloud storage services that the upstream codebase juggled side by side. This change rips out that flexibility and routes everything through Supabase Storage, the file-handling arm of the same backend platform the fork already uses for its database.

The pitch is operational simplicity: one set of credentials, fewer moving parts, two fewer external dependencies to maintain. The trade-off is that anyone running this fork on Cloudflare's infrastructure no longer has a path - it's Supabase or nothing. The team has clearly decided that supporting both was costing more than it was worth.

So what Legal-tech operators evaluating Mike forks should note this one is now firmly in the Supabase ecosystem, which simplifies hosting but narrows deployment options.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from adamwolfe2/mike-amcollective, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
0c77543c refactor: replace S3 SDK with Supabase Storage JS SDK adamwolfe2 2026-04-30 ↗ GitHub
commit body
Eliminates S3 credentials requirement (dashboard-only, no API).
Uses @supabase/supabase-js (already installed) with SUPABASE_URL +
SUPABASE_SECRET_KEY - both already set as Fly secrets.
All public API (uploadFile, downloadFile, deleteFile, getSignedUrl,
key helpers) is preserved unchanged.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-91.md from inside the repo you want the changes in.

⬇ Download capture-thread-91.md