AI tool · StackBlitz
From a Bolt app to production
Bolt builds the app, hosts it or publishes to Netlify, and offers a security audit from the Publish menu that covers secrets, access control, input validation and authentication. It runs when you run it.
Termsrow-level security (database rules that decide which rows each signed-in user may read or write) · two-user test (sign in as one user, create a row, then try to read or change it as another user; pass is nothing comes back) · Edge Functions (small server-side functions hosted by Supabase, where secret keys and payment calls belong) · client bundle (the JavaScript your app sends to the browser or ships inside the mobile app; anyone can read it) · webhook (a message a provider such as Stripe sends to your server when something happens, like a payment) · critical flow (a path a user takes that costs money or trust if it breaks: sign-up, checkout, invite, export) · verdict (a one-word release result (pass, pass with findings, fail) with the findings and the checklist version behind it)
What Bolt changes in a codebase
A prompt-to-app platform with its own hosted database or a Supabase connection, and publishing through Bolt hosting or Netlify. A security audit can be run from the Publish menu.
Bolt's audit is a good floor: run it before every publish, not once. The release checklist adds what the audit does not look at (payments, LLM spend, error handling, performance, migrations, rollback) and turns each item into a pass criterion a second person can check.
Defaults, from the docs verified 2026-09-21
| Default, from the docs | Why it matters for release testing | Source |
|---|---|---|
| The security audit checks "that private keys and passwords aren't stored in your project's code or sent to visitors' browsers", access control ("ways one person could see, change, or delete information that isn't theirs"), input validation and XSS, and authentication on protected parts. | A point-in-time scan over four areas; the checklist adds payments, LLM, performance, migrations and rollback and runs on every release. | docs verified 2026-09-21 |
| "We recommend running a security check at least once before you publish." The audit runs manually. | Once before publish is the vendor's floor; a release cadence needs the check on every release. | docs verified 2026-09-21 |
| Database security settings find "a missing row-level security (RLS) policy or a permission that's too open", including an "RLS Policy Always True warning". | The always-true warning is the policy-too-permissive pattern; AC-02's two-user test is the proof that a policy is not just present but effective. | docs verified 2026-09-21 |
| "Prevent Leaked Passwords" is "on by default for Bolt databases"; the audit warns if it has been turned off. | A good default that a generated fix can switch off; SC-04 records it as production configuration. | docs verified 2026-09-21 |
| Supabase can be connected as an alternative backend from Account settings under Applications. | With Supabase as the backend, every Supabase hub default applies, starting with RLS on tables created by generated migrations. | docs verified 2026-09-21 |
Each row was read on the linked page on the date shown. Docs change; the date tells you how current the row is. Bolt documentation.
Failure patterns most associated
- criticalAPI key shipped in the client bundle
A key meant for the server ends up in JavaScript the browser downloads, so anyone can read it and call the service as the app.
- criticalService-role key used from the front end
The database's bypass-everything key is used in client code, so row-level rules no longer protect anything.
- criticalSecret committed to the repository
A key or token is in git history, where it stays readable to anyone with repository access even after the file changes.
- criticalRow-level security off on a new table
A table created by a migration or SQL has no row-level security, so the anonymous key can read and write every row through the public API.
- criticalPolicy that allows everything
Row-level security is enabled but the policy condition is true for everyone, so isolation exists in name only.
- criticalList endpoint returns other tenants' rows
A list or search endpoint filters by the wrong column or none, so a user sees records belonging to other accounts.
- criticalObject fetched by id without an ownership check
An endpoint checks that the caller is logged in, then returns whatever id was requested.
- criticalAdmin gate enforced only in the UI
The admin page hides its buttons from ordinary users, but the underlying route or action accepts calls from anyone logged in.
How the checklist adapts
- AC-01 and AC-02 run against Bolt Database or the connected Supabase project; the always-true policy warning maps to the policy-too-permissive pattern.
- SC-04 confirms leaked-password protection and other defaults have not been switched off by a generated fix.
- DR-01 checks that publishing goes through one reviewed path once a team is involved.
- EH and PY categories apply in full from the first paying customer.
Release checklist, five of the published items
v1.0 · verified on 2026-09-21No secret keys in client bundles
automated Scan the built client assets (JS, source maps, HTML) for known key prefixes and for every value present in the server environment file.
Zero matches for key prefixes (sk_, service_role, AKIA, whsec_, private keys) and zero server-only env values found in client assets.
Object access checks ownership, not only login
automated For each endpoint or action that takes an id, call it as a logged-in user with an id owned by another user.
Every id-bearing endpoint returns 403 or 404 for a foreign id; none returns the object.
User-supplied content renders inert
automated Submit script, event-handler and URL payloads through every free-text field and view every screen that displays them.
No payload executes on any screen; content displays as text.
Every protected route verifies the session server-side
automated Request every route marked protected without cookies and with an expired session.
Every protected route returns 401, 403 or a redirect to login; none returns protected content.
Release notes carry the checklist version and verdict
manual Open the release record.
The record names the checklist version, the verdict, the build hash and the tester.
Which plan fits
Starter $2,900/mo
Starter after the audit for a web app releasing weekly; Growth when there is an API or daily releases.
For 3-8 engineers, weekly releases, web. Limits, cadence and what is not included.
Questions
Bolt.new app production ready
What breaks in AI written code?
Get a risk list for your codebase
5 business days, $1,200, credited to the first month.