Proxy Mail QA
Get started freeOpen the app

Testing sign-up and auth emails in Bolt apps

Bolt can add accounts to your app from a prompt, using its built-in database's authentication. The confirmation, magic-link and reset emails it sends are only as good as two settings, so test them with a real inbox before you publish.

Updated

How auth emails work in a Bolt app

Bolt’s built-in database includes authentication: email sign-up and Continue with Google. When someone signs up, asks for a password reset or a magic link, the email is sent by the database’s auth service (Bolt’s docs say its templates are powered by Supabase), and its link is built from your Site URL and redirect list.

Test every auth email in five minutes

  1. Turn on confirmation. Open the database icon, then Authentication → Email, and switch on Require users to confirm their email after signing up if your app should check addresses.
  2. Publish, then create an address in Proxy Mail QA, with a generated persona if your form asks for a name.
  3. Sign up on the published app, not only in the preview.
  4. Use the link or code from the row. A confirmation link becomes an Activate account button; codes get a Copy button.
  5. Then test the rest: sign out, reset the password, sign in with the new one, and save it on the row.

The two settings to check

1. Site URL and redirects. Under Advanced Authentication options, the Site URL should be your published address and the URI allow list should include every address your app runs on. If a reset link lands on localhost:3000, this is why. Proxy Mail QA flags links that go to a local address, including ones that only redirect there after verifying. Full guide.

2. The email template. Edit email templates lets you change each email’s subject and body. If you add a 6-digit code to the template, the row shows it with a Copy button; if you keep the link, it shows as a button named for what it does.

Copy-paste prompts for Bolt

Paste these into Bolt’s chat. Then test again with a fresh address.

List every email this app sends: sign-up confirmation, magic link, password reset, invite and email change. For each, tell me what triggers it, which URL its link points to, and how long its link or code stays valid. Flag anything that uses localhost.

Make every auth email link back to the published app, not localhost. Use the current site's address for the sign-up and password-reset redirects, and make sure the published address is in the authentication redirect list.

After a password reset, send the user to a page where they choose a new password, then sign them in. Show a clear message if the reset link has expired or was already used.

Try it on your next sign-up test

Free plan, no credit card. Create an address and watch the code or link arrive.

Create a free accountOpen the app

Questions

Where are the authentication settings in Bolt?

Bolt's docs put them under the database icon at the top of the screen, then Authentication. Email sign-up, the confirmation requirement and email templates are there; the Site URL and redirect list are under Advanced Authentication options.

My Bolt project uses Supabase directly. Does this still apply?

Yes. Bolt's docs say older projects usually use a Supabase project you connected. The same settings are in your Supabase project under Authentication, URL Configuration, and the emails still come from Supabase Auth.

Why do my reset links go to localhost:3000?

The Site URL is used when a link has no allowed redirect, and it starts as localhost:3000. Bolt usually updates it, but check that it's your published address and that every address you use is in the redirect list.

Related guides

See every email testing problem we solve →

Bolt is a trademark of its owner. Proxy Mail QA is independent and isn't affiliated with or endorsed by them.