Bolt.new App Launch Security Checklist: 16 Items Before Going Live

TL;DR

Bolt.new apps typically use Supabase and deploy to Vercel. Before launch, verify RLS policies on all database tables, check that environment variables are properly configured, test authentication flows end-to-end, and confirm no API keys appear in client-side code.

Bolt.new generates full-stack applications quickly, but speed comes with trade-offs. The generated code often works perfectly in demos but needs security hardening for production. This checklist covers the specific issues we see in Bolt.new projects.

Supabase Database Security 5

Verify RLS is enabled on ALL tablesIn Supabase dashboard, check each table. Bolt may only enable RLS on some tables.

Review each RLS policyEnsure policies use auth.uid() correctly and don't allow broader access than intended

Test cross-user data accessLog in as User A, try to fetch/modify User B's data by changing IDs in requests

Check for public tablesTables without RLS policies are readable by anyone with your Supabase URL

Verify service role key is not exposedThe service_role key bypasses RLS. It should never appear in client code.

Environment Variables 4

Set all env vars in deployment platformCheck Vercel/Netlify settings. Missing env vars cause runtime errors.

Confirm only anon key is publicNEXT_PUBLIC_SUPABASE_ANON_KEY can be public. Service role key must stay private.

Search codebase for hardcoded secretsGrep for supabase, sk_, pk_, api_key, password, secret in all files

Verify .env files are gitignoredCheck .gitignore includes .env, .env.local, .env.production

Authentication 4

Test protected routes without loginAccess /dashboard, /app, /settings directly. Should redirect to login.

Verify API routes check authCall API endpoints directly without auth headers. Should return 401.

Test email verification (if enabled)Can users access the app without verifying their email?

Check session handlingLog out and use back button. Verify you can't access protected content.

Pre-Launch Final Checks 3

Test the production URL directlyDon't just test preview deployments. Test the actual production URL.

Verify HTTPS is workinghttp:// should redirect to https://. No mixed content warnings.

Run automated security scanCatch issues you may have missed with manual review

Common Bolt.new Security Issues

Based on scanning hundreds of Bolt.new projects, here are the issues we see most frequently:

The good news is that these issues are straightforward to fix. The bad news is that they're easy to miss if you don't specifically look for them.

Bolt.new can create production-ready apps, but the generated code requires security review. Common issues include incomplete RLS policies, exposed API keys in client code, and authentication gaps. Always review security before launching.

What should I check before deploying a Bolt.new app?

Check Supabase RLS policies, verify environment variables are set correctly, test authentication flows, review client-side code for exposed secrets, and validate that users can only access their own data.

Does Bolt.new automatically secure my database?

No. Bolt.new generates Supabase schemas but may not create complete RLS policies. You need to manually verify that Row Level Security is enabled and that policies correctly restrict data access to authorized users only.