How to migrate a Lovable app and deploy it to Retool

If you built your app in Lovable, Retool lets you bring it into Retool's governed environment, preserving what you built and adding the permissions layer, audit logs, and access controls that production internal tools require.

The migration runs through Retool's import agent. You hand it the zip Lovable exports, and it reads the code, ports the interface, and rebuilds the data layer on a Retool resource, asking for your approval before anything runs. This guide walks one real app through the process end-to-end.

What you'll migrate: A customer onboarding tracker

We'll migrate a customer onboarding tracker from Lovable directly into Retool. There will be no intermediate preparation: the zip file you get from Lovable can go straight into Retool, and Retool will convert the code and data into a Retool app.

Our customer onboarding tracker is a single-screen workspace built in Lovable. It lists customers with status filters, owners, and progress. A side sheet manages each customer's checklist, owner assignment, and notes, and dialogs handle adding customers and team members. Behind it sits a Supabase backend with three tables: customers, team_members, and checklist_items.

By the end, you'll have the same app running in Retool, connected to live data sources, with resource-level permissions, audit logging, and SSO enforced automatically. The interface and behavior your team knows carry over intact.

Prerequisites

A working React app in Lovable. To export, you can either use the GitHub integration or use Code Mode to download your codebase directly (Code Mode is only available on paid plans)
A Retool account. You can migrate apps using the Retool free plan
A data source to connect (PostgreSQL, a REST API, or similar)
Basic React familiarity

Note: Retool supports app imports of 50 MB or smaller. Larger projects will have to be trimmer before importing.

Step 1: Export Your App from Lovable

Here is our app in Lovable:

Lovable offers two options for exporting your project.

Sync the project to GitHub from Lovable

Lovable's GitHub integration works in two layers. A workspace connection authorizes the Lovable GitHub app on your GitHub account or organization. A project connection then links one Lovable project to one repository. You set up the workspace connection once and reuse it across projects.

First, connect your workspace to GitHub. You'll need workspace admin or owner permissions for this part:

1.
Go to Workspace settings → Git → GitHub and click Add connection. (If the project isn't connected yet, Project settings → Git → GitHub gets you to the same place.)
2.
Click Add account. A GitHub pop-up opens.
3.
Choose the account or organization, select All repositories or Only select repositories, and click Install & Authorize.

Lovable detects the installation automatically and saves it as a reusable workspace connection.

Next, connect the project itself:

1.
Open Project settings → Git → GitHub, or use the + menu in the chat.
2.
Click Connect next to the workspace connection where the new repository should be created.

Lovable creates a new GitHub repository and immediately starts a two-way sync. Edits made in Lovable appear in GitHub, and changes pushed to the active branch sync back into Lovable. Sync covers one branch at a time, the repository's default branch (usually main) unless you switch it.

Use Code Mode to download the codebase

If you just want the code without GitHub: on paid plans, open Lovable's Code editor and click Download codebase at the bottom of the file tree sidebar.

This will download a zip file containing all the code from your Lovable project.

What's inside a Lovable export

The repository Lovable creates is a standard Vite + React + TypeScript project. There's no proprietary wrapper or Lovable-specific runtime; what syncs to GitHub is the same project structure you'd get scaffolding a Vite app by hand. Here's the layout for our example onboarding tracker:

index.html at the root, with the entry point at src/main.tsx and the root component at src/App.tsx
src/components/, split between app components (here, onboarding/) and ui/, the shadcn/ui component library Lovable scaffolds (the components.json at the root is its config)
src/integrations/supabase/, containing client.ts and generated types.ts. This is the Supabase wiring you'll deal with in Step 2
src/lib/ and src/hooks/ for utilities and shared hooks
supabase/ at the root, with config.toml and a migrations/ folder holding the database schema
Standard configurations such as: package.json, tsconfig.json, and vite.config.ts

Check that all dependencies are declared in package.json and that you have a src/main.tsx.

Step 2: Prepare your app for Retool Import

In most cases, there's nothing to prepare. Retool accepts the Lovable export as-is: zip the repo you cloned in Step 1 (or use Download codebase in Lovable's Code editor) and import it directly. A Lovable export is a standard Vite + React + TypeScript project, which is exactly what Retool expects.

If the import goes through cleanly, skip ahead to Step 3.

If the import has issues, check for Lovable-specific scaffolding

A few pieces of Lovable's scaffold can trip up an import or a first build. Check these in order:

The lovable-tagger plugin in vite.config.ts. Lovable adds its component tagger as a dev dependency and registers it in the Vite config. It only runs in dev mode, but if the import or build complains about it, remove the import and the plugin entry from vite.config.ts.
Supabase client and missing environment variables. src/integrations/supabase/client.ts reads its URL and key from environment variables. If those aren't present, the app can build fine and then error at runtime. Don't fix data access here; that's Step 4. For now, you only need the app to build.
The root supabase/ folder. This holds Lovable Cloud's backend config and migrations. It doesn't affect the React build, so leave it or delete it. Either way, keep supabase/migrations/ somewhere handy: it's your schema reference when you set up the Retool resource in Step 4.

Confirm the app builds locally

Run npm install and npm run build from the project root. A clean build is all you need; runtime errors due to missing backend connections are expected at this stage and will be resolved in Step 4. If the build succeeds, the export is ready for import.

Step 3: Import your React app into Retool

Retool imports straight from the zip. There's no GitHub connection to configure and no build step on your side. You hand Retool the archive, and an import agent reads the project, asks a couple of questions, and ports the app into your workspace.

Where to find the import in Retool

Create a new app. In the Chat tab of the new app screen (below the starter prompts), expand Import React code. A drop zone appears with Click to browse for a .zip file.

Select the zip of your Lovable export from Step 2. The import starts immediately, and everything that follows happens in the chat panel on the left.

Confirm what replaces the Supabase layer

The agent's first move is reading the app structure. With our onboarding tracker, it identifies the Supabase data layer and pauses to ask which Retool resource should back it, using a Connect Resources form in the chat.

The form describes what it found (here, the customers, team_members, and checklist_items tables with read and write access) and lists your workspace's resources, with a best match flagged. For this walkthrough, we pick retool_db, the built-in Retool Database. You can also choose to use mock data to defer the decision or create a new resource that points to your own database. More on that choice in Step 4.

Review and approve the schema

With a resource selected, the agent checks it for the tables the app expects. They don't exist yet in a fresh retool_db, so it proposes creating them: the status enum, the three tables, supporting indexes, and an updated_at trigger, written with IF NOT EXISTS so the script is safe to re-run. It also offers to seed sample data.

Nothing executes without your approval. The proposed SQL sits in the chat with Run and Deny buttons, so you can read exactly what's about to happen to the database before it does.

What Retool builds when you import a Lovable app

Once the schema is in place, the agent maps the full app. For the onboarding tracker, that meant reading 18 source files and mapping one screen and one data source, then working through a two-step implementation plan: backend functions and shared types first, then frontend types, the data hook, and components.

The end state, as reported in the import summary:

The single-page UI ported faithfully: customer cards, status filters, the per-customer detail sheet with checklists, owner assignment, and notes.
The Supabase data layer was replaced with 12 Retool backend functions over retool_db, consumed through auto-generated hooks.
TanStack Query and Router swapped for the sandbox's React Router and a small refetch wrapper.

The agent flags its substitutions rather than making them silently. In our run, it noted that data freshness now uses manual refetch after each mutation, matching the original's query-invalidation behavior, and that an unused 404 shell was dropped since the app has a single route.

Click Publish, and the app is live. Same interface your Lovable version had, now running natively in Retool with its data layer on a governed resource.

Step 4: Reconnect your app to data sources

Most of this work already happened. The Connect Resources form in Step 3 was the data source decision: the agent identified the Supabase layer, you picked retool_db, and it created and seeded the schema. If you're prototyping or evaluating, you can run on that and skip to Step 5.

The reason to return to this step is the real data. Sample rows in retool_db prove the app works. Production use means pointing it at the database your team actually maintains.

What the import already connected

The onboarding tracker now runs on retool_db, Retool's built-in PostgreSQL database. The agent created the three tables and the status enum there, seeded sample data, and generated the 12 backend functions that read from and write to them. That's a complete, working data layer with one limitation: the data in it is the seed data.

Add your own database in Retool Resources

To connect to a different database, create a resource for it:

1.
From your Retool workspace, open Resources and click Create new, then pick the connector type. For the tracker that's PostgreSQL.
2.
Fill in the connection details: a name and description, the host, port, database name, and credentials. If the database sits behind a firewall, allowlist the Retool IPs shown in the panel on the right of the form.
3.
Click Test connection, then Create resource.

One field worth filling deliberately is the description. It's what the import agent reads when matching resources, so a clear description here is why this database shows up as a best match the next time a Connect Resources form goes looking.

Resources are workspace-level objects, so a connection you create here is reusable by every app in the workspace, not just the imported one. If your team already uses Retool, the database you want may already be in the resource list, which is exactly what the Connect Resources form was searching for in Step 3.

Repoint the app to the new resource

You don't rewire anything by hand. In the app's chat, tell the agent to switch the data layer to the new resource, and it updates the backend functions the same way they were wired during import. If the tables don't exist in the new database yet, it can create them there as well, with the same review-and-run approval as before.

Test before touching governance

Run the app in preview and exercise the paths that hit the database: load the customer list, add a record, update a status. You want data flowing correctly before configuring access rules on top of it.

One thing to register before moving on: the resource connection you just made is also the enforcement point for permissions. Everything in Step 5 hangs off it.

Step 5: What governance you get automatically

Enforcement happens at the resource layer, not inside the app. That's the part of this migration worth understanding, because it means the imported Lovable app inherits the same governance as every other app in the workspace, with no app-level configuration.

None of this was configured in the app. The tracker's code contains no permission checks, no logging calls, and no auth integration; all four features attach at the resource connection made in Steps 3 and 4. That's the practical meaning of resource-layer enforcement: the migrated app is governed because it's connected, and every app connected to the same resource is governed identically.

Step 6: Configure role-based access (Optional)

For a single internal tool, the defaults from Step 5 are enough, and you can skip ahead. This section matters if you're evaluating Retool for broader adoption, because it's where the access model shows how it scales.

Permission settings live under Settings → Permissions. Create a group, then grant it access to the onboarding database resource. For the tracker, a sensible split: the onboarding team gets read-write access so they can update checklists, reassign owners, and move customers between statuses, while everyone else (sales, support, leadership) gets read-only access to check where a customer stands. The grant is defined once, on the resource.

Its scope is the part worth registering. The rule covers every app connected to that resource, not just the tracker. Stand up a churn-risk dashboard against the same database next quarter; the access rules are already in place, with nothing to configure separately.

Step 7: Deploy and share your app

Share internally with your team

Click Publish, then share the app from Retool. Sharing respects the permissions from Step 6, so each person gets the version their role allows. The onboarding team opens the tracker and works their checklists, updates statuses, and reassigns owners; everyone else sees customer progress without the write actions.

Broader deployment options

When the app needs an audience beyond your immediate team, workspace, and organization-level access widen the reach. The same resource permissions continue to govern every one of those paths, so expanding who can open the app never expands what they can do with the data.

The Lovable app is now a governed, production-deployed internal tool. Your team gets the same tracker they had, the same customers moving through the same statuses, with an enterprise access layer running underneath it.

Now, go see what else you can do in Retool.