Bolt.new app login broken after deploy

Site URL and redirect URLs still name the preview

In Supabase, Authentication, then URL configuration, Site URL is the default for email links. Redirect URLs are the allow list. If Site URL is http://localhost:5173 or the Bolt preview, confirmation and reset links go there. If the deployed origin is not on the allow list, signInWithOAuth and signInWithOtp stop at Supabase.

How to check. Read Site URL and the redirect list. The deployed https origin has to be there, including the callback path you actually use. A wildcard such as https://your-deployed-host/** covers that host's paths.

The published bundle has no project URL or anon key

Bolt can keep the preview running with env values that were never saved on the host you published to. The client then calls undefined.supabase.co, or sends an empty apikey, and the auth request fails before a password is checked.

How to check. On the deployed site, print the public Supabase URL and anon key the bundle was built with. undefined means that build did not have them. Set them on the host and rebuild. Restarting the old build does not insert them.

The code exchange runs on a different origin than the one that started login

OAuth and magic links use a PKCE verifier stored on the origin that started the request. If login starts on the deploy and the redirect lands on the preview, or the reverse, the callback cannot exchange the code. Password login does not use that redirect. If only Google or magic-link login is broken, this is the place to look.

How to check. Start login on the deployed URL and watch the address bar until it stops. Every hop after Supabase should be the deployed origin. A preview host in that chain is the bug.

1. Put the public Supabase values in the published build

Use the project URL and the anon key. Do not put the service_role key in a VITE_ or NEXT_PUBLIC_ variable. Save the values where the publish step builds, then trigger a new build. Vite reads VITE_ variables. Next.js reads NEXT_PUBLIC_ variables.

VITE_SUPABASE_URL=https://YOUR_PROJECT.supabase.co
VITE_SUPABASE_ANON_KEY=eyJ...   # payload role is "anon"

const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_ANON_KEY,
);

2. Allow the deployed origin in Supabase Auth

Set Site URL to the deployed origin. Add that origin's callback to Redirect URLs. You can leave the preview URL on the list if you still log in from the preview. Email links use Site URL when the request does not pass a redirectTo.

3. Send redirectTo from the origin the user is on

A hardcoded preview URL or localhost sends the user away from the deploy. Read the origin in the browser at the moment they click the button.

const { error } = await supabase.auth.signInWithOAuth({
  provider: "google",
  options: {
    redirectTo: window.location.origin + "/auth/callback",
  },
});

4. Exchange the code on that same origin

The callback route has to run on the deployed host. exchangeCodeForSession consumes the code and stores the session for this origin. If this file never shipped, or it redirects to the preview before the exchange, the deploy never gets a session.

const url = new URL(request.url);
const code = url.searchParams.get("code");
if (code) {
  const { error } = await supabase.auth.exchangeCodeForSession(code);
  if (error) return NextResponse.redirect(url.origin + "/login");
}
return NextResponse.redirect(url.origin + "/");