---
title: "Migrate from Lovable"
description: "Move a Lovable project to your own coding agent and infrastructure: export the code, replace Lovable Cloud, and keep the app running locally and in production."
---

Lovable is an AI coding and hosting platform. It generates a standard TypeScript frontend, and hosts the backend on Lovable Cloud, a white-label Supabase. Moving away means two things: working on the code with a coding agent of your choice, such as Claude Code, Cursor, or Codex, and replacing Lovable Cloud with infrastructure you control.

Specific handles the second part. Your agent defines the database, services, and storage in one `specific.hcl` file, runs everything locally with `specific dev`, and deploys with `specific deploy`.

## Let your agent do it

Most people leaving Lovable are not going to do this by hand, and they don't have to. Install the CLI, then give your agent this prompt:

```
Help me migrate my Lovable project to Specific by following: https://docs.specific.dev/for-ai/lovable
```

```bash
curl -fsSL https://specific.dev/install.sh | sh
```

The agent walks through the steps below with you, runs every command, and asks only for what it cannot know, such as the link to your GitHub repository and any API keys.

## What you own after exporting

Lovable exports your code to GitHub from the project settings. That export contains the frontend and any server code. It does not contain your database, users, or uploaded files: those live in Lovable Cloud and are recreated on the other side.

## The two kinds of Lovable projects

Lovable has generated projects from two frontend stacks, and the backend is wired differently in each:

- **TanStack Start** (current): the app is server-side rendered and already has server functions. Data access runs inside those functions, so they stay as the API layer and only their internals change. No new service and no frontend changes are needed.
- **Vite SPA** (older): a static single-page app that calls Supabase directly from the browser. There is no server, so the migration adds a small backend service that serves the frontend and replaces the generated API.

`specific docs /migrations/lovable` tells the agent how to identify which one a project uses.

## Replacing Lovable Cloud

Lovable Cloud is Supabase, so the backend migration follows [Migrate from Supabase](/migrations/supabase):

- **Database**: the schema transfers as is; it is Postgres on both sides. Schema changes going forward use [Reshape](/guides/reshape).
- **API and authorization**: the generated API and row level security policies become routes and checks in your own backend code.
- **Authentication**: replaced with an auth library or provider, with users stored in your database.
- **Storage** moves to [object storage](/guides/storage), and **realtime** to [sync](/guides/sync) where it is still needed.
- **Lovable AI**: projects that call Lovable's AI gateway switch to the model provider's API directly, with your own API key stored as a secret.

Moving the data itself (rows, users, uploaded files) is a manual step today.

## Testing and deploying

The agent runs the migrated app with `specific dev`, and with `specific dev --tunnel` you can test it from any device. The local dashboard shows your database and files, much like the Lovable interface did.

When it works, the agent deploys it. It does not need you to create an account first: `specific login --agent` registers the agent itself, `specific deploy` publishes the app, and `specific claim` hands the project to your email address. See [Coding agents](/coding-agents) for how that works.

## Afterwards

- Manage the deployed app at [dashboard.specific.dev](https://dashboard.specific.dev), including the database and automatic deploys from GitHub.
- Ask the agent to write a `CLAUDE.md` or `AGENTS.md` describing the new stack, so future sessions start with the right context.
- Custom domains are attached with `specific domain add` on a paid plan.