Lovable deploy: the five settings the editor never asked you for

Your lovable deploy looked done the second the preview went green, then production turned into five separate bugs wearing one URL.

Publish copies your frontend to a live host. Auth still points at localhost. Stripe still listens on a tunnel you closed yesterday. Supabase still accepts reads from anyone with the anon key. Env vars from your laptop never reached production. The custom domain shows a certificate warning. Each failure feels new. They are the same five settings the editor never asked you to confirm.

What you see right after lovable deploy

Login loops or does nothing. A customer pays and your database stays empty. Saves vanish on the live site, or anyone can read rows through the API. Server routes throw errors because process.env is undefined. A custom domain loads with Not secure or fails entirely.

The editor optimizes for “make it work here.” Live traffic needs URLs, secrets, webhooks, policies, and TLS you configure outside the chat panel.

Auth Site URL and redirect URLs

Supabase sends magic links, password resets, and OAuth callbacks to your Site URL and Redirect URLs. During build, that is almost always localhost or the Lovable preview origin.

After publish, sign-in loops, magic links open localhost, and sessions never stick. The AI wired auth against preview. Nothing updates when you publish to yourapp.lovable.app or a custom domain unless you edit Supabase.

1. Copy your live origin after publish, including https://.
2. Open the linked Supabase project. Preview and production must use the same project.
3. Set Site URL under Authentication → URL Configuration.
4. Add Redirect URLs for live, preview, and localhost if you still test locally.
5. Update OAuth providers so Google or GitHub callbacks match Supabase.
6. Republish and test in a private window with a fresh magic link.

Full loop fixes live in the lovable login guide.

Stripe webhook endpoint in production

Checkout succeeds while your backend stays deaf. Stripe shows paid. Your database still says free because no live endpoint receives checkout.session.completed or invoice.paid.

Local dev uses stripe listen tunnels that die when you close the terminal. The AI ships a success page that never calls your server. Stripe POSTs to URLs you register. Localhost registrations do not follow you to production.

1. Deploy the handler route on your live domain first.
2. Switch to live Stripe keys and a live signing secret.
3. Register the live webhook in Stripe Dashboard → Developers → Webhooks.
4. Subscribe to the right events for Checkout and subscriptions.
5. Paste whsec_ into production env, never client-side code.
6. Run one real test charge and confirm delivery logs show success.

See the stripe webhook article for the paid-but-silent walkthrough.

Supabase RLS and row-level policies

RLS is off by default on new tables. The anon key ships in your frontend. Without policies, anyone who reads client code can query rows they should never touch.

After publish, saves fail with permission errors if RLS is on but policies are missing. Or data looks fine while the REST API stays wide open. The AI creates tables and demo rows. It skips ENABLE ROW LEVEL SECURITY because preview used your session or the service role.

Auth URL mistakes and RLS mistakes stack. The supabase auth article covers Site URL setup. Here the focus is who may read and write which rows.

1. List tables with user data — profiles, orders, messages.
2. Enable RLS on each sensitive table.
3. Add policies such as auth.uid() = user_id for select and insert.
4. Test with the anon key, not the service role.
5. Confirm live inserts still work under those policies.

Environment variables in production

Preview reads secrets the editor knows about. Production reads what your host injects. Missing variables pass undefined into Supabase, Stripe, and API routes.

Stripe throws invalid key errors. Supabase fails to init. Server actions crash while the UI still renders. The AI copies .env.example patterns for preview. It cannot push values into your host for you.

1. Search the codebase for every process.env and import.meta.env name.
2. Keep secrets server-side. Only public prefixes belong in the browser bundle.
3. Add each name in your hosting provider’s production env settings.
4. Redeploy after changes — most hosts bake env at build time.
5. Smoke-test login, one save, and one payment.

Custom domain and SSL as a launch blocker

You point DNS at a new domain and expect a padlock. Instead you get certificate errors, parking pages, or redirect loops. The product works on the default subdomain while launch stalls on the hostname you bought.

Custom domains need correct DNS, propagation time, and TLS for the exact hostname users type. Mixed http:// assets on an https:// page cause warnings even when the cert is valid.

1. Add the domain in your host and copy DNS targets exactly.
2. Update registrar records — CNAME for www, ALIAS or A for apex.
3. Wait for DNS and certificate issuance before sharing links.
4. Redirect HTTP to HTTPS and fix hardcoded insecure asset URLs.
5. Update Supabase and Stripe URLs to the final domain, not the temporary preview host.

Checklist before you call lovable deploy done

• Auth: Site URL and Redirect URLs match live. OAuth and magic links work in a private window.
• Payments: Live webhook registered, signing secret in env, test charge updates the database.
• Database: RLS enabled with policies tested via the anon key.
• Env: Every required variable on the host, redeploy done.
• Domain: Hostname resolves, certificate active, HTTPS works, callbacks use the final domain.

When all five switches are on, preview and production describe the same product.

FAQ

Why does my Lovable app work in preview but break after publish?

Preview runs on hosts and keys the AI already wired up. Production uses a different URL, live API keys, webhooks, and Supabase settings you must set manually. Until those five areas match your live domain, auth, payments, and database writes fail silently.

What are the five settings to check before a lovable deploy goes live?

Set Supabase Site URL and redirect URLs, register a live Stripe webhook endpoint, enable Supabase RLS policies, copy every environment variable to production, and confirm your custom domain has valid SSL. Skip one and users hit a different failure on the same URL.

Does Lovable set production environment variables automatically?

No. Lovable can inject keys for preview and connect Supabase or Stripe in the editor. Published builds read from your hosting provider’s production env. Secrets that exist only in local .env files or preview never reach the live bundle unless you add them there.