Migrate from Lovable

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

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:

• Database: the schema transfers as is; it is Postgres on both sides. Schema changes going forward use 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, and realtime to 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 for how that works.

Afterwards

• Manage the deployed app at 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.