Is my Bolt.new app secure?

Bolt.new builds your app in the browser and then deploys it to a live host (commonly Netlify, and increasingly other targets). The moment it is deployed, it behaves like any other website: the frontend code runs in your visitors' browsers, and anything shipped in that bundle — including environment values baked into it — can be read by anyone who looks. That is not a Bolt flaw; it is how the web works. The job before launch is making sure nothing sensitive ended up in that public surface.

One Bolt-specific habit worth keeping: review the deployed site, not just the in-editor preview. It is easy to keep iterating in the chat and forget which version is actually live in front of users.

Vite, which Bolt apps are built on, embeds any environment variable whose name starts with VITE_ directly into the browser bundle. It is not server-side and it is not hidden — it ships to every visitor.

Fine in a VITE_ variable

Public identifiers meant to be seen: a Supabase project URL, a Supabase anon key, an analytics site id. These are designed to be public.

Never in a VITE_ variable

A Supabase service_role key, a Stripe or payment secret, an OpenAI / AI provider key, a private webhook secret, or any token with real privileges. If your app needs one of those, the call must happen in server-side code (for example a serverless function or a Supabase Edge Function), not in the frontend.

If a secret has already gone out in a deploy, follow public .env files and what to do if a secret leaked — rotate first, then remove.

Many Bolt apps store their data in Supabase. If yours does, the decisive question is whether Row Level Security is enabled and your policies are scoped correctly. With RLS off, your public anon key — which ships in the frontend — lets anyone query the table directly, around your app's screens.

• In the Supabase dashboard, confirm RLS is enabled on every table with real data.

• Read each policy and confirm it limits access to the right user, not everyone.

• Check write policies (insert, update, delete) as carefully as read policies.

The full walkthrough — including why the anon key is safe to expose and what a leaked service_role key means — is in the Supabase RLS checklist.

If your Bolt app has accounts, test the boundary between users, not just the login form. The risk is rarely the sign-in screen — it is whether a logged-in user can reach data that isn't theirs, or trigger an action they shouldn't.

• Sign in as one user and try to load another user's record by changing an id — you should be denied.

• Confirm sign-up, sign-in, sign-out, and password reset end in the correct state.

• Ensure privileged actions are enforced server-side or by a database policy, not just hidden in the UI.

See the authentication security checklist for the complete set.

Run through this against the deployed app before real users arrive:

• You checked the live deployed URL, not just the Bolt preview.

• No service_role key or private API secret is in any VITE_ variable or the frontend bundle.

• If you use Supabase, RLS is on for every table with real data and policies are scoped.

• Login, logout, and password reset work, and one user cannot reach another user's data.

• Privileged actions are enforced on the server, not just hidden in the interface.

• HTTPS is enforced and basic security headers are present.

• You ran a scan of the live URL to catch exposed keys and obvious exposure.

The tool-agnostic master version is the launch security checklist for vibe-coded apps, and the browser-protection details are in the HTTP security headers checklist.

GuardMint scans your deployed app from the outside and reports what is visible there. The methodology page explains the scope.

• Detects Supabase and other keys in your frontend and flags a service_role key as serious.

• Looks for other exposed secrets and obviously open endpoints.

• Checks HTTPS, security headers, and other public launch-readiness signals.

Is a Bolt.new app secure once it's deployed?

Deploying does not add security on its own. Bolt.new produces a normal public web app, so anyone can read its frontend bundle and any keys inside it. Whether it is secure depends on configuration Bolt cannot decide for you — keeping secrets out of VITE_ variables, enabling Row Level Security if you use Supabase, and enforcing auth on the server. Verify those before you point real users at it.

What environment variables are public in a Bolt.new app?

Bolt apps are typically built with Vite, which embeds any variable named with the VITE_ prefix into the browser-visible build. Those are public. A Supabase project URL and anon key are fine there; a service_role key, payment secret, or AI API key is not — those become readable by anyone and must live in server-side code instead.

Does Bolt.new handle Supabase security for me?

No. Bolt can wire your app to Supabase, but it does not guarantee Row Level Security is enabled or that your policies are scoped correctly. With RLS off, anyone with your public anon key can read or write the table directly. Check RLS and your policies in the Supabase dashboard before launch.

How do I check my deployed Bolt.new app is safe to launch?

Open the deployed URL, not just the Bolt preview, and confirm what actually shipped. Check that no private secret is in a VITE_ variable, that Supabase RLS is on if you use it, that login and logout behave correctly, and that one user cannot reach another user's data. A free scan of the live URL will also flag exposed keys and obvious public exposure.