Clerk replaces Supabase Auth across the full stack; Supabase takes over storage
zgbrenner replaced Gary's Supabase Auth with Clerk across both the frontend and backend, and consolidated the data layer on Supabase so the fork can run without any Cloudflare dependency. The migration spans six commits and rewrites auth middleware, session verification, identity lookup, account deletion, and the object storage configuration.
The frontend half landed in aa9602ce. Custom login/page.tsx and signup/page.tsx (about 285 and 131 lines respectively) were deleted and replaced with Clerk's catch-all login/[[...rest]] and signup/[[...rest]] routes. AppSidebar was rewritten for Clerk sessions, and mikeApi.ts was updated to pass Clerk session tokens to the backend. The .env.local template swaps two Supabase variables for six Clerk ones.
The backend half landed in a7ea67d0. The requireAuth middleware in backend/src/middleware/auth.ts now verifies Clerk session JWTs via @clerk/backend (version 3.4.11, see bun.lock), with a new backend/src/lib/clerk.ts holding the Clerk client. The resolved Clerk user id flows to res.locals.userId, and downstream ownership checks see the same id the frontend uses - the commit notes this as the key payoff, since existing row.user_id === user.id comparisons stay correct. Email resolution moved from Supabase's auth admin API to a Clerk API lookup with a short-lived cache; a missing email is non-fatal and yields no shared items rather than an error.
The schema changes follow from the identity switch. Clerk user ids are not UUIDs, so columns previously referencing auth.users were relaxed to plain text. The Supabase Auth trigger that auto-created profiles on sign-up was dropped; the backend's lazy profile creation handles that instead. Account deletion now calls the Clerk API to remove the user alongside the database cleanup.
Storage also moved in the same pass. The R2_* environment variables were replaced with generic S3_* variables, and Supabase Storage (which exposes an S3-compatible endpoint at https://<project-ref>.supabase.co/storage/v1/s3) becomes the recommended bucket. The existing AWS SDK client code works unchanged - only the env var names changed. A new docs/SUPABASE_SETUP.md covers the storage configuration steps.
d6f10f71 added docs/SETUP_PROGRESS.md tracking the migration state. At the time it merged, Clerk auth was working end to end and Vercel was deployed, but the Supabase database and backend deploy were still pending. That file is marked as a scratchpad to delete once setup is complete. Verify whether it's still present in the version you're evaluating; if it is, the deployment may not have been fully tested.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?