Lovable signup not working

Lovable signup is usually Supabase Auth

Lovable projects that have accounts are almost always calling supabase.auth.signUp from the generated client. The button, the redirect, and the “check your email” screen are app code. Whether an account is created, and whether a confirmation email goes out, is Supabase.

Start in the browser devtools network panel. The call to /auth/v1/signup should return 200. A 400 with “signup disabled” means Email signup is turned off in Supabase Authentication → Providers. A 422 or 400 about the password means the project's password rules were not met.

Confirmation email and the redirect

If “Confirm email” is on, signUp creates an unconfirmed user and sends mail. The app looks broken when that mail never arrives. Use the same SMTP and redirect-allow-list checks as a password reset. emailRedirectTo on the signUp call has to be an allowed URL, or the link in the message will not open your app.

If you turned confirmation off to unblock yourself, say so in the product. Otherwise people create an account, see no email, and try to sign up again. The second attempt returns “user already registered”, which Lovable's generated UI often shows as a generic error.

The profile row after signup

A lot of Lovable apps insert a row into a profiles table from a trigger on auth.users, or from the client right after signUp. If Row Level Security is enabled and the insert policy does not allow that write, signup “succeeds” in Auth and then the next request fails. The user thinks signup is broken.

In the Supabase table editor, open profiles and look at the policies. A typical owner policy is: insert and select where auth.uid() = user_id. A trigger that runs as the table owner can insert without that policy. A client insert cannot. Match the pattern you actually generated.

Also check Authentication → Rate limits if you have been clicking the button a lot from one IP. The error is easy to miss in a toast that only says “something went wrong”.