Lovable vs Bolt vs Cursor: the deploy errors each one tends to hit

How deploys fail differently for apps built with Lovable, Bolt.new and Cursor, and what to check first for each.

Why the tool matters

Lovable and Bolt run your app inside their own environment while you build, then publish it somewhere else. Cursor is an editor, so your app runs wherever you set it up. That difference decides where things break: hosted builders tend to break at the hand-off between preview and production, while Cursor projects break wherever your own config is incomplete.

Lovable

Lovable generates a Vite and React front end, usually backed by Supabase. Common breaks: Supabase tables without row level security, auth redirect URLs still pointing at the preview domain, and secrets added as VITE_ variables, which Vite puts into the public bundle. Check Supabase Authentication URL configuration and RLS first.

Bolt.new

Bolt builds and previews in the browser using WebContainers. Things that work in the preview can fail on your host: env vars that were never added to the host, server functions that need JWT verification turned off for third-party webhooks, and a missing SPA rewrite so sub-pages 404 on refresh. Bolt's own troubleshooting docs cover integrations and webhook JWT settings.

Cursor

With Cursor you own the whole stack, so there is no platform default to fall back on. Typical breaks: the build passes in dev mode but fails type checks or lint on the host, dependencies installed globally but missing from package.json, file name case mismatches on Linux builders, and env vars present locally but not in production.

What to check first, for any of them

Run the production build locally. Compare every variable in .env with the host's settings. Test a deep link with a hard refresh. Sign in from a second account and confirm you cannot see the first account's data.

Sources

Have a specific error? Try the error explainer or the pre-launch checklist.