You built an app on Lovable and now want to keep working on it with your own coding agent, host it where you control it, and stop depending on Lovable Cloud. The migration itself is done by your agent. This post is for deciding whether to do it and knowing what to expect: what you keep, what gets rebuilt, what happens to your users, and what stays manual.

The short version, if you have already decided: open the project in Claude Code, Cursor, or Codex and paste this.

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

Whether to migrate

Reasons people do:

They want to work with their own coding agent instead of Lovable's, on a codebase they run locally.
The app needs something Lovable Cloud does not run: a long-running service, a worker, a scheduled job that outlives an edge function.
They want the backend in a repository they own, not a hosted account they can be locked out of.

Reasons to stay: the app is small, Lovable's editor is working for you, and you have no backend needs beyond what Lovable Cloud offers. Lovable's GitHub sync already gives you a copy of the code, so ownership of the code alone is not a reason to move.

What you keep and what gets rebuilt

Lovable Cloud is built on Supabase's open-source foundation, so the backend migration is a Supabase migration. The parts, and where each one ends up:

Part	What happens
Frontend and server code	Kept. It is already in your GitHub repository.
Database schema, storage bucket definitions, RLS policies	Move as the SQL migrations in your repository, then become Reshape migrations.
Database rows, uploaded files, users	Exported from Lovable Cloud (the Cloud tab, Advanced settings, "Export project data"; one export per 24 hours, up to 5 GB), then imported. This step is manual.
Auto-generated API and RLS	Become routes and authorization checks in a backend you own. On TanStack Start projects the server functions already are that backend and only their internals change. Vite SPA projects get a small Hono server added.
Edge functions	Become routes in the same backend.
Authentication	Keep Supabase Auth on a Supabase project of your own, or replace it with Better Auth or a provider such as Auth0, Clerk, or WorkOS.
File storage	An S3-compatible bucket.
Realtime	Postgres sync, powered by ElectricSQL, or polling where that is enough.
Lovable AI gateway	The model provider's API directly, or another gateway such as Vercel AI Gateway or OpenRouter, with your own key.
Lovable-specific packages and secrets	Removed. Nothing in the project needs a Lovable-injected secret afterwards.

The step-by-step mapping, including the differences between the two Lovable project generations (TanStack Start and the older Vite SPA), is in the Lovable migration guide in our docs.

What happens to your users

User accounts are part of the data export, password hashes included. If you keep Supabase Auth, restored into a Supabase project of your own, every user and password keeps working. If you switch to another auth system, whether it can verify those hashes depends on the system, so plan a password reset flow as the fallback. Signed-in users have to sign in again either way, and OAuth providers need their redirect URLs updated to the new domain.

What it takes

The agent installs the CLI, pulls your repository, and follows a runbook we maintain for exactly this. It rewrites the code, asks you for the secrets it finds along the way, and runs the app locally with a public tunnel URL so you can click through it and confirm everything still works. Then it deploys, without you creating an account first: specific login --agent registers the agent itself, and specific claim hands the project to your email afterwards. Unclaimed accounts are deleted after 48 hours, so do the handoff before you close the session.

How long it takes depends mostly on the backend. A TanStack Start project keeps its server functions, so the work is inside them. A Vite SPA project has no backend yet, so the routes Supabase generated have to be written.

What the result looks like

One file, specific.hcl. This is the minimal version for a TanStack Start app: the web service and its database. A project that used file storage, realtime, or background jobs adds a storage, sync, or temporal block to the same file.

build "web" {
  base    = "node"
  command = "npm run build"
}

service "web" {
  build   = build.web
  command = "node dist/server/index.mjs"

  endpoint {
    public = true
  }

  env = {
    PORT         = port
    DATABASE_URL = postgres.main.url
  }

  dev {
    command = "npm run dev -- --port $PORT"
  }
}

postgres "main" {
  reshape {
    enabled = true
  }
}

specific dev runs this on your computer, with a real Postgres database and a local dashboard where you can browse your tables the way you did in Lovable. specific deploy runs the same file in production.

Common questions

Do I have to be a developer to do this?

No, but you do need to be comfortable letting an agent run commands on your computer. The runbook tells the agent to run everything itself and to explain as it goes.

Can I keep using Lovable for the frontend?

Yes. Lovable's GitHub sync is two-way, so you can keep editing in Lovable and deploy from the repository elsewhere. Most people who migrate switch fully to their own agent, since the backend now lives outside Lovable Cloud.

What about my custom domain?

Add it from the Specific dashboard once the app is deployed. Custom domains require a paid plan.

Try it

Paste the prompt above into your agent, or install the CLI yourself:

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

If you'd rather not do this alone, or get stuck at any point, email us at [email protected] and we'll help you through the migration. For how Specific works with coding agents in general, see the coding agents guide.