How to migrate Lovable Cloud users, with or without password resets
📌 Update, August 31, 2026: Lovable's current documentation says that user passwords from the official project export are not provided in a usable form, so the supported path is to plan a password reset for migrated users.
If avoiding resets matters, Lovable MCP can be tested for access to existing password hashes. On August 31, 2026, I rechecked that capability without exposing any hash value, and Lovable MCP could still detect non-empty password hashes on a Cloud project. MCP is a research preview, so verify this per project and keep the reset path as your fallback.
One of the biggest questions when migrating from Lovable Cloud to your own Supabase is: can my users keep their passwords?
The honest answer now is: not through the official export alone. There is still an advanced MCP route that may preserve existing passwords, but it is a separate, sensitive workflow.
The two paths
| Path | What happens | Best for |
|---|---|---|
| Official export | Migrate users, then ask them to reset their password | Most projects, predictable and supported |
| Advanced Lovable MCP | Copy the existing bcrypt hashes when the project still exposes them | Projects where avoiding resets materially matters |
The official export can run once per day. Do not assume its auth records contain usable passwords just because an older export did.
Why there are two paths
Lovable MCP provides a separate path from the official export. In tests on March 21 and July 6, 2026, I read encrypted_password from auth.users, imported the existing bcrypt hashes into Supabase, and verified that users could log in with the same password.
The key distinction is practical: the official export requires a reset, while the MCP route depends on whether the project still exposes those hashes. Test it before relying on it.
Path A: use the official reset flow
Choose this path when you want the most reliable migration or do not want password hashes passing through an MCP and AI execution context.
- Export and restore the Lovable Cloud project.
- Confirm every auth user and identity exists in the new Supabase project.
- Configure your Site URL, redirect URLs, email provider, and password recovery page.
- Test
resetPasswordForEmailwith one real migrated user. - Only remove Lovable Cloud after the reset and login both work.
This adds one step for users, but it avoids relying on preview behavior.
Path B: preserve passwords through Lovable MCP
Use this only when keeping existing passwords matters enough to justify the extra security handling.
Step 1: run a capability check
Start with a query that returns counts only, never the hash values:
SELECT
count(*) AS total_users,
count(*) FILTER (
WHERE encrypted_password IS NOT NULL AND encrypted_password <> ''
) AS users_with_password_hash
FROM auth.users;
If users_with_password_hash is greater than zero, the route is available for those users. OAuth and passwordless users may correctly have no password hash, so migrate their identities and providers separately.
Step 2: approve the sensitive route
Before reading any hash, understand the tradeoff: the values necessarily pass through Lovable MCP and the agent's execution context.
Do not:
- paste hashes into a chat
- print them in terminal output
- include them in screenshots or logs
- commit them to Git
- leave the export in Downloads or a normal project folder
If your agent cannot keep the migration output protected and out of user-facing responses, stop and use password resets.
Step 3: migrate the minimum fields
The source query for password users is:
SELECT
id,
email,
encrypted_password,
raw_user_meta_data,
raw_app_meta_data,
email_confirmed_at,
created_at
FROM auth.users
WHERE encrypted_password IS NOT NULL
AND encrypted_password <> '';
Ask the agent to perform the transfer without echoing the results:
Migrate my Lovable Cloud password users to my own Supabase.
First run the count-only capability check and show me only the counts.
Before reading hashes, ask for my explicit approval.
Use each existing encrypted_password as password_hash with the Supabase Auth Admin API.
Preserve user IDs and metadata.
Do not display, paste, print, log, or commit any password hash.
Delete any protected temporary artifact after verification.
If any expected password user has no hash, stop and plan a reset for that user.
Supabase supports importing an existing bcrypt hash through auth.admin.createUser:
await supabase.auth.admin.createUser({
id: user.id,
email: user.email,
password_hash: user.encrypted_password,
user_metadata: user.raw_user_meta_data,
email_confirm: Boolean(user.email_confirmed_at)
})
Use a server-side Supabase admin client. Never expose the service role key in browser code.
Step 4: migrate identities and verify
Passwords are only one part of auth migration. Preserve auth.identities, metadata, user IDs, OAuth configuration, and redirect URLs too.
Before removing Lovable Cloud:
- compare source and destination user counts
- compare identity counts
- test one real email and original password
- test password recovery
- delete every protected temporary auth artifact
If the original-password login fails, do not invent a temporary password. Use the reset flow.
What users keep when the MCP route succeeds
- The same user IDs, so foreign keys keep working
- The same emails
- The same bcrypt password hashes
- The same user metadata
OAuth and passwordless accounts still need their provider-specific configuration. A password hash alone does not recreate an OAuth connection.
My recommendation
Use the official export for the database and plan password resets by default. Keep the MCP method as an advanced option for projects where avoiding resets has real value.
The method still helps when avoiding resets matters. Because MCP behavior can change, verify it before every migration and keep the reset flow ready as a fallback.
More resources
Reader margin
What stayed with you?
Leave one small mark in the margin.
Notes from readers
The margin is open. You can leave the first note.
Stuck with something like this? I fix it daily → Services