Moving Supabase Auth off Lovable without breaking every session

You built on Lovable, it wired up Supabase Auth for you, and now you’re moving your backend but you’re terrified of the auth part. One wrong step and every logged-in user gets kicked out, or worse, can’t log back in at all. That fear is correct. Auth is the one piece where a sloppy migration is immediately visible to every user. Here’s how to move it without the mass logout.

Why this happens

When Lovable sets up auth, it uses Supabase Auth (GoTrue) under the hood. Your app trusts tokens that Supabase signs. Users’ passwords are stored hashed in Supabase’s auth.users table. Active sessions are tokens already sitting in your users’ browsers, signed with a secret only Supabase knows.

That last part is the trap. A session isn’t a database row you can copy. It’s a signed token already out in the world. If you move to a system that signs tokens with a different secret, every existing token instantly becomes invalid, because the new system can’t verify a signature it didn’t make. That’s the mass logout. Everyone gets bounced at once, and if password hashes didn’t come along cleanly, some can’t even sign back in.

So there are really two things to preserve, and people conflate them:

1. Users (identities and password hashes) so people can log in.
2. Sessions (already-issued tokens) so people don’t have to log in right now.

You can almost always preserve the first. The second depends heavily on which path you take. Being clear-eyed about that up front saves you a bad surprise.

How to fix it

First, decide where auth is going. There are three realistic destinations, and they trade off differently.

Option A: keep Supabase Auth, move only the database.

If your real goal is control over your data, you don’t have to move auth at all. You can keep Supabase Auth exactly as-is and only migrate the application data to your own Postgres. Auth keeps signing the same tokens with the same secret, so no sessions break and no users are disrupted. This is by far the lowest-risk path, and often the right one. Move the hard, scary piece last, or not at all.

Option B: move to a managed auth provider (Auth.js, Clerk, or similar).

You get a polished auth system you don’t operate. The cost is that existing Supabase sessions won’t survive, because the new provider signs tokens differently. You can migrate the users (import the password hashes if the provider supports the same hashing, or trigger a one-time password reset if not), but everyone will have to log in again once. Plan for that as a known, communicated event, not an accident.

Option C: self-host GoTrue (the same engine Supabase uses).

This is the only path that can preserve sessions, because GoTrue is the same software signing tokens the same way. If you run your own GoTrue with the same JWT secret and import the auth.users table, existing tokens keep verifying and nobody gets logged out. The cost: you now operate an auth server, including its security patches and uptime. More control, more responsibility.

Here’s the decision in short:

Just want your data controlled?      -> Option A (keep Supabase Auth)  [lowest risk]
Want managed auth, ok with 1 relogin -> Option B (Auth.js / Clerk)
Must keep sessions, will run infra   -> Option C (self-host GoTrue)

Whichever path, do these steps.

Step 1, export the users first, always. Before touching anything, get a copy of the auth users out:

pg_dump "$SUPABASE_DB_URL" \
	--table='auth.users' --table='auth.identities' \
	--format=custom --file=auth-backup.dump

That’s your safety net. If anything goes wrong, you still have every identity and hash.

Step 2, for Option C specifically, reuse the JWT secret. This is the whole trick for keeping sessions. The new GoTrue must sign and verify with the same secret Supabase used, so tokens already in browsers stay valid:

GOTRUE_JWT_SECRET=<the-exact-secret-from-supabase>
GOTRUE_JWT_EXP=3600

Different secret, every session dies. Same secret, they survive. There’s no middle ground here.

Step 3, keep the old system warm for rollback. Don’t shut Supabase Auth off the moment the new one is live. Leave it running and reachable for a week or two. If the new auth misbehaves, you can point the app back at Supabase and fix things without your users noticing. Tearing down the old system on day one removes your escape hatch exactly when you’re most likely to need it.

Step 4, test with a real second account before cutting over everyone. Create a test user on the old system, migrate, and confirm that account can still log in on the new one. Prove the path works on one user before you run it on all of them.

Step 5, if a mass relogin is unavoidable (Option B), tell users before it happens. A short “you’ll need to log in again after our upgrade” email turns a scary “why am I logged out” moment into an expected one. Silence is what makes it feel like a breach.

Or, we do it for you

Auth migrations are the highest-stakes part of moving a Lovable app, which is exactly why they’re a core part of our rescue work: we keep sessions where we can, migrate users cleanly, and keep the old system warm for rollback. See our rescue service for how we handle it.

FAQ

Will all my users get logged out when I move auth?

Only if the new system signs tokens with a different secret than Supabase did. If you keep Supabase Auth and only move your data, nobody’s logged out. If you self-host GoTrue with the same JWT secret, sessions survive. If you switch to a different provider like Clerk, expect a one-time relogin, and warn users first.

Can I keep users’ passwords so they don’t have to reset?

Usually yes. Password hashes live in Supabase’s auth.users table and can be exported. If the destination uses the same hashing scheme, you import them and passwords keep working. If it uses a different scheme, you fall back to a one-time password reset for everyone, which works but is more disruptive.

What’s the safest way to do this?

Move your data but keep Supabase Auth in place (Option A). It carries almost no user-facing risk because auth never changes. If you must move auth too, self-hosting GoTrue with the same JWT secret preserves sessions, and keeping the old system warm for rollback protects you if something goes wrong.

How long should I keep the old auth system running?

At least a week or two after cutover. That window is your rollback path. If the new auth has a problem, you can switch back with minimal user impact while you fix it. Shutting the old system down immediately throws away that safety net right when the risk is highest.