Checklist
How to secure a Bolt.new app
Short answer. Publish from the Publish menu, then assume a Free plan site is public. Check the database security page on every plan, and run the full project audit if you are on a paid plan. Bolt's database docs say a table without row level security can be read and changed by anyone.
Updated 19 Oct 2026
This is a practical checklist, not a guarantee. It is not a penetration test, a compliance audit, or proof that an app is safe to launch.
Bolt can host the app on a bolt.host address, with a database and auth beside it. Some projects also connect a database you already run. Name which one you have before you follow a step. The shorter list is Ship a Bolt app. The general pass after this page is the pre-launch checklist.
See what Publish will make public
Bolt's publish docs say you can publish for free at an address ending in bolt.host, from the Publish menu. On the Free plan, every published site is public. On a paid plan you can choose public, or private to your team and people you invite. Custom domains are on paid plans.
Use the Publish or Update button in that menu. Bolt says prompting the agent to publish spends tokens, and the button does not.
If the project has real user data, a public bolt.host URL is a production URL. Private visibility is a paid-plan setting, and Bolt says teammates can still view a private site by default.
Run the check that matches your plan
Bolt documents two different checks. The database one is on every plan. The project one is on paid plans.
| Check | Who can run it | What Bolt says it covers |
|---|---|---|
| Database security page | Every plan | The database only. Missing row level security, a policy that is too open, and related database settings. The page is titled Security Audit and Bolt says it does not review the whole project. |
| Project security audit | Paid plans | Code and database. Who can see and change data, what the public pages reveal, how sign-in and sign-out work, misuse such as changing a price, unsafe input, and private keys stored in code or sent to the browser. |
Bolt says the project audit and its fixes do not use tokens when you start them from Run security audit in the Publish menu. Prompting the agent to audit does use tokens. The limit is 30 project audits a day, resetting at midnight UTC. Bolt says it fixes most of what it finds, and that some items are yours, such as a setting at an email or payment provider you connected.
When the audit finishes, the menu item changes to "Security audit up to date." Run it again after you change the project. A finished audit is Bolt's report of what it looked at. It is not a certificate. A second look from the security scanners category still belongs on the URL you will share.
Turn on row level security for every table
Bolt's database security docs say anyone can send requests to the database directly, without using your screens. Row level security is the rule that decides which rows those requests can touch.
- Bolt says it turns row level security on for the tables it creates. Tables you add yourself need the same switch.
- A table without it can be read and changed by anyone. That sentence is from Bolt's own security page.
- Each policy should allow the rows that user should reach. A policy that lets every request through is one of the warnings the database page shows, named along the lines of an always-true RLS policy.
Open the database icon, then Security, after every schema change. The button Ask Bolt to fix appears when you can edit the project and Bolt found an issue.
If this project uses a Supabase database you connected, use the Supabase row level security checklist in that dashboard as well. Bolt's page and Supabase's policies are the same idea. Confirm you are looking at the database the app actually calls. Supabase is the directory entry. The wider list is database and auth.
Keep secrets in the database secrets tab
Bolt's secrets docs say server functions read secrets so that API keys and passwords are not sent to the browser. The agent asks for a secret when a prompt needs one, for example an OpenAI integration, and then points you at the Secrets tab.
Open it from the database icon, then Secrets. You can add a name and a value there. The value is hidden as you type. Bolt's tips on that page are to rotate keys, remove keys you no longer use, and keep secrets out of plain text in the code.
Who can open that tab depends on the account. Bolt says an individual project allows the owner. A team project allows the owner, co-owners, and team admins. Editors and viewers do not get that tab.
Bolt's sharing docs describe a separate environment-variable permission: editors and co-owners can view environment variables, and viewers cannot. If a viewer opens the project, Bolt may tell them that environment variables are unavailable in view-only mode. Treat both stores as private. The API key checklist is how to check the built JavaScript anyway.
Payments, email, and expensive routes
Bolt's project audit says it looks for actions you did not intend, including changing a price. That check is on the paid audit. On every plan, a button that only updates the screen is not a payment. Use a server confirmation. Stripe projects should follow the webhook checklist. The payments and email categories are the products that belong on the server.
Email in a Bolt database project is documented as a server function that reads a secret from the database settings. Password resets and receipts take that path. The email API key stays in Secrets.
If a route calls a paid model or sends mail, add a limit on the server. Hiding the button is not a limit. See rate limiting.
FAQ
Is a free Bolt.host site private?
No. Bolt's publish docs say that on the Free plan, all published sites are public. Paid plans can mark a site private to the team and invited people. Teammates can view a private site by default.
Does the database security page review my whole app?
No. Bolt says that page checks the database, including missing row level security and policies that are too open, and that it is available on all plans. The full project audit, including the code, is on paid plans and starts from the Publish menu.
Who can see a Bolt secret?
Bolt's secrets page says the project owner on an individual account, and the owner, co-owners, and team admins on a team account. Editors and viewers do not manage that tab. Sharing settings separately let editors view environment variables. Viewers cannot.
What if the app is not on Bolt's database?
Follow the database the client actually calls. A connected Supabase project uses the row level security checklist. Then run the pre-launch checklist for AI-generated code on the source, because the host is only half of the review.
Sources
Checked 19 Oct 2026.
Newsletter
A short weekly note on new tools and security checklists. No spam, unsubscribe anytime.