How to replace Replit Auth with authentication you control

Replit Auth lets an app sign people in with Replit accounts and no setup. That’s the convenience and the dependency: the identities live with Replit. Replacing it is easy on a new site and delicate on a live one, and the difference is entirely about keeping existing users able to sign in. This guide keeps those two cases apart.

Published September 14, 2026 · About a 11 minute read · Last reviewed September 2026

Does your app use Replit Auth?

Open the project in Replit and look for the Auth tool. Replit’s documentation lists exactly two sign-in options: Replit Auth and Clerk. If the Auth pane shows a Users tab listing everyone who has signed in, with a Configure tab for the login screen’s name, icon, providers and session secret, and your app’s login page is Replit-branded, the app uses Replit Auth. If the pane instead talks about a Clerk tenant, test and live Clerk keys, and a proxy, the app uses Replit-managed Clerk, which this guide covers too. If you can’t tell, ask the agent in the project which authentication system the app uses; Replit’s docs don’t publish package or route names to look for in the code.

What the dependency is

In plain English: with Replit Auth, your users don’t have accounts on your site. They have Replit accounts, and your site lets Replit accounts in. Replit’s documentation says so directly: when someone signs in to your app, they are creating or using an existing Replit account, on a Replit-branded login page, through the same flow used across replit.com and Replit’s own shared sign-in apps for Google, GitHub, Apple, X and email. Replit sends the password reset emails, keeps the sessions, and, as a side effect, adds anyone who signs up to your Replit referrals.

That’s why it needs no setup and why it can only be set up by Agent. It’s also why it can’t leave Replit: the identities belong to Replit’s account system, not to your app. Replacing the sign-in code is straightforward. Keeping the same people able to sign in afterwards is the whole problem, and it’s the subject of most of this guide.

What user data exists, and what you can get out

Data	Where it is	Can you get it out?
The list of users: name, last sign-in, details, activity	Replit’s Auth pane	Viewable and searchable. Replit documents no export or download of this list.
User rows in your own database	Your app’s Postgres database	Yes. Replit Auth automatically creates user entries in your database, and the database itself can be dumped, as the Replit ownership guide describes. What those rows contain depends on what Agent built.
Passwords	Replit’s account system	Not documented. Replit Auth users sign in with Replit accounts and Replit handles password resets; nothing in Replit’s documentation describes per-app passwords or exportable password hashes. This guide assumes none are available.
Google, GitHub, Apple and X identities	Replit’s shared OAuth apps	Not transferable. The consent was given to Replit’s app, not yours. Those users can sign in again with the same provider through an app of yours, and be matched by email.
Active sessions	Replit	No. Any change of system ends them; everyone signs in again.

Two very different situations

A site with no real users yet. Replacing the authentication is a code change. Nothing needs preserving. Do it before launch, on a branch, and the rest of this guide is mostly about doing it cleanly.

A live site with existing accounts. Now you’re changing the lock on a building people live in. Every user will have to establish themselves with the new system, and if the switch is done in the wrong order, some will be locked out, some will end up with duplicate accounts, and orders or data tied to their old identity may be orphaned. Everything below applies, the cautions are real, and the right answer for a busy site is to run both systems for a period rather than switch overnight.

What Replit’s documented migration does, and doesn’t

Replit documents one migration: Agent moving an app from Replit Auth to Clerk Auth. According to Replit, it moves your Replit Auth user data to Clerk, including account identity details and supported sign-in credentials; waits for that to finish; then updates the app’s sign-in and session code, restarts, and runs checks. It changes only the authentication code, not your database data or schema. Replit says to expect ten minutes to an hour, longer for many users, and to run it as a fresh task without touching auth code meanwhile. It doesn’t say whether it can be reversed, exactly which credentials count as “supported”, or what happens to signed-in sessions.

The destination matters. Clerk Auth on Replit means a Replit-managed Clerk tenant: Replit provisions a separate Clerk application for your app, owned by your app and managed by Replit. Your users get accounts in your app rather than Replit accounts, which is a real improvement. But you have no Clerk account for it, the tenant isn’t exposed in the Clerk dashboard, its keys are secrets Replit tells you not to edit, and billing, currently free with no user cap, goes through Replit. Clerk’s own user export, which includes hashed passwords, is a dashboard feature, so a Replit-managed tenant doesn’t give you that route either.

Moving from the managed tenant to a Clerk app of your own is documented only as: delete the Replit-managed Clerk app from the Auth pane’s Configure tab, which removes the tenant and releases its domains, then wire up your own; and Replit’s help pages say switching to your own instance requires a manual step through Replit Support. No documented path moves users from Replit Auth, or from a Replit-managed tenant, into a Clerk app you own. Ask support what they can do before you delete anything.

The hard part is usually the users, not the login screen

Swapping an authentication SDK is a day of developer work: new sign-in pages, new session handling, new checks on protected routes. Clerk, Supabase Auth and others all have this well documented. What no SDK can do is recreate credentials it never held. A user is an identity plus a way to prove it. The identity, usually an email address, you can carry across. The proof, a password hash or an OAuth consent, is what you don’t have from Replit Auth. So every migration off Replit Auth comes down to one of two things for each user: they set a new password through a reset email you send from the new system, or they sign in with the same Google, GitHub, Apple or X account through your own provider setup and are matched to their existing record by email. Plan for both, and plan for the email you’ll send explaining it.

Clerk, if that’s the destination, documents the mechanics for a system that does hold credentials: its Backend API can create users with an existing password hash in any of a long list of formats, can create users without a password so they set one, and Clerk provides a tool that imports a CSV or JSON list of users within its rate limits. It also documents the trickle approach: keep both systems running, move users as they sign in, and cut over fully later. Clerk is explicit that switching systems will likely end active sessions. For Replit Auth, the import is identities without credentials, which is the “set a password” path.

The safe sequence to authentication you control

Inventory. Which providers are enabled, how many users, which tables reference the user id, what a user can see or do when signed in. Ask the agent to list every place the code checks the signed-in user.
Back up. Dump the production database, so the user rows and everything keyed to them exist outside Replit. Screenshot the Auth pane’s user count.
Verify ownership. The repository is under your GitHub account and you can deploy it somewhere; see the Replit ownership guide. Auth is the last dependency, not the first.
Create the replacement. An auth provider account in your own name. With Clerk: a development instance to build against (capped at 100 users, with no transfer to production), then a production instance, which needs a domain you control, DNS records Clerk lists on its Domains page, and your own OAuth credentials for each social provider; Clerk’s shared development credentials aren’t allowed in production. Clerk’s free tier covers 50,000 monthly retained users.
Implement on a branch. A developer or agent replaces the sign-in code and adds a “migrated” marker to user records. Keep the old user ids in a column, which Clerk suggests as an external id, so orders and data stay attached.
Decide how each user re-establishes themselves. Email users: import their identities into the new system without passwords and trigger a reset, or have them use “forgot password” on first visit. Social users: enable the same providers under your credentials and match by email on first sign-in. Decide what happens to an email that exists in your database but hasn’t re-registered.
Run both, if the site is live. Keep Replit Auth working while the new system is reachable on the same domain, and move users as they sign in, the trickle approach. For a small or quiet site, a dated cutover with an email warning is acceptable; for a busy one, it isn’t.
Test, per the section below.
Cut over. Deploy the branch, update deployment secrets, republish. Expect every session to end.
Verify sign-in, sign-up, reset and social login on the real domain, and that migrated users see their own data.
Only then remove Replit Auth from the app, and, if you had a Replit-managed Clerk tenant, delete it from the Configure tab. Both are one-way.

Variables, redirects and deployment

Secrets. The new provider’s publishable and secret keys go into Replit’s Secrets pane for development and, separately, into deployment secrets for the published app; Replit keeps the two stores apart and a change to one doesn’t update the other. Test keys (pk_test_, sk_test_) for development, live keys (pk_live_, sk_live_) in production, and Clerk says to redeploy after changing them.
Redirect URLs. Each OAuth provider’s console needs your app’s callback address, and Replit notes that linking a new domain or buying one through Replit can change your app’s callback URLs and origins. Replit’s own environment variable REPLIT_DOMAINS lists the app’s domains and is refreshed by republishing.
DNS. A production Clerk instance on your domain needs the records Clerk’s dashboard lists; for an external domain linked to Replit, Replit shows the CNAME records under Authentication DNS setup. Add them with the DNS guide open.
Deployment. Every change to secrets or auth code needs a republish from Publishing before it reaches the live app. If the app also moves off Replit, the same keys go into the new host’s environment variables.

Testing before cutover

On the development instance: sign up, sign in, sign out, reset a password, and sign in with each social provider, with throwaway accounts.
A migrated test user, imported without a password, can reset it and then sees the same data they had before.
A social test user who existed before is matched to their record, not given a new empty one.
Every protected page and API route refuses a signed-out visitor.
The production instance’s DNS records show as verified and its certificates are deployed.
Production OAuth credentials are your own, not shared development ones.
Deployment secrets hold the live keys; development secrets hold the test keys.
The announcement email to users is written and the reset flow it describes actually works.

Checklist

I know which auth system the app uses, and which providers.
I have a database dump and a record of the user count.
I own an account at the replacement provider, with a production instance on my domain.
The new sign-in is implemented on a branch, with old user ids preserved.
I’ve decided how email users and social users re-establish themselves, and told them.
The site is live with both systems, or I’ve accepted a dated cutover for a small site.
Cutover verified on the real domain before anything old was removed.
Replit Auth, or the Replit-managed Clerk tenant, removed last.

The full picture of what else a Replit app depends on is in do you actually own your Replit site?, and the move itself in the exit guide.

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

Keep going

Or go back to the overview of what owning your site means, which ties all of these together.

Do you actually own your Replit site?
What you own when you build on Replit, and what still depends on Replit: the code and how to push it to GitHub, Replit’s publishing and deployments, its databases, Replit Auth, App Storage, secrets, domains bought through Replit, and what the documentation says happens when you stop paying. With an ownership checklist.
About a 8 minute read
Where your website’s data lives
Owning the repository is not the same as owning the website. The database, uploaded files, user accounts, form submissions, CMS content and analytics each live in a service with its own owner. How to find every one, work out whose account it’s in, check whether the data can be exported, and record what would have to move.
About a 9 minute read