Guide Lovable ยท Bolt

Should I enable email confirmation before I launch my Lovable or Bolt app?

By the PatchAndShip team Last verified:

Short answer

For a real launch with email and password sign-up, turn Confirm Email on so a new account cannot sign in until the person proves they own that inbox. Turning it off is a common test shortcut. Leave it off only while you still use throwaway test accounts. Lovable's own tip for projects on your Supabase account is the same shape: turn confirmation off while testing, then re-enable it before launching to real users.

Where the switch lives

Open your Supabase project Dashboard, then Authentication, then Providers, then the email provider. Find Confirm Email and turn it on for launch.

If you build in Lovable with your own Supabase project, those Auth settings live in the Supabase dashboard, not inside Lovable. If you build in Bolt, use the same Supabase path. Bolt's project security audit checks that password and email verification rules look strong enough, and that secrets are not shipped to visitors' browsers; it is not a separate Confirm Email toggle in the Bolt UI.

What "off" means in plain words

With Confirm Email disabled, Supabase assumes the email does not need to be verified to sign in, and it implicitly confirms the user's email in the database. In plain words: anyone who can complete sign-up can sign in without clicking a mail link.

That speeds local testing with fake inboxes. It also makes mistyped or throwaway addresses easier to keep using after you go live, because the app no longer waits for proof of the inbox.

What "on" means before launch

With Confirm Email on, users need to confirm their email address before signing in for the first time. First sign-in waits on the confirmation link in their mail.

Before real users hit that flow, check Site URL and redirect URLs in Supabase Auth so the link lands on your real domain, not a leftover localhost or preview URL. Keep that check short here; related deploy or auth tips cover redirect detail without turning this page into a full redirect guide.

How this sits next to fake-signup controls

CAPTCHA and Auth rate limits are separate controls. Confirmation is the "prove the inbox" step. For the bot-focused checklist (fake sign-ups, CAPTCHA, rate limits), use Stop fake sign-ups on Supabase. This page stays the pre-launch toggle: off for throwaway tests, on for real users.

Quick self-check (no SQL)

  1. Turn Confirm Email on in Supabase Auth (email provider).
  2. Create a fresh test account with an inbox you control.
  3. Confirm you cannot use the private parts of the app until you click the mail link.
  4. Then create a second account and confirm it cannot use the first account's private data (notes, orders, uploads, messages).

Those clicks sit next to the broader no-SQL rituals in How to test your Lovable or Bolt app before real users and the leak questions in Is my Lovable or Bolt app leaking data?.

What you can DIY vs when to get a second look

You can flip Confirm Email, fix Site URL and redirects, and run the fresh-account plus two-account checks yourself.

Stop guessing if you cannot tell whether Confirm Email is on in the live project, whether unverified accounts can still reach private rows, or whether signed-out visitors and other accounts see data they should not. That is the natural handoff to a read-only second look.

Want a second pair of eyes?

Turning Confirm Email back on is one launch switch. If you still are not sure whether signed-out visitors or other accounts can reach private rows, the $49 Database Check is a read-only second look: you run our script and send the results. No passwords, no keys, no login to your account. We change nothing. AI agents run the checks and a human engineer reviews and approves every report. Not a penetration test, a security guarantee or a compliance certification.

See plans and prices

Sources