Supabase auth removed; Clerk takes over login and session management

zgbrenner replaces Gary's hand-rolled Supabase auth UI with Clerk, motivated by deployment fit rather than feature gaps. The old login system is gone; the data layer stays on Supabase. There's an explicit incomplete backend piece left for a follow-up PR.

securityinfrastructure

The scope was deliberately tight: authentication only. No billing, organizations, RBAC, invitations, or multi-tenant isolation. The /login and /signup routes are preserved as URLs but now render Clerk's hosted components. Clerk's middleware handles route protection at the Next.js layer.

Rather than rewriting the roughly fifteen components that consumed the old auth context, zgbrenner kept the existing auth hook signature and reimplemented it as a compatibility shim backed by Clerk. Eight backend-calling files route through a single shared helper that attaches the Clerk session token. The sidebar account dropdown swaps to Clerk's <UserButton>. The Supabase client, Supabase auth libraries, and their frontend dependencies are deleted. React is bumped to satisfy Clerk's peer requirement.

The important caveat is that this is app-level protection only. Gary is treated as effectively single-user. The Express backend still verifies Supabase JWTs and does not yet validate Clerk tokens. The frontend already sends the Clerk session token, so data-accessing features currently depend on the documented next step: swap backend auth middleware to verify Clerk JWTs via Clerk's JWKS endpoint and map the Clerk user ID onto the existing data model. Until that follow-up merges, the auth chain is split.

The test plan noted a clean build and passing auth tests, with manual sign-in verification deferred since it requires real Clerk keys. Env files and docs are updated with the new variables and warnings to distinguish pk_... (publishable, browser-safe) from sk_... (secret, never prefix with NEXT_PUBLIC_).

So what Worth a look if you want Clerk over Supabase Auth and are running Gary as a single-user or small-team tool. The compatibility shim approach (preserve the hook signature, swap the backing implementation) reduces blast radius for the frontend change. But you'd need to also land the backend JWT verification follow-up before this is production-complete - the split auth chain is a real gap.

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 zgbrenner/gary, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
aa9602ce feat: replace Supabase auth with Clerk Claude 2026-05-20 ↗ GitHub
commit body
Swap Gary's built-in Supabase login/signup flow for Clerk so the app can
run as a protected one-person web app on Vercel.

- Add @clerk/nextjs; wrap the root layout in ClerkProvider
- Add Clerk middleware (proxy.ts) that protects every route except
  /login and /signup
- Render Clerk SignIn/SignUp at the existing /login and /signup URLs
- Back the useAuth() compatibility hook with Clerk instead of Supabase
- Replace the sidebar account dropdown with Clerk UserButton
- Send the Clerk session token on backend requests via a shared helper
- Remove the Supabase client, JWT helper, and @supabase/* frontend deps
- Document Clerk env vars and setup in the env examples and docs

The separate Express backend still verifies Supabase JWTs; swapping it to
verify Clerk tokens is a documented follow-up.

https://claude.ai/code/session_018GMAE164ehpBTxzBdsof9r

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-568.md from inside the repo you want the changes in.

⬇ Download capture-thread-568.md