Lovable login — signing in, and adding login to your app

Part 1 — Signing in to your Lovable account

Go to lovable.dev and choose the same sign-in method you originally used. Mixing methods is the number one cause of "my projects are gone": signing up with Google and later signing in with email creates a second, empty account.

Quick fixes for the common problems:

• No projects visible. You are almost certainly in a second account. Sign out and retry with the other method, checking which email address is shown.
• Magic link never arrives. Check spam, and confirm the address is spelled correctly. Corporate mail filters are the usual culprit; a personal address will get through.
• Stuck in a redirect loop. Clear cookies for the domain, or use a private window. Browser extensions that block third-party cookies commonly break OAuth sign-in.
• Lost access to the GitHub or Google account. Sign-in identity is tied to that provider, so recover the provider account first.

Part 2 — Adding login to the app you are building

This is what most builders actually need. A login screen on its own protects nothing — anyone can request your data directly if the database allows it. Real login is three parts working together.

Step 1: turn on the backend

Ask for it in plain language:

Enable the backend for this project so I can store users and data.

That provisions a database, an authentication service and file storage for your app.

Step 2: ask for the sign-in method you want

Add email and password sign-up and sign-in, plus Google sign-in. Create a /login page and send people to /dashboard after they sign in.

Email and password is the simplest starting point. Google sign-in converts better for consumer apps because there is no password to invent. You can have both.

Step 3: protect the pages and the data

Make /dashboard require a signed-in user. Redirect signed-out visitors to /login. Make sure each user can only read and write their own rows.

That last sentence is the one people skip. Hiding a page in the interface is cosmetic; row-level security in the database is what actually stops one user reading another's records.

A profile table, not the auth table

Store user-facing fields — display name, avatar, plan, preferences — in your own profiles table keyed to the user id. The authentication system's user table is managed for you and is not the place for app data.

Test it properly before you launch

1. Sign up as a brand-new user.
2. Sign out completely.
3. Try to open the protected page directly by typing the URL. You should be redirected.
4. Sign in as a second user and confirm you cannot see the first user's data.
5. Test the password reset email end to end.

Step three and step four are the ones that catch real bugs.

Common login problems and their causes

Symptom	Usual cause
"Unsupported provider"	Google sign-in requested but the provider was never configured
Sign-in works, then instantly signs out	Redirect target is a protected page that loads before the session is ready
Confirmation email never arrives	Email confirmation enabled with no sending domain configured
User signs in but sees no data	Security rules block reads because rows have no owner id

What to build next

Once login works, the natural follow-ups are a user profile page, an admin role for yourself, and per-user data. Ask for roles as a separate table — never as a field users can edit on their own profile, which is the classic way self-built apps get taken over.