Afraid to pull the trigger until you're sure you've done everything?

What Lovable was doing for you

And what each part costs once you do it yourself.

• Kept the codeGitHubfree
• Ran the database, auth, storage and functionsSupabase, in an organisation you ownfree, or $25/mo
• Built and hosted the siteVercelfree
• Deployed the moment the AI touched a table or a functionA GitHub Actions workflow, supabase.yml in the kitfree
• The chatClaude Code or Codex$20/mo

The Supabase free plan pauses a project after seven idle days, so an app with real users means the $25 plan. Row four is the one people forget: outside Lovable a database change is a file in supabase/migrations/, and nothing applies it until something runs it. The $20 is the plan you may already be paying for.

Two things changed in 2026

Check these before you trust any older guide.

New projects are TanStack Start, since 13 May

Anything created in Lovable after that date is server-rendered (pages built on a server), not the Vite single-page app most tutorials assume. Vercel deploys it with zero configuration, on two conditions: @lovable.dev/vite-tanstack-config at 2.6.2 or newer, and three server-side variables set in Vercel with no VITE_ prefix: SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, SUPABASE_SERVICE_ROLE_KEY. Lovable's own hosting injected those silently. Miss one on Vercel and the app fails at the door with the message Connect Supabase in Lovable Cloud, on a project that has Supabase connected. The kit's scripts/audit.sh detects the file that reads them and prints the list.

Lovable Cloud has an export, since July

Five gigabytes, once a day, no storage files, no usable passwords, so each of your users resets theirs after the move. Restoring it in the right order is about thirty steps. The kit does not rewrite that phase. It hands the restore to Carol Monroe's MIT-licensed skill, which has been run on real moves, and adds the checks before and after: row counts that must match, and a password reset and an image load that must both work from the new project.

What people hit

From the threads, with links.

The reply in the first thread that says "security security security" is mine, as u/SignatureSharp3215. This page is the long version of that reply.

The kit

$19, one payment. A private GitHub repo and a zip.

Markdown your agent reads and config it runs. Copy kit/ into the root of your project, open Claude Code or Codex there, and say:

Read AGENTS.md, then run the away-from-lovable skill. Start with the stack check.

The skill reads the guide chapter before each step, explains what a command does before running it, and never performs the destructive clicks itself. Removing Lovable Cloud and changing DNS stay yours.

What is in kit/

AGENTS.md

rules for Claude Code and Codex: migrations as files, RLS on every new table, no secret values in src/, a denial test before "done"

CLAUDE.md

points Claude Code at AGENTS.md

.github/workflows/supabase.yml

supabase db push and functions deploy on every push to main

.github/workflows/ci.yml

build and secret check on every pull request

.claude/skills/away-from-lovable/

the skill that runs the guide with you, for Claude Code

.agents/skills/away-from-lovable/

the same skill, for Codex

scripts/audit.sh

stack check, secret values in src/, functions callable without login, Lovable leftovers, pending migrations

sql/audit.sql

paste into the SQL Editor; every row printed is a decision

.env.example

every variable named, nothing filled in

The audit, as it reads

The first two of six queries in sql/audit.sql. The others find read policies open to everyone, tables with RLS on but no policies (your app sees empty pages), policies that never mention the caller, and SECURITY DEFINER functions the browser key can call.

-- 1. Tables in public with Row Level Security OFF: anyone with the browser key can read and write.
select 'RLS OFF' as finding, n.nspname as schema, c.relname as "table"
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r' and not c.relrowsecurity
order by 3;

-- 2. Write policies that allow everyone (qual or with_check is literally true).
select 'WRITE POLICY ALLOWS ALL' as finding, tablename as "table", policyname, cmd, roles
from pg_policies
where schemaname = 'public'
  and cmd in ('INSERT','UPDATE','DELETE','ALL')
  and (coalesce(qual,'') in ('true','(true)') or coalesce(with_check,'') in ('true','(true)'))
order by 2;

The guide, eight chapters in the order that cannot be skipped

1. What Lovable was doing for you. The five services, and the two things it never did.
2. Own the repo. Clone it, build it locally, decide whether Lovable keeps write access.
3. Backend. Two versions: you already run your own Supabase, or you are leaving Lovable Cloud.
4. Hosting on Vercel. Both stacks, and the exact environment variables each one needs.
5. Cutover. DNS TTL a day ahead, auth redirect URLs, your own SMTP, OAuth callbacks, both copies live.
6. What you are now responsible for. RLS on every table, keys out of the browser, open edge functions, rate limits, backups, billing alerts, one tested restore.
7. Claude Code or Codex. The branch, pull request, preview, merge loop, and the desktop apps if you would rather not open a terminal.
8. When it breaks. Twenty-two symptoms, each with its cause, its fix, and the chapter it belongs to.

About an hour if your backend is already your own Supabase. Half a day if it is on Lovable Cloud.

What it is not

Read before buying.

Not a course, and there is no video

People ask for one. If I record a walkthrough of the skill running, it goes into the repo and you have it.

Not a service

Nobody logs into your accounts. Your agent does the work with you watching.

Not software

Nothing of ours to install. You need Node, the Supabase CLI and Claude Code or Codex, which you need for the move anyway. Two shell scripts and a SQL file are the closest the kit gets to software.

Not the only way

Vercel deploys a Lovable app from a button. Carol Monroe's Cloud-to-Supabase skill is MIT and the kit uses it rather than replacing it. Supabase's own docs cover linking a project. What none of them contain is the deploy workflow, the audit, the cutover order, and the May and July changes above. If you would rather assemble it yourself, the checklist is the map.

Who wrote this