Short answer
To test a Bolt.new app, publish it to bolt.host, run Bolt's security audit, and then test the published site in a browser with a test account: sign-up, sign-in, password reset and every form. TestOptim AI tests the published site from its URL, writes negative and edge-case tests for each flow, and re-runs them after every update.
- Bolt projects start with
localhost:3000as the auth site URL; reset and confirmation links break until you change it. - Bolt's preview runs inside your browser tab, so test the published bolt.host site instead.
- The published site does not change until you click Update, so test after every update.
On this page
How a Bolt.new app is built and hosted
Bolt.new, from StackBlitz, builds web apps and Expo mobile apps in the browser on WebContainers. Bolt describes its default stack as React, Vite, Tailwind CSS and Node.js. The default backend is Bolt Database, a Postgres database built on Supabase, and you can connect your own Supabase project on paid plans.
The editor preview runs inside your own browser tab, so there is no preview URL for an outside tool to open. Published sites live at your-app.bolt.host or a custom domain, and are public by default. Private sites are a paid option. On the free plan, a site that runs out of hosting usage goes offline for the rest of the month.
Bolt Database sign-in uses email and password, with optional email confirmation. Google sign-in is optional and needs your own Google Cloud credentials.
What Bolt already tests in your app
- Project security audit (paid plans, from the Publish menu) reviews code and database for data access and IDOR, account enumeration, session handling, business-logic abuse such as price changes or skipped steps, input handling and exposed keys, and can fix what it finds.
- Database security check (all plans) uses Supabase's advisor checks, such as policies that are always true.
- Browser testing: Bolt does not document a browser testing agent. Its own October 2026 blog recommends testing an app by hand before launch.
That makes the browser side the main gap for a Bolt app. TestOptim fills it by testing the published site, signed in, with the wrong inputs as well as the right ones.
Bugs to check in a Bolt app
- Reset and confirmation links that open localhost. Bolt's docs say projects use
localhost:3000as the site URL by default, which does not work for live apps. Set the site URL to your bolt.host or custom domain, and test password reset yourself; no agent can read the email. - Data any visitor can change. For apps without sign-in, Bolt may write database policies that let any visitor view, add, change and delete data, and tables you add yourself may have no policies at all. Run the database security check.
- A white screen after publishing. Missing environment variables or an unconnected Supabase URL leave the page blank. TestOptim records console errors and failed requests, so a blank page fails its tests with the error attached.
- A stale live site. Changes reach the published site only when you click Update, so the preview and the live site drift apart. Re-run tests after each update.
How to test a Bolt.new app with TestOptim AI
- Publish to bolt.host, or to a custom domain, and fix the site URL for auth first.
- Create a test account with email and password and confirm its email yourself.
- Create a TestOptim project with the published URL and add the account as a credential profile. Open the URL in a private browser window. If you see your app without signing in to the builder, TestOptim can reach it too.
- Explore, generate and run. The agent maps your pages and writes happy-path, negative and edge-case tests for each flow.
- Fix in Bolt, then Update. Paste the issue's steps and expected result into Bolt's chat, click Update to republish, and mark the issue fixed in TestOptim to re-run its test.
A private Bolt site needs a sign-in on Bolt's side before your app loads, so TestOptim cannot open it. Test a public published copy instead.
Frequently asked questions
Does Bolt.new test my app for bugs?
Bolt checks security: a project security audit on paid plans and a database security check on all plans. It does not document a browser testing agent that clicks through your app, so flow bugs such as broken forms and sign-in need a separate browser test before launch.
Why do my Bolt app's password reset links go to localhost?
Bolt projects use localhost:3000 as the auth site URL by default, and reset and confirmation links fall back to it when your domain is not in the allowed list. Set the site URL and redirect URLs to your bolt.host address or custom domain, then test the reset email again.
Why is my published Bolt site a blank white page?
Most often an environment variable is missing or the Supabase URL is not connected for the published site. Open the browser console to see the error. A TestOptim run reports this as a failing test with the console error and failed request attached.
Can TestOptim test the Bolt preview inside the editor?
No. The Bolt preview runs inside your own browser tab on WebContainers, so it has no address another browser can open. Publish to bolt.host and test the published site.
Why does my Bolt site not show my latest changes?
Bolt only updates the published site when you click Update. Until then the live site keeps the previous version, even though the preview shows your changes. Click Update, then re-run your tests against the published site.
Is a Bolt app on the free plan safe to test?
It is safe, but watch your hosting usage. On Bolt's free plan a published site that runs out of hosting usage goes offline for the rest of the month, so frequent scheduled test runs on a busy free site can add to that usage. Test less often, or move to a paid plan before launch.
Sources
Platform facts were checked against these pages on 22 October 2026. Builders change quickly, so check them again before relying on a detail.
More Vibe-coded apps guides
- How to test a vibe-coded app before you launchHow to test a vibe-coded app from Lovable, Bolt, Replit, Base44 or v0: the bugs AI app builders leave, what their own checks miss, and a launch checklist.
- How to test a Lovable app before you launchHow to test a Lovable app: what Lovable's security scan and browser testing cover, the Supabase RLS and sign-in bugs to check, and how to QA lovable.app.
- How to test a Replit app before you publishHow to test a Replit app: secrets and databases that differ in production, Replit Auth sign-in, what Replit App Testing covers, and how to QA replit.app.
- How to test a Base44 app before you launchHow to test a Base44 app: what the Testing Agent and Security Scan cover, why sign-in can only be tested once published, and how to QA base44.app.
- How to test a v0 app before it reaches productionHow to test a v0 app on Vercel: protected preview deployments, NEXT_PUBLIC_ secrets, env vars that differ by environment, and how to QA production.