Lovable vs Bolt vs Replit: security defaults compared

Lovable, Bolt, and Replit will each take a prompt and publish a URL. They don't document a shared security score, and this page won't invent one. Everything below comes from their own docs about stacks, secrets, and databases, plus two facts that are true of any published website: the URL is public, and a key inside the JavaScript is public. Where two of a vendor's pages disagree, both are linked so you can check the product you actually have.

Deploy Safely doesn't log into these builders. The free check looks at the published page. The docs below are how you interpret what it finds, and what it can't see because it lives only in the builder's dashboard.

What Lovable documents

Lovable's FAQ says new apps created from May 13, 2026 use TanStack Start, which renders pages on the server. Enterprise workspaces pick that up from June 22, 2026. Older apps use React and Vite and render in the browser. The FAQ also says you can't pick a different framework or database. The database is PostgreSQL through the built-in backend (Cloud) or Supabase. Hosting repeats the May 13, 2026 date for server-side rendering, and notes that older apps serve rendered pages to verified crawlers, not to every third-party tool.

Secrets is the page that matters for keys. Lovable says secrets are encrypted, injected into Edge Functions, and never reach the browser. You usually add them through a secure input in the chat, not by pasting them into a file. The same page draws a hard line at the VITE_ prefix. Anything with that prefix is a build-time, browser-exposed value and must live in the project's .env file, not in Secrets. Their examples of backend secrets include STRIPE_SECRET_KEY, RESEND_API_KEY, and OPENAI_API_KEY. Their examples of frontend variables include VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY. They say those frontend values are embedded into the client bundle and are safe to be public.

Lovable also says not to add .env to .gitignore in a Lovable project, because the build needs those VITE_ values for previews and published builds. That's a Lovable-specific instruction. It's safe only if .env contains the public values, not the secret ones. The secrets page says a VITE_ name is rejected if you try to store it as a secret.

Reserved names are filled in for you. Prefixes SUPABASE_ and LOVABLE_ can't be created in the Secrets UI. SUPABASE_SERVICE_ROLE_KEY is one of the values Lovable says is populated when Cloud or a connected Supabase project is enabled, and that Edge Functions can read with Deno.env.get. You shouldn't need to paste that key into a component. If the project uses an external Supabase project, the page says secrets are managed in Supabase and the backend view links you there.

What Lovable's pages don't say: they don't claim that Cloud tables ship with a particular row-level security policy already written for your schema. The database is Postgres, so Supabase's row-level security model is the one to apply. The Lovable guide is the short version of the checks, and row-level security in plain English is the longer one. If Cloud doesn't put a supabase.co host in the published page, a public URL check can't list those tables.

What Bolt documents

Bolt's Supabase integration page says that for most projects, Bolt Database is the simpler default: it works without extra setup. Supabase is optional. On paid plans you can choose Supabase when you create a project, after connecting a Supabase organization under account settings. A Bolt account connects to one Supabase organization. Bolt's database page says there is currently no supported way to migrate an existing Bolt database to Supabase. You choose Supabase at the start of a new project if you want it.

Secrets settings says secrets are used by server functions (also called edge functions) so the function can read an API key or database password without exposing it to users. The page says private information should never end up in users' browsers or devices. Bolt prompts you when a message such as "Integrate OpenAI" needs a secret, and the value is hidden as you type. The same page says to rotate keys, remove unused keys, and never store secrets in plain text in your code. Who can open the Secrets tab depends on the role. Editors and viewers on a team account don't get it.

Introduction to databases lists environment variable names for a Supabase connection: VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY, and SUPABASE_SERVICE_ROLE_KEY. That page describes environment variables as a way to keep keys private and out of source control. Read that next to Vite's env guide, because the VITE_ prefix is Vite's switch for "expose this in client source." Vite says VITE_ variables shouldn't contain sensitive information such as API keys. The anon key is a publishable Supabase key, so putting that one in a VITE_ variable matches Supabase's own guidance. The service role key in that list shouldn't use the VITE_ prefix. Bolt's secrets page is the place they tell you to put server-only values.

What these pages don't say: they don't document row-level security behavior for Bolt Database. Deploy Safely can't open Bolt Database or read its access settings. If the published page has no supabase.co URL and no anon JWT, the Supabase table check doesn't run. Confirm private records in Bolt's database settings yourself. The Bolt guide says the same thing.

What Replit documents

Replit's Secrets page says the tool stores and encrypts sensitive values, including API keys, tokens, and database connection strings, and exposes them to the project as environment variables. They list three ways hard-coding leaks: sharing a public Replit project, checking the code into a public repository, and live streaming or screen sharing. Configurations, in the same tool, are for non-sensitive settings such as log levels and public URLs. The page says not to store API keys or passwords as configurations.

Here's a limit that is easy to miss: secrets are available for all deployment types except Static Deployments. A static publish doesn't get that environment. If the agent printed a key into an HTML file because the static deploy had no secret store, the key is in the site.

Two publishing pages describe how secrets reach the live app, and they don't use the same sentence. The publishing overview says deployment secrets sync automatically from the development environment when you publish or republish, and that Replit always runs a security scan before publishing. A setting controls whether publishing is blocked when that scan reports critical vulnerabilities. The overview doesn't list what the scan detects. Troubleshoot publishing says secrets set in the project editor don't automatically carry over, and that you add production secrets in the Publishing pane. If you're about to share a URL, open Publishing and read the production values. Don't assume the editor and the deploy match. The Replit guide is about the published URL, which is the part a stranger can open without your account.

What is the same on all three

Each product's docs tell you to keep real secrets out of the files the browser downloads, and each one gives you a secrets area for server-side code. Each one can still publish a frontend that contains a public Supabase key or a Firebase web key. Those public keys are fine only when the database rules are on. None of the three pages above is a substitute for reading the Supabase or Firebase rules on the project you connected.

A free Deploy Safely check does the same thing no matter which builder you used. It fetches the public page and its scripts. It looks for common secret shapes, including a Supabase service role JWT, and it treats a Supabase anon JWT as expected. It requests /.env, /.git/HEAD, /.git/config, and /.npmrc. It follows a source map only when a script already points at one and the map includes original source. It asks Supabase or Firebase for data only when that config is already on the page. It notes missing security headers when two or more of the watched ones are absent on the main response. It doesn't open Lovable, Bolt, or Replit, and it doesn't read their secret stores. A clear result is about that public page. The checklist is the pass that includes the dashboards.

Review this project against the security defaults in the builder's own docs. Do not print secret values.

1. Move API keys, service role keys, and database passwords out of client code. In a Vite app, do not prefix secrets with VITE_. In Lovable, put backend secrets in Secrets and keep only public VITE_ values in .env. In Bolt, put server-function secrets in the Secrets tab. In Replit, use the Secrets tool, and confirm production secrets in the Publishing pane. Static Replit deploys do not receive Secrets.
2. If the app uses Supabase, keep the anon or publishable key in the browser and enable row-level security on every exposed table. Do not ship the service role key. If the app uses Bolt Database, keep private records limited to the signed-in user and tell me where that is configured.
3. If the app uses Firebase, replace test-mode or allow-all rules. The web API key may stay in the client.
4. Make sure the published site does not serve .env or .git, and turn off production source maps.
5. List anything that was already public so I can rotate it in the vendor's dashboard.

Do not weaken a rule so the preview will load.