Bolt auth not working: fixing sign-in, Google login and reset emails

Login in a Bolt app runs on Bolt Database. Bolt's docs describe its email templates as powered by Supabase technology, and the template variables reference supabase-js methods such as signUp, signInWithOAuth and resetPasswordForEmail. So the code behind your login screen is Supabase Auth, and the settings that break it live behind the database icon at the top of your project. That is the good news: most fixes are settings, not rewrites.

Symptom

Bolt auth failures rarely throw a clear error. What people usually report:

• Sign-up worked for the first couple of test accounts, then confirmation and reset emails stopped arriving.
• The password reset link opens the dashboard, or a localhost address, instead of a "set new password" screen.
• The Google button does nothing, or fails, inside the Bolt preview.
• Google sign-in works for you but not for customers, or the consent screen shows your domain instead of your app name.
• Users can sign in, but one account can see another account's records.

The database's Security Audit is the one place Bolt names the problem outright. These are two of the warning titles its docs list:

Why it happens

Login was added late. Bolt doesn't always add sign-up and log-in by itself; its docs say you may need to prompt for it. Bolt's security docs also say that before you add sign-in, it may write policies that let any visitor view, add, change and delete data. Add login afterwards and those open policies can stay.

The Site URL still points at localhost. By default, Bolt projects use localhost:3000 as the Site URL. Bolt usually updates it when you publish, but its docs say you may need to set it yourself, especially with more than one domain. Reset and confirmation links that don't match the URI allow list fall back to the Site URL.

Google sign-in can't run in the preview. Google's OAuth flow blocks iframes, so Bolt tells you to test it on the published site. On top of that, Google puts a new OAuth app in Testing status, which limits sign-in to up to 100 users.

The email limit is tiny. Bolt Database sends auth emails through Supabase's default service, capped at 2 per hour for the whole project. That covers confirmations, password resets, magic links, invitations and email changes. A few test runs use it up.

Duplicates reset sign-in settings. When you duplicate a project, the new database gets Bolt's default sign-in settings. Google credentials, email templates and redirect URLs don't come with it.

The fix

1. Set the Site URL and allow list

Open the database icon, click Authentication, and find the advanced options. Set Site URL to the primary address of your live app, for example your custom domain. In URI allow list, add every address users might return to, comma-separated. Wildcards work, as in Bolt's own example:

https://yourapp.com/**,https://your-app-name.bolt.host/**

Bolt respects manual changes here, so once you set them they stay set.

2. Send reset links to a real reset screen

Bolt's docs warn that users can land on the dashboard instead of a reset screen. Make the redirect explicit, then handle the recovery session on that page. This uses supabase-js v2:

// Find your Supabase client in Code view by searching for createClient
import { supabase } from "./lib/supabase";
 
export async function sendResetEmail(email: string) {
  const { error } = await supabase.auth.resetPasswordForEmail(email, {
    redirectTo: `${window.location.origin}/reset-password`,
  });
  if (error) throw error;
}

// src/pages/ResetPassword.tsx
import { useEffect, useState, type FormEvent } from "react";
import { supabase } from "../lib/supabase";
 
export default function ResetPassword() {
  // Bolt's docs note the reset link carries #type=recovery in the URL
  const [ready, setReady] = useState(() => window.location.hash.includes("type=recovery"));
  const [password, setPassword] = useState("");
  const [message, setMessage] = useState("");
 
  useEffect(() => {
    const { data } = supabase.auth.onAuthStateChange((event) => {
      if (event === "PASSWORD_RECOVERY") setReady(true);
    });
    return () => data.subscription.unsubscribe();
  }, []);
 
  async function save(e: FormEvent) {
    e.preventDefault();
    const { error } = await supabase.auth.updateUser({ password });
    setMessage(error ? error.message : "Password updated. You can sign in now.");
  }
 
  if (!ready) return <p>This reset link is invalid or has expired.</p>;
 
  return (
    <form onSubmit={save}>
      <label htmlFor="password">New password</label>
      <input id="password" type="password" minLength={8} required
        value={password} onChange={(e) => setPassword(e.target.value)} />
      <button type="submit">Save password</button>
      {message && <p role="status">{message}</p>}
    </form>
  );
}

Add /reset-password to the router and to the URI allow list. If your app uses #/ style URLs, the path will look different, so check the address bar after clicking a real reset link.

3. Test Google sign-in on the published site

Follow Bolt's Google SSO steps: database icon, Authentication, Continue with Google, turn on Enable Google Sign In, and copy the JavaScript origin and redirect URI into a Web application OAuth client in Google Cloud Console. Paste the Client ID and Client Secret back into Bolt. Then publish and test in a normal browser tab.

Before launch, go to Google Auth Platform, then Audience, and publish the OAuth app so more than 100 people can sign in. Branding (your app name and logo) needs verifying and publishing separately under Branding.

If you call Google sign-in yourself, send people back to the page they came from:

await supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo: window.location.origin },
});

4. Get past the email limit

For testing, create accounts from User Management with Add User instead of signing up again and again. That keeps your 2 emails an hour for the flows you are actually testing.

For production, Bolt's docs say to set up custom SMTP so auth emails go through your own provider. That requires claiming your database in Supabase first, which needs a Bolt Pro or Teams plan, and raises the limit to 30 auth emails an hour. One catch: on a free Supabase plan, leaked password protection is off for claimed databases; it needs Supabase Pro or higher.

5. Make every policy check the user

Open each table under Tables and click View Policies. Any policy with no condition on the signed-in user needs replacing. For a table where each row belongs to one user, the policies look like this:

-- Example table: public.projects with a user_id column. Adjust names to your schema.
alter table public.projects enable row level security;
 
create policy "Owners read their projects" on public.projects
  for select to authenticated
  using ((select auth.uid()) = user_id);
 
create policy "Owners add their projects" on public.projects
  for insert to authenticated
  with check ((select auth.uid()) = user_id);
 
create policy "Owners change their projects" on public.projects
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);
 
create policy "Owners delete their projects" on public.projects
  for delete to authenticated
  using ((select auth.uid()) = user_id);

Ask Bolt to apply this and remove the old open policies, then reopen Security to confirm the RLS Policy Always True warning is gone. On a paid plan, also run Publish, then Run security audit: it checks sign-in and session handling across the whole project, not only the database, and doesn't use tokens.

How to prevent it

• Ask for login in your first few prompts, before Bolt builds tables that hold private data.
• Every time you add a domain or switch from bolt.host to a custom domain, recheck the Site URL and allow list.
• Keep Prevent Leaked Passwords on. It only checks passwords set after it is turned on.
• If the app is invite-only, turn off Allow new users to sign up.
• Keep two test accounts and try to open one account's records while signed in as the other.

When to get help

If you've worked through these and users still get logged out, see the wrong data, or never receive emails, the problem is usually in how the data model was built around login. The Bolt to production guide covers the wider launch checklist, and the fix guide for vibe-coded apps explains why these failures cluster. For login beyond Bolt specifics, read how to fix auth in an AI-built app, and if records are going missing or erroring, see Bolt database issues.

Start with the free vibe-code health check. If it needs hands-on work, a Rescue Sprint covers an audit plus fixes at a fixed price agreed after a technical assessment (from £750), usually in about a week.