Seatbelt
Back to Seatbelt

Bolt.new security checklist before you launch

You are about to publish from Bolt to Netlify. The in-platform Security Audit is useful and it does not stop a deploy. When Bolt finds nothing or you fixed issues, the Publish menu shows No security issues: green confidence copy, not v0's deploy block. Vendor studies often put Bolt apps among the highest rates of secret keys landing in the public JavaScript bundle. Use the checks below, then run one Ship Read on the folder you hand off.

Reviewed July 2026

The short version

  1. No secret keys in the client bundle. Search for sk_live, service_role, and VITE_ names that look like secrets. Rotate anything real that leaked.
  2. Run Bolt's Security Audit tab and fix what it finds. Do not treat No security issues in the Publish menu as clearance to share the link. That green line is confidence copy, not a deploy block.
  3. Export or clone the project. Scan that artifact before Netlify publish, not after strangers open the URL.
  4. Confirm server auth and leftover admin routes the same way as any vibe-coded app. See the full before you launch checklist.

Seatbelt reads secrets, databases, login, payments, customer data, and risky shortcuts in one pass. Run a Ship Read on the export.

  1. 01

    No secret keys in the Bolt client bundle

    Bolt is frontend-first. Wiring an API in chat is the fastest path, and that is how live keys end up in browser code. Watch for OpenAI client calls configured to run in the browser (the SDK's browser-allow flag) and for VITE_ or NEXT_PUBLIC_ names that look like secrets.

    Check it yourself

    • After a preview build, search the loaded JavaScript for sk_live, sk-, service_role, and AKIA.
    • Search the project for the OpenAI browser-allow SDK flag and for env names that include SECRET, SERVICE_ROLE, or PRIVATE.
    • If a real key was exposed, rotate it with the provider before the bots find it. Bots scan public repos and fresh bundles for keys around the clock, so treat even a few seconds of exposure as compromised. Removing it from the file is not enough.

    What Seatbelt reads: the secrets surface on the folder or ZIP you hand it. A secret in the public build is a must fix. Publishable keys like Stripe pk_ stay noted.

  2. 02

    Database rules that actually filter by user

    Bolt's Security Audit is strong on missing row level security and related database settings. Still verify outside the builder: policies that never check who is asking leave every row one API call away.

    Check it yourself

    • Use Settings → Database → Security in Bolt, then confirm the same rules in your Supabase or Firebase console.
    • Create a second account and request the first account's data through your API. If it answers, the rules are not doing their job.

    What Seatbelt reads: database cues in the export: service keys in the browser, rules that allow everything, database URLs in public code. It never connects to your live database.

  3. 03

    Export, then scan before Netlify publish

    The moment that matters is the handoff: GitHub export, Cursor clone, or ZIP. Platform checks stay inside Bolt. A Ship Read on the artifact follows you across tools and gives a shareable proof link.

    Check it yourself

    • Export or clone the project to a folder you control.
    • Paste that folder or ZIP into Try a Ship Read, or run /seatbelt from Cursor after install.
    • Fix must-fix findings before you share the Netlify URL.

    What Seatbelt reads: a static pass over the six surfaces. Not a pentest. Not a live URL probe. If it finds almost nothing, the report says so.

Run the Bolt checklist in one pass

Seatbelt returns a Ship Read: plain English verdict, file and line, why it matters, next step. Hand it the Bolt export after you leave the builder.

  • Full findings included, not a locked score.
  • Works after GitHub export or local clone. Same check as Lovable, Cursor, and Replit.
  • Optional push gate parks flagged deploys on a pull request instead of main.
Run a Ship ReadFull before-you-launch checklistCompare tool lanes

Questions

Bolt Publish menu says No security issues. Am I clear to launch?

Not by itself. Bolt shows No security issues when it finds nothing or you fixed issues (Bolt support publish, July 2026). That green line is confidence copy inside Bolt, not a deploy block like v0's automatic Vercel stop. If issues remain, Bolt alerts with Review security; publish never stops. Export to GitHub or push from Cursor and nothing gates the artifact. Run a Ship Read on the export for shareable proof at handoff.

Does Bolt's Security Audit replace a pre-launch checklist?

No. The audit tab is real and useful inside Bolt. It does not block deploy. Export and Cursor pushes still need a ship-moment read on the artifact. See also the compare page Bolt row.

What should I check on a Bolt.new app before Netlify publish?

No secret keys in the public bundle, database rules that filter by user, authorization on the server, and no leftover admin routes. Then run a Ship Read on the export.

How do I run Seatbelt on a Bolt project?

Export or sync to a folder or GitHub repo, then paste that path or ZIP into the browser check, or clone and scan from Cursor. Seatbelt does not log into Bolt or probe your live Netlify site.

For agent fleets

Seatbelt is an enforced human-in-the-loop layer between agents: one agent's output is evidence, not authorization. Wire it once with /seatbelt init on Get started.