Migrating to Ploy Auth
Map Supabase Auth and Clerk concepts and APIs to Ploy Auth.
Migrating to Ploy Auth
Ploy Auth covers the common auth building blocks with no separate service to run: users live in a database in your organization and sign-in runs on your app's domain. This page maps the concepts you know from Supabase Auth and Clerk.
From Supabase Auth
| Supabase | Ploy Auth |
|---|---|
auth.users table | ploy_users in your auth database (Users and data) |
auth.identities | ploy_identities |
supabase.auth.signUp({ email, password }) | useAuth().signUp(email, password) or POST /_ploy/auth/signup |
supabase.auth.signInWithPassword(...) | useAuth().signIn(email, password) or POST /_ploy/auth/signin |
supabase.auth.signInWithOAuth({ provider }) | useAuth().signInWithProvider("google") or /_ploy/auth/oauth/google |
supabase.auth.getUser() on the server | currentUser() from @meetploy/nextjs/auth, or env.PLOY_AUTH.getUser(token) |
@supabase/ssr cookie clients and middleware | Built in: the ploy_session cookie is set by Ploy; use authMiddleware |
| Auth UI blocks | SignInForm, SignUpForm or the hosted pages |
| Provider settings in the Supabase dashboard | Dashboard → Auth → Settings |
user_id uuid references auth.users | A user_id TEXT column in your own database; see Referencing users |
Differences to plan for:
- No row-level security. Access rules live in your server code: resolve the user with
currentUser()orPLOY_AUTH, then filter byuser_id. - No cross-database foreign key. Your tables reference users by ID, but the database does not enforce it. Clean up your own rows when you delete a user.
- Not yet available: email verification, magic links, password reset emails, phone sign-in, and MFA.
From Clerk
| Clerk | Ploy Auth |
|---|---|
<ClerkProvider> | <AuthProvider> from @meetploy/auth-react |
<SignIn />, <SignUp /> | <SignInForm />, <SignUpForm /> |
<UserButton /> | <UserButton /> |
<UserProfile /> | <UserProfile /> |
<SignedIn>, <SignedOut> | <SignedIn>, <SignedOut> (client in auth-react, server in @meetploy/nextjs/auth) |
appearance={{ variables }} | appearance={{ variables }} (Theming) |
clerkMiddleware() + createRouteMatcher() | authMiddleware({ protectedRoutes }) + createRouteMatcher() |
auth(), currentUser() | auth(), currentUser() from @meetploy/nextjs/auth |
auth.protect() | protect() |
| Account Portal | Hosted pages on your own domain |
user.publicMetadata | user.metadata, set at sign-up |
Differences to plan for:
- Middleware checks presence, not validity. Clerk verifies sessions in middleware; Ploy's middleware only checks the cookie, so confirm the user with
currentUser()orprotect()in the page. - Not yet available: organizations, MFA, email and phone verification, and impersonation.
Moving existing users
There is no automated import yet. Accounts that sign in with Google, Apple, or GitHub can move without user action: enable the same providers in Ploy and users who sign in with a verified email get a fresh account with the same email.
Password hashes from other providers can't be reused yet. Password users need to create a new password or switch to a passkey or social sign-in.
How is this guide?
Last updated on