Skip to main content
This guide covers users signing in to an app you built. For problems signing in to your Replit account, see Account and access.

​
Identify the authentication system first

Ask Agent: “Does this app use Replit Auth, Replit-managed Clerk Auth, or a separately configured authentication provider?”
  • Replit Auth: users sign in with Replit accounts.
  • Replit-managed Clerk Auth: your app has its own user accounts and managed auth configuration.
  • Your own Clerk account or another provider: check that provider’s configuration as well as the app.
For Clerk, confirm whether Agent provisioned the integration or you supplied credentials from your own Clerk account. Do not mix configuration from the two.
Do not delete or recreate an authentication tenant to fix a sign-in error. Deleting a tenant can delete user accounts. Do not switch providers or replace credentials without a migration plan for existing users.

​
Sign-in works in Preview but fails after publishing

  1. Test Preview and the published app separately. Record the exact failure.
  2. For Clerk, check that the intended development or production environment is selected. Their users and configuration are separate.
  3. Check that the published app has the required auth environment variables. Inspect names and configuration status; do not paste their values into chat.
  4. If using your own provider, compare the allowed origins and callback URLs with the exact published hostname and protocol.
  5. Publish any intended configuration change, then test in a fresh browser session.
For an OAuth redirect_uri_mismatch, compare the actual redirect URI with the provider’s registered URI. Do not guess a callback path or add wildcard access as a workaround.

​
Only one social sign-in provider fails

Test another enabled sign-in method to isolate the failure. Check the failing provider’s setup for the correct environment, domain, and callback URI. For managed Clerk, follow Clerk Auth rather than creating a replacement tenant.

​
Users appear to be missing

Confirm the project, authentication provider, and environment before changing anything. A development account does not demonstrate that the same account exists in production. A copied or remixed project may use different auth configuration; do not assume users migrated with the code.

​
A custom domain causes sign-in errors

First test the default published URL. If only the custom domain fails, follow the domain guide, then verify the auth provider’s domain configuration. Hosting DNS and authentication DNS are separate checks. If a domain is reported as already attached to another auth application, contact Support for a managed integration, or your provider for a self-managed one. Do not delete the old application just to release the domain.

​
Verification emails do not arrive

Check the address, spam folder, and whether the account exists in the intended environment. Record any error or rate-limit message before retrying. Avoid rapidly requesting more codes, and never share a verification code with Support.

​
Still failing?

Include the provider and management mode, environment, failing sign-in method, affected hostname, sanitized error, and time with timezone. State whether other methods work. Do not include tokens, cookies, credentials, or user lists. Use the support checklist.