Menu
BOOK A CALL Get a Quote

From Lovable to Production: How to Build a Real Production Environment Without Leaving Lovable Behind

You built something real. You took an idea, opened Lovable, and turned it into a working product: a frontend, backend logic, a database, auth. It works and users are signing up. But now you’re starting to feel the friction.

Maybe Lovable went down and your app went with it. Maybe someone on your team pushed a change that broke something in production and there was no review process to catch it. Maybe you just want to know that your production environment is yours: stable, predictable, and under your control.

The good news: you don’t have to abandon Lovable to get there. You can keep building in Lovable while running a proper production environment alongside it. That’s exactly what we help founders do at FusionWorks, and this article walks you through how we approach it.

The Core Idea: Lovable for Development, Production on Your Terms

The migration most people imagine is an all-or-nothing move: rip everything out of Lovable, rewrite what you need, and never look back. That’s expensive, risky, and usually unnecessary, especially at the stage where you’re still iterating fast.

What we propose instead is a dual-environment setup:

  • Lovable stays your rapid prototyping and development tool. Founders and non-technical team members can keep making changes there.
  • A separate production environment runs on infrastructure you control – Cloudflare Pages for the frontend, Supabase’s own cloud for the backend and database.
  • GitHub sits in the middle, syncing changes from Lovable to production through pull requests and a proper review process.

This means you get the speed of Lovable and the stability of a controlled production deployment. Changes flow from Lovable through GitHub, get reviewed (by your team or ours), and only then reach your users.

What Lovable Is Actually Made Of

Before you can migrate anything, you need to understand what Lovable assembled for you under the hood.

Lovable uses Supabase as its backend layer. Your database, your Edge Functions, your authentication, it all lives in a Supabase project that Lovable manages on your behalf. The frontend is a standard SPA (Single Page Application) built with Vite and React, and Lovable handles the build and deployment for you.

When you connect Lovable to GitHub (which you should do immediately if you haven’t), you get a repository with two main areas: a src folder containing your frontend code and a supabase directory containing your Edge Functions code and database migrations.

That repository is your escape hatch. Everything you need to run independently is in there, with a few catches we’ll get to shortly.

The Migration Path: Step by Step

1. Audit Your Repository

Start by pulling down your Lovable-connected GitHub repo and actually reading through it. Pay special attention to two things:

Database migrations. Lovable generates these as you build, but the ordering isn’t always clean. We’ve encountered cases where a security policy for a table was created in a migration that ran before the migration that created the table itself. Go through the migration files in order and make sure each one only references objects that already exist at that point in the sequence. You may need to reorder or merge a couple of files.

The config.toml file in the supabase directory. This contains your Supabase project configuration: the project ID it’s linked to, which features are enabled, and importantly, the JWT verification settings for your Edge Functions. We’ll come back to this.

2. Set Up Your Production Infrastructure

We recommend the following stack for most Lovable migrations – it’s cost-effective, gives you full control, and each piece can be swapped independently later:

Supabase Cloud for your database, Edge Functions, and authentication. You’ll create a new Supabase project directly on supabase.com. This gives you access to features and configuration options that Lovable’s managed Supabase instance doesn’t expose.

Cloudflare Pages for your frontend. The free tier is generous and more than sufficient for most early-stage products. It gives you global CDN, automatic builds from GitHub, and preview deployments for every branch.

The key benefit of this split: each piece runs on infrastructure optimized for its purpose, and you’re not locked into any single vendor.

3. Navigate the Supabase Gotchas

This is where real-world experience saves you hours of debugging. Here are the issues we’ve hit and solved:

API key types. Supabase has different types of API keys, and Lovable may have been using legacy keys. Before you update your codebase to use the new project’s keys, check which type Lovable was using and make sure you match it or deliberately migrate to the newer format.

JWT verification on Edge Functions. By default, Supabase Cloud enables JWT verification on all Edge Functions. Lovable typically disables it. If you deploy your functions and immediately start getting 401 Unauthorized errors even though your keys are correct, this is almost certainly the cause. Check that your config.toml has verify_jwt = false under each function definition or better yet, take this opportunity to properly implement JWT verification.

Data API settings. The inverse problem: Lovable enables the Data API by default, but a fresh Supabase project has it disabled. If your Edge Functions are calling Supabase’s REST API internally, you’ll need to flip this on.

4. Deploy Your Frontend to Cloudflare Pages

Connect your GitHub repository to Cloudflare Pages and set up a build. A few things to watch for:

The lockfile problem. Cloudflare’s default build tool is Bun, and if there’s a bun.lock or bun.lockb file in your repo (Lovable may have created one), Cloudflare will use Bun regardless of what you want. If your project was built with npm, delete the Bun lockfile from your repo. This avoids subtle dependency resolution differences that can cause build failures.

SPA routing. This one bites everyone. Lovable handles SPA routing internally and doesn’t export any routing configuration to your repo. When you deploy to Cloudflare Pages, navigating directly to any route other than / will give you a 404. You need to configure Cloudflare to serve your index.html for all routes. The simplest approach: add a _redirects file to your public folder with /* /index.html 200.

Branch configuration. Since we’re maintaining backward compatibility with Lovable, we recommend creating a dedicated branch for your production deployment (e.g., production). Configure Cloudflare Pages to build from this branch. Changes from Lovable flow into main, get reviewed, and are merged to production when ready.

Domain and auth settings. Once your Cloudflare deployment is live (either on a custom domain or the preview URL), go back to your Supabase project and update the URL Configuration in Authentication settings. Without this, OAuth flows and email links will point to the wrong place.

5. Handle the Lovable AI Dependency

This one catches people off guard. If your app uses any AI features – chatbots, summaries, document Q&A, sentiment analysis, image understanding – Lovable provides those through its own AI proxy called Lovable AI. It gives your app access to models like Gemini, GPT-5, and others without requiring you to set up API keys or billing with providers directly. It just works inside Lovable.

The problem is that Lovable doesn’t expose this API for use outside their platform. Once your app is running on your own infrastructure, any feature that calls Lovable AI will simply stop working.

You have a few options here, and which one you pick depends on how you want to manage the transition:

Option A: Replace with OpenRouter. This is our recommended approach for most cases. OpenRouter gives you a single API that routes to dozens of LLM providers: Anthropic, Google, OpenAI, and more. You swap out the Lovable AI calls for OpenRouter calls, keep one API key, one billing account, and you can switch between models without changing your code. It’s the closest equivalent to what Lovable AI was doing for you.

Option B: Go direct to providers. If you know exactly which model you need (say, Claude for your chatbot, Gemini for image analysis), you can integrate with each provider’s API directly. More control, but more API keys and billing relationships to manage.

Option C: Make it configurable. This is the approach we often take when founders want to keep building in Lovable while running production separately. You abstract the AI call behind a configuration flag – in the Lovable development environment, it uses Lovable AI; in production, it routes through OpenRouter or a direct provider API. Same codebase, different backends depending on where it’s running. This preserves full backward compatibility with Lovable while giving production its own reliable AI layer.

Whichever route you choose, the code changes are usually straightforward, Lovable AI calls follow a standard pattern, and replacing them with an OpenRouter or direct API call is mostly a matter of swapping the endpoint and adding an API key from environment variables.

6. Establish the Sync Workflow

This is where the real value of our approach becomes clear. Here’s how the day-to-day workflow looks:

  1. Founders and team members build in Lovable as they always have. Lovable pushes changes to the main branch on GitHub.
  2. A pull request is created from main to production (this can be automated).
  3. The PR gets reviewed, either by your team or by FusionWorks engineers. This is the quality gate. We check for breaking changes, security issues, and anything that shouldn’t go to production without testing.
  4. Once approved, changes merge to production and Cloudflare automatically builds and deploys.
  5. Professional development work (bug fixes, performance improvements, features that need proper engineering) happens on feature branches, goes through its own PR process, and merges to production independently.

This gives you the best of both worlds: Lovable’s speed for rapid iteration and a professional engineering workflow for production stability.

Why This Matters

We’ve seen it too many times: a founder builds something great in Lovable, gets real users, and then hits a wall. Lovable has an outage and their product goes down. An accidental change breaks something critical. There’s no staging environment, no review process, no way to roll back.

Going from a working prototype to a production-grade setup doesn’t have to mean a complete rewrite. It means putting the right infrastructure and processes around what you’ve already built.

At FusionWorks, we’ve been building production software for over a decade. We know how to take what you’ve created in Lovable, which is real, working code, and give it the production foundation it deserves. And we do it in a way that lets you keep moving fast in Lovable while your production environment stays rock solid.

FusionWorks helps founders migrate from AI-powered platforms to production-grade environments. If you’ve built something in Lovable and you’re ready for production stability without slowing down, get in touch.