Lovable GitHub export — code out, then what?

You wired lovable github, pushed clean commits, and still have no live app — because the repo is not the same thing as production hosting.

Export felt like freedom. Version control, CI, your own Vercel team. The first push succeeded. Vercel built green or failed on missing config. The live URL loads a shell, auth dies, or env errors flood the log. Lovable preview still works when you open the editor. GitHub holds code. It does not hold Supabase Site URL, Stripe webhooks, or the production env drawer.

What you see after lovable github sync

Patterns repeat across forum threads.

• Repo exists, site does not. GitHub shows files. No deployment connected or wrong branch.
• Vercel build fails. Framework detection wrong, Node version mismatch, or missing build command.
• Build passes, runtime empty. Env vars never copied from Lovable preview to Vercel Production.
• Auth loops on Vercel URL. Supabase Redirect URLs omit *.vercel.app or your custom domain.
• Two sources of truth. You edit in Lovable and in GitHub; last sync overwrote manual fixes.
• Secrets in git history. Panic after committing .env — rotate keys before going live.

Code out of Lovable is step one. The lovable deploy checklist is step two through five: auth URLs, webhooks, RLS, env, SSL.

Why lovable github does not ship production for you

Lovable’s GitHub integration mirrors project files. It does not provision Vercel, Netlify, or DNS. The AI built against preview keys inside the editor. Those integrations stay in Lovable’s environment unless you transcribe them.

Vercel clones the repo and runs npm run build. It reads env from the Vercel dashboard — not from Lovable’s connected Supabase panel. A successful Git push does not copy VITE_SUPABASE_URL into Production. See vercel env vars for the copy-and-redeploy flow.

Auth breaks on a new hostname for the same reason as first publish. Supabase allows preview and localhost. Your new project.vercel.app or custom domain is not listed until you add it. OAuth in Google Cloud has the same gap.

Custom domains add DNS and SSL work after GitHub. Connecting repo and domain are separate clicks. SSL pending while you test auth creates false “github broke my app” reports.

The AI may generate a README with deploy steps. It cannot click Vercel Import or set Production checkboxes. That manual gap is the product boundary — not a failed export.

Teams that treat GitHub as “done” skip the same five production settings as first-time Lovable publish. Export changes where you edit. It does not change what production requires: live secrets, auth allowlists, webhook endpoints, row policies, valid TLS.

Deploy after lovable github step by step

1. Confirm the GitHub repo and branch. Default is often main. Lovable should push there on publish. Open GitHub and verify latest commit time.
2. Import to Vercel (or your host). New Project → Import Git Repository. Select the Lovable repo. Match framework preset to Vite or Next as your project uses.
3. Set build settings. Install command, build command, output directory — match what Lovable used. Wrong output dir serves an empty folder.
4. Copy every env var to Vercel Production. Open Lovable integrations or your local .env.example. Add each name in Vercel → Settings → Environment Variables with Production enabled.
5. Deploy once env is complete. Trigger production deployment. Read build log for missing modules or type errors.
6. Update Supabase URL configuration. Add Vercel production URL, preview URLs, and custom domain to Site URL and Redirect URLs.
7. Register Stripe webhooks on the live Vercel domain. Paste whsec_ into Vercel Production env. Redeploy.
8. Attach custom domain in Vercel if needed. Fix DNS and SSL before you remove the default Lovable URL from auth allowlists.
9. Choose edit workflow. Keep syncing Lovable → GitHub, or work only in the repo. Document which side wins to avoid overwrite surprises.

After the first successful Vercel deploy, test in a private window on the Vercel URL — not only in Lovable preview.

Branch protection and preview deployments help catch env gaps before production. Turn on Vercel Preview env vars for pull requests, then mirror the same names into Production before you merge to main. Skipping Preview env teaches nothing; Production still ships blind.

Checklist after lovable github is connected

• GitHub repo has recent commits from Lovable or your IDE
• Host project linked to that repo and correct branch
• Production deployment status is Ready
• All client and server env vars exist for Production on the host
• Supabase Redirect URLs include Vercel and custom domains
• No secrets committed — rotate if .env was pushed
• Live URL passes login and one data operation
• Team knows whether Lovable or Git is the source of truth

FAQ

What happens after I connect lovable github?

Lovable syncs your project to a GitHub repository on each publish or manual sync. The repo contains source code, not production secrets, DNS, or Supabase URL configuration. You still need a host, env vars, and auth dashboard updates.

Why does my app break after lovable github export to Vercel?

Vercel builds from the repo without Lovable preview secrets. Missing VITE_ or NEXT_PUBLIC_ vars, wrong framework settings, or auth still pointing at localhost causes the same failures you saw on first publish.

Do I still use Lovable after connecting github?

You can keep editing in Lovable and syncing, or switch to Cursor or another IDE on the repo. Either way, production depends on the connected host’s env and Supabase settings, not the Lovable secret drawer alone.