Vibe Coding Checklist

Guide · Bolt · Checked against Bolt's docs, October 2026 · Updated

The Bolt launch checklist

Is my Bolt app ready for real users?

Only after you check what's underneath. On paid plans, the Publish menu has a "Run security audit" button, and the database Security page flags issues like missing row-level security. Also confirm your API keys live in Secrets, private files sit in private storage buckets, and you have another way to recover data, because Version History doesn't restore your database.

Bolt can take an idea to a published site in an afternoon. Before real people use it, check the ten things underneath. Each one says where to look in Bolt (most database screens open from the database icon at the top center of your project) and gives you a prompt to paste into the chat.

Connected your own Supabase project instead of Bolt's built-in database? See the Supabase launch checklist too.

Take the 2-minute checkJump to: before you publish
  1. 01

    Your data

    Database → Tables

    Bolt creates databases automatically when your app needs one. Open the Tables view and make sure each table matches something real in your app. A table you can't explain, or the same information in two places, is a sign the AI guessed.

    Paste into Bolt

    Describe my data model in plain English: every table, what it stores, and how the tables connect. Flag anything you assumed instead of being told.

  2. 02

    Accounts

    Database → Authentication, User Management

    Bolt's built-in authentication supports email confirmation, password reset and Google sign-in. Turn on email confirmation, and make sure the whole lifecycle exists: sign up, sign in, forgot password, sign out, and a way to delete an account. Bolt's security check verifies that signing out actually ends the session.

    Paste into Bolt

    Walk me through every account flow: sign up, email confirmation, sign in, forgot password, sign out and delete account. Which are missing or half built? Account deletion must remove the person's data on the server.

  3. 03

    Permissions

    Publish → Run security audit

    Bolt's audit checks whether one person could see, change or delete information that isn't theirs, and whether users can do things you don't intend, like changing a price or skipping a required step. Hiding a button doesn't count: the check has to happen on the server.

    Paste into Bolt

    For every piece of private data and every action that costs money or changes someone else's data, show me where the server checks who is allowed. List anything only protected by hiding it in the interface.

  4. 04

    Database rules (RLS)

    Database → Security

    Bolt's database Security page flags problems like a missing row-level security policy or a permission that's too open, with warnings such as "RLS Policy Always True." Review each one, then use "Ask Bolt to fix." This page checks only your database, not your whole project.

    Paste into Bolt

    List every table and its row-level security policies in plain English: who can read, add, change and delete rows. Flag any policy that is always true or lets someone who isn't signed in reach private data.

  5. 05

    Secret keys

    Database → Secrets

    Store API keys in Bolt's Secrets section and use them from server functions, so they never sit in your code or reach visitors' browsers. Bolt's security check looks for private keys and passwords stored in code. Any key that was ever in front-end code should be replaced.

    Paste into Bolt

    Search this project for API keys, tokens and passwords. For each one, tell me its name (not its value) and whether it appears in front-end code. Move every secret into Secrets and use it only from server functions.

  6. 06

    When things break

    Database → Server Functions

    AI builds the happy path. Anything that touches money or another service belongs in a server function, where the server can finish or undo the work if someone closes the app halfway.

    Paste into Bolt

    For sign up, save, pay and upload: what happens if it fails halfway or the connection drops? Show me what the person sees, and make sure retrying can't create duplicates or double charges.

  7. 07

    What leaves your app

    Integrations (Stripe and others)

    Emails, notifications and payments leave your app the moment they fire. Test with your own addresses, and use your payment provider's test mode (Stripe has one) before any real card is involved.

    Paste into Bolt

    List everything this app sends out: emails, notifications, payments, webhooks. For each, what triggers it, and how do I test it without reaching a real person or charging a real card?

  8. 08

    Uploads

    Database → File Storage

    Bolt's docs are clear: files in a public bucket can be seen by anyone with the link, even if they're not signed in. Private buckets are protected by row-level security policies. Keep anything personal in a private bucket.

    Paste into Bolt

    Set up storage security for each bucket so each user can only upload and access their own files. Tell me which buckets are public, and why.

  9. 09

    Hosting and cost

    Cloud settings

    Bolt shows your database limits on the Cloud settings page. Unpublished projects with low usage for six days can be paused automatically; published projects keep their databases. Version History does not restore your database, so have another way to recover your data.

    Paste into Bolt

    What does this app run on, which limits apply on my plan, and what would break or get expensive first if ten times more people used it? How would I recover my data if something was deleted by mistake?

  10. 10

    Knowing when it breaks

    Database → Logs

    Logs show what happened, but nobody reads logs until something's wrong. Add an outside check that does what a real user does every day, and track keys and domains that expire.

    Paste into Bolt

    How would I find out right now if this app stopped working for users? Suggest a simple daily check that tests a real user action, and list any keys, certificates or domains that will expire.

Before you publish

  1. Run the security audit from the Publish menu. It reviews your code and database, fixes most problems itself, and tells you what you need to do. Use the "Run security audit" button there; it doesn't use tokens. It's available on paid plans, with up to 30 audits a day.
  2. Clear the database Security page. Review every warning and use "Ask Bolt to fix." Remember it covers only the database.
  3. Choose who can see the site. Public sites can be found by search engines. Private sites (paid plans) are visible only to your team and invited people. A site with a custom domain can only be published publicly.
  4. Publish with the Publish or Update button. Bolt notes these don't use tokens, unlike asking the AI to publish.

Newsletter · Free

Get the full Fix Kit, free.

For all ten items: a prompt to check your app, a prompt to fix it, and a way to confirm it worked yourself. Plus one new prompt every week.

Common questions

Does Bolt check my app for security problems?

Yes. On paid plans, the Publish menu has a "Run security audit" button that reviews your code and database, fixes most issues on its own, and tells you what's left. The database Security page also lists issues like missing row-level security policies, with an "Ask Bolt to fix" option.

Where do I put API keys in Bolt?

In the Secrets section of your Bolt database, used from server functions. That keeps them out of your code and out of visitors' browsers.

Are files in Bolt storage private?

Only if the bucket is private. Files in a public bucket can be seen by anyone with the link, even without signing in. Private buckets are protected by row-level security policies.

Can I restore my Bolt database from Version History?

No. Bolt's docs say Version History does not currently support database restores, so plan another way to recover data.

Is this an official Bolt checklist?

No. It's an independent guide by Andrew Adams, based on Bolt's public documentation (checked October 2026). It isn't a professional security audit.

Sources

An independent guide, not affiliated with Bolt, and not a professional security audit. Dashboards change often; if a menu has moved, the prompts still work. Written by Andrew Adams, based on the Vibe Coding Checklist. Other guides: Lovable · Bolt · Cursor and Claude Code · Supabase · Firebase.