Is Bolt secure? What to check before you launch

This page answers the question with the checks, not with a yes or a no. Bolt can host the app and may attach its own database. The project you publish is the thing to review. The longer project pass is how to secure a Bolt.new app. The short list is Ship a Bolt app. Bolt.new is the directory entry. The same question for two other builders is Is Lovable secure? and Is Replit secure?.

What Bolt is

Bolt's intro says Bolt is an AI-powered builder for websites, web apps, and mobile apps: you type a prompt, and Bolt turns it into a project. The same page says Bolt is developed by StackBlitz and runs on WebContainers, so the editor runs in your browser and you do not install a local environment. That is the building session.

Publishing is a separate step. Bolt Cloud is the hosting, database, and domain layer inside the product. Bolt's intro says a project can publish to a free bolt.host address, and that Bolt creates a database when the project needs one. By default that database is Bolt Database, which the Supabase integration page says is available on every plan. Connecting or claiming a Supabase database, or starting a project on Supabase, requires a Pro or Teams plan.

Bolt's intro also says the company is SOC 2 Type II compliant, and it points enterprise readers to the sales team for the report. The public trust profile lists SOC 2 Type 2, GDPR, and CCPA. Those are statements about Bolt's company program. They do not tell you whether the app you generated allows a second user to read the first user's rows.

What you still check

Bolt documents the hosting, the secret store, sign-in settings, and two security checks. You still decide four things before the URL is for real users:

• Whether the published site is public.
• Which values live in .env, where browser code can read them, and which live in Secrets.
• Whether every table has row level security, and whether each policy matches the person who should see that row.
• Whether a second account, and a logged-out visitor, can read or change the first account's data.

A finished check inside Bolt is Bolt's report of what that pass looked at. It is not a certificate. The walkthrough for one project is how to secure a Bolt.new app.

The checks Bolt documents

Bolt documents two checks, and they are not the same thing.

The database security page is on every plan. Open it from the database icon, then Security. Bolt says it looks for 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. Bolt says the warnings come from the same database checks as Supabase's Security Advisor. Ask Bolt to fix appears when you can edit the project and Bolt found an issue. Open the page again after you change the schema.

The project security check is on paid plans. Bolt calls it a security audit and says it reviews code and database: who can see and change data, what 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. Start it from Run security audit in the Publish menu. Bolt says that button, and the fixes it applies from that button, do not use tokens. Prompting the agent to audit does. The limit is 30 project audits a day, resetting at midnight UTC. When it finishes, the menu item changes to "Security audit up to date." Run it again after you change the project.

The publish docs say to check for security problems before anyone else uses the site. On a paid plan you can run the project check from the Publish menu. On every plan you can read the database security page. Read the result either way. The pre-launch checklist is the general pass after Bolt's own checks.

Secrets and the .env file

Bolt's secrets docs split two stores.

Secrets are for server functions, which Bolt also calls edge functions. Bolt says it reads a secret only when a server function needs it, and that it does not write that value into your project files, the browser code, or the published site. The agent asks for a secret when a prompt needs one, such as email, and points you at the Secrets tab under the database icon. Names are case-sensitive. After you save a secret, Bolt says it does not show the value again. Names that start with SUPABASE_ are reserved for Bolt's database connection and cannot be deleted.

Who can open that tab is limited. 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. If you lack access, the tab says "Project admin access required."

Environment variables live in the project's .env file, which is part of the project. Bolt says the code can read them directly, including code that runs in the browser. If the browser reads a value, that value is sent to anyone who visits the published site. Editors and co-owners can view environment variables. Viewers cannot. A viewer may see Bolt's message that environment variables are unavailable in view-only mode.

Bolt's database introduction lists VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY, and SUPABASE_SERVICE_ROLE_KEY as examples of values stored in environment variables. The secrets page is the tighter rule for anything that must stay off the visitor's machine: a payment provider's secret key or an email API key belongs in Secrets. If the project has a database, Bolt says it fills in some .env values for you, such as the web address and the public key, and locks those specific values. The public or anon key can stay in the client when row level security matches what that key should be allowed to do. The service role key bypasses those policies. If it is already in the bundle, the repo, or the chat, use Supabase service role key exposed. The anon-versus-secret distinction is Is the Supabase anon key safe to expose?. The wider pass is API keys in the frontend.

Bolt's tips on the secrets page are to change keys regularly, remove keys you no longer use, and keep secret values out of plain text in the code.

Sign-in

Authentication settings sit under the database icon. Bolt's auth docs cover email sign-in and Google sign-in. Allow new users to sign up is on by default. Allow anonymous sign-ins is off by default. Anonymous sign-in lets someone use the app without an account, and Bolt says a later account can be linked to those actions. Leave it off unless that is the product.

Email settings include confirmation after sign-up, reauthentication before a password change, and Prevent Leaked Passwords. Bolt says leaked-password protection is on by default when Bolt creates the database. It uses HaveIBeenPwned and rejects a password that has appeared in a known breach. It applies to passwords created or changed after the setting is on. It does not review passwords people already set. If you claim the database into Supabase, or connect a Supabase database, Bolt says the setting stays available on a Supabase Pro plan or higher and is off on a free Supabase plan.

Auth email has its own limit. Bolt says Bolt Database sends those messages through Supabase's default email service, which is meant for testing and demos and is limited to 2 auth emails an hour for the whole project. For a production app, Bolt says to set up custom SMTP, and that requires claiming the database first. Password-reset links depend on the Site URL and the URI allow list. Bolt says it usually updates those when you publish, and that the default Site URL of localhost:3000 does not work for a live app.

Sign-in is what lets a policy name a person. Bolt's database security docs say that if you have not added sign-in, Bolt might write policies that allow any visitor to view, add, change, and delete rows.

Row level security and the backend

Bolt's database security docs say anyone can send requests to the database directly, without using your screens. Row level security 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 security page. Each policy should allow the rows that user should reach. A policy with no condition shows up as RLS Policy Always True. Bolt says it flags that even when public access is what you want, and that the warning fits only if every visitor should be able to change or delete that data.

The test is two users, plus logged out. User B, using the same client, should not receive user A's rows. The policies and the "RLS is on but the query still returns rows" cases are in how to set up Supabase row level security and the Supabase row level security checklist. If this project uses a Supabase database you connected, confirm you are looking at the database the app actually calls. Supabase is the directory entry.

Server functions are where Bolt says work such as checking permissions, processing payments, receiving webhooks, calling an AI API, or sending email should run, because that code runs on a server. Bolt Cloud says you connect Stripe for payments, and that Bolt Cloud and Stripe handle card data so you do not store it yourself. The screen that says a customer paid is still a screen. Confirm the event with the Stripe webhook checklist. If a route calls a paid model or sends mail, add a rate limit on the server. Bolt Cloud also includes file storage with public and private storage. A private table next to a public file URL is still a public file.

Who can open the published site

On the Free plan, Bolt says every published site is public. On a paid plan you can choose public, or private to your team and people you invite. When a site is public, Bolt says anyone on the web can view it and search engines can list it. Private visibility is a paid-plan setting. If you are on a team, Bolt says other members can view the site by default, even when it is private. A site with a custom domain can only be published publicly. Custom domains themselves require a paid plan.

The project Share link is not that public URL. Bolt says the project link works for you, collaborators who accepted an invite, and team members with access. Someone else sees a page where they can request access. To let anyone on the internet see the project, publish it. Bolt also says it no longer lets you turn on sharing with anyone who has the link. If an older project still has that setting, you can turn it off, and you cannot turn it back on.

Use the Publish or Update button in the Publish menu. Bolt says prompting the agent to publish spends tokens, and the button does not. Changes you make after publish stay off the live site until you click Update. Unpublish takes a Bolt-hosted site offline. If the project has real user data, a public bolt.host URL is a production URL.

Before you launch

• Write down whether data lives in Bolt Database or in a Supabase project you connected. Supabase connect and claim are Pro and Teams features. Bolt Database is the default on every plan.
• Open .env and Secrets. A value the browser reads is public. A payment secret, an email API key, and the service role key belong in Secrets.
• Open Security on the database. Read every missing-RLS and always-true warning. Run the two-user test, then repeat it logged out.
• Open Authentication. Leave Prevent Leaked Passwords on unless you have a reason recorded for turning it off. Confirm the Site URL is the live address, not localhost:3000. If the app is in production, plan for custom SMTP instead of the two-email test limit.
• If you charge, confirm the payment on the server. Use the Stripe webhook checklist.
• On a paid plan, run the project check from the Publish menu and read what it flagged. On every plan, read the database security page. Then run a free passive check on the URL you will share, walk how to secure a Bolt.new app, and finish the pre-launch checklist.

FAQ

Does a finished Bolt security check mean the app is finished?

No. The database page reviews database settings and is on every plan. The paid project check reviews the code and the database, then applies the fixes it can. A finished run means that pass reported what it found. It does not replace the two-user test, and it is not a certificate.

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. A custom domain can only be published publicly.

Are values in .env secret?

Editors and co-owners of the Bolt project can open them. Viewers cannot. Bolt says a value the browser reads is sent to visitors of the published site. Secrets are the store Bolt keeps out of project files and the published site, and Bolt makes them available only to server functions.

Where is the rest of the Bolt launch list?

How to secure a Bolt.new app is the project walkthrough. Ship a Bolt app is the short version. Bolt.new is the directory entry.

Sources

Checked 6 Nov 2026.

• Intro to Bolt
• Bolt trust profile
• What is Bolt Cloud?
• Check a Bolt project's security
• Bolt database security
• Bolt database secrets
• Publish a Bolt project
• Share a Bolt project
• Bolt database authentication
• Bolt server functions
• Introduction to databases
• Supabase for databases