Replit auth not working: how to fix sign-in on a published app

Symptom

Sign-in works in the Replit preview. Then you publish, share the link, and one of these happens:

• You try to log in with the account you used while building, and the app says it doesn't exist.
• Google sign-in works on the .replit.app address but fails on your own domain.
• New users sign up with email and password, and the verification code never arrives.
• Everything looks fine, but a signed-out browser can still load private data from the API.

If you set up your own OAuth credentials, the provider's error page often shows this code:

Replit's own troubleshooting guide names that error for a callback URL that doesn't match what the provider has registered. The last symptom on the list has no error at all, which is why it is the one I check first.

Why it happens

Two auth systems, chosen by your plan

Replit offers two options, and Agent picks one by default if you don't name it. On Starter, Core and Pro the default is Clerk. On Enterprise it is Replit Auth. Agent keeps whatever your app already uses unless you ask it to change.

• Replit Auth signs people in with Replit accounts on a Replit-branded page. Replit's docs say Agent is the only way to add it: manual implementation is not supported.
• Clerk Auth gives your app its own Clerk tenant, managed by Replit. Users create accounts in your app, not on Replit.

The fixes are different, so knowing which one you have comes first.

Development and production are separate apps

With Clerk Auth, every app gets two Clerk environments. The workspace Secrets hold test keys (pk_test and sk_test) for Development. The published app runs with live keys (pk_live and sk_live) for Production. Each environment has its own user store, its own sessions and its own list of sign-in providers. Any data you keyed off a Development userId won't match a Production user.

Domains change the callback URLs

Custom OAuth credentials are a Production setting. Linking a new domain can change the redirect URLs and JavaScript origins the provider expects. Email verification on a domain you bought elsewhere needs extra DNS records before codes are delivered reliably.

The login screen is not the lock

Agent adds Clerk's Express middleware, which reads the session. It does not decide what each route is allowed to return. Replit's own security advice is to validate the user on the server before any sensitive operation. A hidden page in React is not a protected API.

The fix

1. Identify the system. Ask Agent whether the app uses Replit Auth, Replit-managed Clerk Auth or a provider you configured yourself. Replit's guide warns against mixing configuration from a managed and a self-managed Clerk app.

2. Test both environments. Open the preview and the published URL in separate private windows. Write down exactly which step fails and where.

3. Check the production keys. For Clerk Auth, open Publishing, then Overview, then Adjust settings, and confirm CLERK_PUBLISHABLE_KEY starts with pk_live. Don't paste live keys into the workspace Secrets pane. Replit's docs say that breaks the automatic switch between environments.

4. Check the users. In Users & Auth, the Users tab has an environment toggle. If your account is only in Development, sign up again on the published app.

5. Fix the domain. Test the default .replit.app address first. If only the custom domain fails, open Users & Auth, then Configure, select Production under SSO providers, and look for providers marked with a warning and "setup steps remaining". Copy each value from the provider setup checklist into the provider's developer console, then select Mark all as done. For email codes on an external domain, open Publishing, then Domains, then Manage, and add every CNAME record under "Authentication DNS setup required". DNS can take up to 48 hours. On Replit Auth, republish after linking a domain so the REPLIT_DOMAINS variable picks it up.

6. Lock every API route. This is the fix that matters most. A small middleware, then an ownership check in the query:

// server/auth.ts
import type { Request, Response, NextFunction } from "express";
import { getAuth } from "@clerk/express";
 
export function requireUser(req: Request, res: Response, next: NextFunction) {
  const { isAuthenticated, userId } = getAuth(req);
  if (!isAuthenticated || !userId) {
    return res.status(401).json({ error: "Not signed in" });
  }
  res.locals.userId = userId;
  next();
}

// server/routes/projects.ts (match your project's import paths)
import { Router } from "express";
import { and, eq } from "drizzle-orm";
import { db } from "../db";
import { projects } from "@shared/schema";
import { requireUser } from "../auth";
 
export const projectsRouter = Router();
 
projectsRouter.get("/api/projects/:id", requireUser, async (req, res) => {
  const [project] = await db
    .select()
    .from(projects)
    // ownerId stores the Clerk userId; convert the id with Number() if yours is an integer
    .where(and(eq(projects.id, req.params.id), eq(projects.ownerId, res.locals.userId)));
  if (!project) return res.status(404).json({ error: "Not found" });
  res.json(project);
});

Then check it from a signed-out terminal. You want a 401, not data:

curl -i https://your-app.replit.app/api/projects/1

7. Don't rebuild the tenant. Replit's guide is clear: deleting or recreating an auth tenant can delete user accounts. If you want to leave Replit Auth, use the Agent migration to Clerk in a new task. Agent moves the users first and only then changes the code. Replit says to expect 10 minutes to an hour.

How to prevent it

• Write the auth system and the rule "every /api route uses requireUser" into replit.md, so Agent follows it in every session.
• After each publish, run four checks on the live URL: sign up as a new user, sign out and back in, open another user's record by URL, and call one API route signed out.
• Revisit the Configure tab after any domain change.
• Leave the Clerk keys alone. Replit manages both sets.

When to get help

If users have already signed up in production and the data is tangled, or you need a migration plan between providers, that is worth a second pair of eyes before you touch anything. The guide to fixing vibe-coded apps covers the wider picture, and fixing auth in an AI-built app goes deeper on access rules. Auth problems often surface on release day, so pair this with deploying a Replit app to production.

Run the free vibe-code health check for a quick read on your app, or book a Rescue Sprint and I'll find and fix the gaps.