replit auth looked done but breaks after you ship

Your replit auth looked finished inside the Repl, then fell apart the first time someone opened the deployed link.

You asked the Agent to add Google login. It scaffolded routes, a session store, and a sign-in button. Inside the editor, you clicked through and landed on a dashboard. You deployed. Friends opened the URL, clicked sign in, and got errors, blank screens, or endless redirects. The Repl preview and the public deployment are not the same runtime. Auth that only knew the sandbox hostname cannot complete outside it.

Built, insecure, broken

Replit Agent auth often ships three problems at once: it works only in the Repl, it stores secrets in the wrong place, and it leaves production callbacks misconfigured.

Sign-in button does nothing on the deployed URL

The click handler fires in the Repl because environment variables exist there. On the deployed host, SESSION_SECRET or OAuth client IDs are missing. Server routes return 500. The browser shows a spinner, then nothing.

OAuth redirects to the wrong host

Google or GitHub sends users back to a Repl dev URL or localhost. The provider registered that callback while you were building. Deployed traffic never matches, so the session never attaches.

Sessions vanish on refresh

You log in once. Reload the page and you are logged out. Cookie secure flags, domain attributes, or in-memory session stores behave differently between preview and deployment. The Agent picked the path of least resistance for the editor, not for HTTPS production.

Secrets visible in client code

Search the generated bundle for client_secret or long random strings in frontend files. If they appear in React or static JS, anyone can extract them. That is not auth. That is a public password.

These patterns mirror what Lovable and Bolt users see after publish. The fix sequence is similar even when the editor differs. Compare notes in lovable login and the publish hub at lovable deploy.

Why the Agent shipped replit auth this way

Replit Agent optimizes for “make login work in this Repl right now.” It sees the current hostname, available Secrets, and a single-user test flow. It does not automatically reconfigure OAuth for a deployment URL you have not created yet.

Session libraries default to development mode: cookies without secure, secrets read from .env files that deploy pipelines ignore, redirect URIs copied from documentation examples pointing at localhost.

Agents also merge auth into a single file to ship faster. Server-side validation, CSRF protection, and refresh-token rotation get dropped because they are invisible in a quick demo. You see a green checkmark in the Repl. You do not see missing production env vars until a real user tries.

Replit Deployments use a different hostname and secret scope than the editor preview. Unless you copy Secrets into the deployment configuration and update provider callbacks, auth code still believes it runs on the build machine.

Fix replit auth before you share the deployed link

Work through these steps on the deployed URL, not only inside the Repl preview.

1. Copy your deployed origin. Open the live deployment URL. Copy the full https:// origin with no trailing path unless your app requires one.
2. Audit Secrets in the Repl. Open Secrets in the Repl sidebar. List every key your auth code reads: SESSION_SECRET, GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, database URLs, JWT signing keys. Confirm the same names exist for deployment, not only for the editor runtime.
3. Add missing deployment secrets. In Replit deployment settings, add each secret with production values. Generate a fresh SESSION_SECRET if the Agent reused a placeholder. Never reuse demo secrets from tutorials.
4. Update OAuth provider callbacks. In Google Cloud Console or GitHub OAuth settings, register redirect URIs that match your deployed domain and your auth route, for example https://your-app.replit.app/auth/callback. Remove stale localhost entries only after production works.
5. Fix cookie settings for HTTPS. In your server auth config, set secure: true and a sensible sameSite policy for production. Ensure session cookies target the deployed hostname, not localhost.
6. Move secrets off the client. Search frontend files for API secrets. Move token exchange and session creation to server routes. The browser should only receive session cookies or short-lived public tokens.
7. Redeploy and test privately. Trigger a fresh deployment after secret and callback changes. Open a private browser window, sign in once, refresh, and confirm the session persists.
8. Review generated auth code. Read the Agent’s login and callback handlers line by line. Delete unused providers, close open routes, and add basic rate limiting on sign-in endpoints.

Keep a short log of which secrets and callbacks you changed. Agents may regenerate files and overwrite manual fixes unless you pin the auth module.

Checklist before you call replit auth production-ready

• Every auth secret exists in deployment Secrets, not only the Repl editor
• OAuth redirect URIs match the deployed https:// origin
• No client secrets in frontend bundles or public repos
• Session cookies use secure on the live site
• Sign-in survives a full page refresh in a private window
• Provider dashboards list only callbacks you still control

FAQ

Why does replit auth work in the Repl but fail after deploy?

The Repl runs with development secrets and a known hostname. Deployed apps use different environment variables and a public URL. Session cookies, OAuth callbacks, and JWT secrets that only existed in the Repl break once traffic moves to production.

Where do I set secrets for replit auth in production?

Open your Repl, go to Secrets, and copy every auth-related key to the deployment environment. Set SESSION_SECRET, OAuth client IDs, and callback URLs to match your deployed domain, not localhost or the Repl preview host.

Is replit auth secure if the Agent generated it?

Only if you review it. Agents often skip HTTPS-only cookies, short session expiry, and server-side token storage. Treat generated auth as a draft: verify redirects, rotate secrets, and never commit keys to a public repo.