Skip to main content
The reference stack ships with MERV_REQUIRE_AUTH=1. Authentication reuses a Supabase Auth project (the same one RapidReview uses, or your own); Merv’s data never lives there.

​
Variables

Keep secrets in managed secret storage; rotate through Supabase and your deployment runbooks.

​
What a verified credential can do

One Authorization: Bearer <credential> header, three shapes: Project membership is the authorization layer: project_members rows decide what a user sees. Creating a project records the creator as its first member; any member can add or remove members (POST /api/projects/{id}/members with user_id or, with a user directory configured, email). Existing databases must contain one membership row per authorized user/project pair before enabling auth. Email sharing also expects the service-role lookup_user_for_share and user_display_profiles RPCs in the auth project.

​
Interactive clients

Nothing changes on the client side: manifests are URL-only, the client gets a 401 from your brain, discovers OAuth (RFC 9728/8414), registers dynamically, and completes PKCE consent in the browser. Point the MCP url at your brain. See Authentication.

​
Notes

  • Under auth, EventSource can’t send the header, so the hosted stream 401s and the UI falls back to ETag polling (~3 s).
  • /api/admin/* is an operator surface — keep it network-restricted even with auth on.
  • Custom identity providers: pass your own user directory to create_fastapi_app(user_directory=…); it must return the same opaque ids as your verifier. See merv/docs/AUTH.md.