Yes, you can deploy a Lovable app through GitHub to Cloudflare. The important part is understanding what you are actually moving.
A production app is not one object. Source code, frontend hosting, database, authentication, storage, secrets, domain and deployment configuration can live in different systems. Moving the frontend does not automatically migrate the rest of the product.
The safest sequence is:
Lovable → GitHub → reproducible build → Cloudflare deployment → production tests → domain cutover.
Lovable’s current deployment and ownership documentation says projects can sync to GitHub, run on external infrastructure and move frontend and backend components independently. That separation is the key to avoiding a migration that creates several unknowns at once.
1. Put the deployable code in GitHub first
Before touching Cloudflare, confirm:
- the business controls the repository;
- the intended current code is present;
- the production branch is known;
- a clean checkout can install and build;
- the intended production commit can be identified.
GitHub should be a reproducible source of truth, not merely a backup.
If another developer may take over later, also read my Lovable developer handoff guide. A handoff includes the backend, domains, secrets and product rules as well as code.
2. Map the application before choosing deployment commands
Start by separating the layers.
The frontend contains the browser experience. The backend may provide database tables, authentication, storage, realtime features and server-side functions. Other providers may handle payments, email, analytics or AI calls.
Lovable’s external hosting guide explicitly separates frontend deployment from backend migration. You can host the frontend elsewhere while keeping the backend where it is. If the backend moves too, the frontend must then point to the new backend.
For many products, changing one layer at a time is safer than moving everything together.
3. Prove the build before debugging Cloudflare
From a clean GitHub checkout, verify that dependencies install and the production build succeeds.
Also document required environment variables and test direct navigation to important routes. If the application cannot build reproducibly before Cloudflare is involved, Cloudflare is not yet the problem.
This is also the point to check for exposed credentials. Lovable’s current security guidance states that browser code is public and should not contain secrets. Privileged credentials belong behind a trusted server-side boundary.
4. Make the production target explicit
When you connect the repository to Cloudflare, record the answers to five questions:
- Which repository is being built?
- Which branch triggers production?
- Which build command succeeds?
- Which environment variables exist in production?
- Which commit is currently deployed?
These facts matter because several failures look identical from the outside. A stale branch, failed build, wrong deployment target and missing environment variable can all produce “my Lovable changes are not live.”
Do not reconnect tools or rewrite the application until you know which boundary failed.
5. Test the Cloudflare version before moving DNS
Your real domain should be the last step, not the test environment.
On the Cloudflare deployment, test:
- homepage and nested routes;
- sign-up, login and logout;
- authenticated database reads and writes;
- file uploads if used;
- server or Edge Function calls;
- payment test flows if applicable;
- a clean private-browser session;
- mobile behavior;
- failure states as well as successful flows.
If authentication or database access fails before the custom domain is connected, changing DNS will not fix it.
6. Move environment variables deliberately
Classify each value as browser-safe configuration or a server-only secret.
Pay special attention to backend project URLs, API credentials, OAuth settings, payment keys, email credentials and callback URLs. Never solve a missing production variable by putting a privileged database or payment secret into browser code.
If the app uses Supabase or another backend, confirm that production points to the intended production project rather than a development database.
7. Do not confuse code export with backend migration
This is the biggest ownership trap.
Lovable’s current external-hosting documentation shows that moving a Lovable Cloud backend to managed Supabase can involve SQL migrations for schema, while table data, storage files, authentication providers, environment variables and secrets require separate handling. It also warns that user passwords cannot simply be exported, so an auth migration can require a password-reset plan.
A GitHub repository therefore proves code portability. It does not by itself prove that users, files, data and production state have moved.
Before moving a backend, inventory these layers:
| Layer | Production question |
|---|---|
| Code | Is the current app in the business-controlled repository? |
| Schema | Can the production database structure be recreated? |
| Data | Has real production data been migrated and checked? |
| Auth | Can existing users still sign in? |
| Storage | Are uploaded files present with correct permissions? |
| Secrets | Have server credentials been recreated securely? |
| OAuth | Are provider credentials and callbacks correct? |
| Domain | Will DNS move only after the new environment works? |
If you are only moving frontend hosting, do not create unnecessary backend migration risk.
8. Keep security and testing in the definition of “deployed”
A successful build is not proof that an app is ready for real users.
Lovable’s Project Security view checks RLS, database configuration, application code and dependency risks. Its testing documentation also separates browser testing, frontend tests and backend verification.
For a serious launch, verify that one user cannot read another user’s private records, privileged actions are enforced server-side, critical journeys can be repeated reliably, and failed or duplicated requests cannot corrupt important state.
My AI-built app production checklist covers the wider launch review.
9. Move the custom domain last
Once the Cloudflare-hosted version works, connect the real domain and verify HTTPS, apex/www behavior, auth callback URLs, canonical URLs, redirects, analytics, forms and transactional email.
For a live product, preserve the previous environment long enough to give yourself a rollback path. Deleting the old setup before the replacement is proven turns a cutover problem into an emergency.
10. Know when not to migrate
Portability is valuable. Migration for its own sake is not.
Lovable’s current ownership guidance recommends moving components when a real constraint appears, such as compliance, data residency, unsupported networking, infrastructure policy or another concrete operational requirement.
That is a useful principle for AI-built products generally:
Own the escape route before you need it, but do not exercise it merely to prove it exists.
If Lovable Cloud is reliable and fits the product, a business-controlled GitHub repository, tested backups and a documented migration path may be enough for now.
Production deployment checklist
Before calling the move complete, confirm:
- The business controls the GitHub repository.
- The intended production commit is known.
- A clean production build succeeds.
- Cloudflare is connected to the correct repository and branch.
- Production environment variables are configured.
- No privileged secret is exposed to the browser.
- Authentication works in a clean session.
- Database access rules still hold.
- Critical user journeys have been tested.
- The Cloudflare deployment works before DNS cutover.
- Domain and OAuth callbacks are correct after cutover.
- A rollback path exists.
When engineering help becomes worth it
If your Lovable project already has real users, private data, payments or business-critical workflows, this stops being a simple hosting tutorial. The useful work is deciding which layers should move, which should stay and how to prove that user state survives the change.
If you want help turning an AI-built product into a controlled production system, see my MVP development service or contact me.
