How to Move a Lovable App to Cloudflare

Before you start: what to have ready

A Cloudflare migration that fails does so in the first five minutes — almost always because of missing env vars or a wrong output directory. Checking these prerequisites before you touch the Cloudflare dashboard saves a full debug cycle. Work through this list now.

1. Confirm your Lovable preview is working — only migrate a stable app.
2. List every environment variable in Lovable Project Settings → Environment. You need all VITE_ prefixed values.
3. Confirm your GitHub repo is connected to Lovable and the latest code is pushed.
4. Check your vite.config.ts for the build output directory — for Vite projects it is dist by default, but some Lovable templates override it.
5. If your app uses Supabase, note your Supabase project URL and anon key.
6. If your app uses Stripe webhooks, note the current webhook endpoint URL — you will need to update it after DNS cutover.

Why choose Cloudflare Pages over Vercel or Netlify?

Cloudflare Pages serves assets from Cloudflare's global edge with no origin server and no cold-start delays. For Lovable apps that are primarily static or use Supabase for all data operations, this means fast load times worldwide with an unlimited-bandwidth free tier. The trade-off is that Cloudflare Workers uses a V8 isolate runtime rather than Node.js, which matters if you add server-side functions.

How do I connect my Lovable repo to Cloudflare Pages?

First connect Lovable to GitHub so your code lives in a repository, then import that repo in the Cloudflare Pages dashboard. Cloudflare auto-detects most Vite projects, but you may need to manually set the build command and output directory if auto-detection picks the wrong preset.

1. In Lovable, open Project Settings → GitHub and push your code to a new repo.
2. Go to dash.cloudflare.com and select Workers & Pages → Create Application → Pages.
3. Connect your GitHub account and select the Lovable repo.
4. Set Build command: npm run build (or vite build if not using npm scripts).
5. Set Build output directory: dist (Vite default — confirm by checking your vite.config.ts).
6. Add environment variables before clicking Save and Deploy.

Which environment variables do I need to copy from Lovable?

Lovable stores your Supabase credentials and any other secrets as VITE_ prefixed variables in its build environment. When you move to Cloudflare Pages, those variables must be added to the Cloudflare dashboard before the first deploy or your Supabase client will initialise with undefined values and the app will appear blank.

How do I update Supabase to allow the Cloudflare Pages domain?

After your first Cloudflare deploy, you will have a *.pages.dev URL. Add it to Supabase Authentication → URL Configuration → Redirect URLs before testing any auth flows. Auth calls from an unlisted origin are rejected by Supabase, which looks like a successful deploy that fails silently on login.

1. Copy your *.pages.dev URL from the Cloudflare Pages dashboard after the first deploy.
2. In Supabase, go to Authentication → URL Configuration.
3. Add the *.pages.dev URL to Redirect URLs.
4. After DNS cutover, add your custom domain to the same list.

Common Cloudflare Pages errors and fixes

Cloudflare Pages surfaces errors differently from Vercel and Netlify. Build failures appear in the Pages deployment log; runtime errors appear only in the browser console or Cloudflare Workers logs. The table below covers the most common issues reported by teams migrating Lovable apps.

What are the most common gotchas when migrating to Cloudflare Pages?

The four most common issues are: missing env vars (blank page), Supabase origin not updated (auth 403), the build output directory set to build instead of dist (deploy succeeds but returns 404), and vanishing env vars after a re-deploy because they were only set for the Preview environment and not Production. Double-check all four before cutting DNS.

How do I roll back if the Cloudflare Pages migration breaks?

Cloudflare Pages retains every deployment and lets you restore any previous build via the dashboard — no rebuild needed. If your DNS is already managed by Cloudflare, rolling back a domain cutover is a single record change that propagates in seconds on Cloudflare's own network, which is faster than waiting for external DNS TTLs to expire.

1. In the Cloudflare dashboard, go to Workers & Pages → your project → Deployments.
2. Find the last stable deployment and click the three-dot menu → Rollback to this deployment.
3. If your DNS is on Cloudflare, edit the CNAME record in DNS back to Lovable's hostname — the change propagates within seconds on Cloudflare's network.
4. If DNS is on an external provider (GoDaddy, Namecheap), update the CNAME there and allow for propagation delay.

How do I handle auth password hashes when moving to a new Supabase project?

If you are migrating to a fresh Supabase project (not reusing the same one), Supabase auth password hashes cannot be exported or transferred. Users will not be able to log in with their existing passwords. Send a password-reset email to all users before cutting DNS, and communicate the reset in advance so users expect it.

Post-migration smoke test for Cloudflare Pages

Cloudflare's V8 isolate runtime behaves differently from Node.js, which means some issues only appear after deploy and not during local testing. Run this checklist on your *.pages.dev URL to catch Workers-specific failures — especially missing environment variables and process-not-defined errors — before any live user traffic hits the new domain.

1. Load the home page and check for console errors about undefined env vars — Cloudflare Preview/Production scoping is the most common source.
2. Sign in with a Supabase account and hard-reload — confirm the session survives (Cloudflare caching headers can interfere with auth cookies).
3. Open Cloudflare Pages → Functions → Real-time Logs and trigger a Worker function — confirm no 'process is not defined' or Node.js-specific errors.
4. Verify Supabase Redirect URLs include both your *.pages.dev URL and your custom domain before declaring the migration complete.