Como migrar do Lovable Cloud para o seu próprio Supabase
Para migrar do Lovable Cloud para um Supabase seu, crie o projeto de destino, aplique as migrações do repositório e restaure com pg_restore o .backup exportado pelo Lovable. Depois copie os arquivos, recrie segredos, Edge Functions e tarefas agendadas e troque as variáveis do app. Os usuários mantêm a senha. As sessões abertas caem.
Recomendação da Heartscale: faça pelo menos um restore completo num projeto Supabase de teste e meça o tempo antes de marcar a virada. Se o app já tem usuários reais, login social ou pagamento, peça uma revisão do plano antes de pausar as gravações.
Este guia cobre só o banco e o backend. Para o código, o build, o servidor e o domínio, veja como sair do Lovable.
Lovable Cloud e Supabase: o que muda
O Lovable Cloud é o backend embutido do Lovable e é feito sobre o Supabase (Lovable Cloud). Ele junta banco, login, storage, Edge Functions, segredos, tarefas e logs, e cobra tudo do mesmo saldo de créditos.
Num projeto Supabase seu, cada peça passa a ser sua: a conta, a cobrança, o painel e a manutenção. Três regras da documentação do Lovable:
- Os destinos suportados são o Supabase gerenciado e o Supabase instalado por você. PostgreSQL puro ou outro provedor exigem recriar login, storage e funções à mão.
- Mover só o PostgreSQL não move login, storage, realtime nem Edge Functions.
- O caminho de volta não existe: migrar de um Supabase para o Lovable Cloud não é suportado hoje (Lovable Cloud).
Se escolher instalar o Supabase no seu servidor, o caminho recomendado é o Docker. A própria documentação do Supabase diz que backups, segurança e manutenção do Postgres ficam com você, e que o suporte é da comunidade.
O que a exportação leva e o que não leva
Pela página de Database backups:
| Leva | Não leva |
|---|---|
| Estrutura e dados do banco | Arquivos do storage |
| Contas de usuário | Código das Edge Functions (está no repositório) |
| Hashes de senha | Segredos |
| Configuração dos provedores de login | |
| Chaves de API do projeto |
Limites: banco de até 15 GB, arquivo de até 5 GB e uma exportação a cada 24 horas. O banco precisa estar ativo. Se o projeto pausou por falta de créditos, retome antes de exportar.
O limite de 24 horas define o cronograma. Você vai precisar de pelo menos duas exportações: uma para o teste e outra para a virada.
Passo 1: crie o projeto de destino
No Supabase, clique em New project. Escolha uma senha forte para o banco e uma região perto dos usuários. Anote o Project ID, a URL (https://<id>.supabase.co) e a chave publicável.
Antes de restaurar, ligue no projeto novo as extensões que o banco antigo usava e os Database Webhooks, se houver. O guia de backup e restauração do Supabase pede isso antes de carregar os dados.
Passo 2: aplique o esquema pelas migrações
O esquema vem das migrações guardadas no repositório. Pela documentação do Lovable:
- Pasta
supabase/migrations/: rode os arquivos SQL em ordem pelo prefixo de data, do mais antigo ao mais novo. - Pasta
drizzle/migrations/: siga a ordem demeta/_journal.json. A CLI do Supabase não aplica esse formato.
Com a CLI, no caso do Supabase:
npx supabase login
npx supabase link --project-ref <id-do-projeto-novo>
npx supabase db push
Para conferir diferenças entre o repositório e o banco, rode npx supabase db diff --linked, com o Docker aberto.
As migrações também criam os buckets e as políticas de acesso. Confira se as políticas de RLS vieram completas: veja como configurar RLS no Supabase.
Passo 3: exporte e restaure os dados
No Lovable, vá em More → Database → Manage → Settings → Export project data → Export data. No cartão Database, clique em Export e em Start export. O Lovable avisa por e-mail. Baixe o arquivo em More → Storage e guarde uma cópia fora do Lovable.
O arquivo é um .backup no formato custom do PostgreSQL, com compressão zstd. Se vier dentro de um .zip, extraia antes. O pg_dump ganhou compressão zstd na versão 16 (notas da versão 16), então use um pg_restore 16 ou mais novo, compilado com zstd.
Como o esquema já foi aplicado no passo 2, restaure só os dados. O roteiro, com as opções descritas na documentação do pg_restore:
# 1. lista o conteúdo do arquivo
pg_restore --list export.backup > export.list
# 2. edite export.list: comente com ";" o que não quer restaurar
# 3. restaura só os dados, na ordem da lista, tudo ou nada
PGOPTIONS="-c session_replication_role=replica" \
pg_restore --data-only --no-owner --single-transaction \
--use-list=export.list \
--dbname "<string de conexão do Session pooler>" \
export.backup
O que cada parte faz:
--data-onlyrestaura dados de tabelas e valores das sequências, sem recriar o esquema.--single-transactionaplica tudo ou nada. Se algo falhar, o banco fica como estava.session_replication_role = replicaimpede que gatilhos rodem durante a carga. O Supabase usa essa mesma configuração no guia de restauração. Sem ela, um gatilho que cria um perfil para cada usuário novo criaria perfis em dobro ou faria a carga falhar. Ela também desliga as checagens de chave estrangeira, então confira a contagem de linhas depois (PostgreSQL).- A string de conexão do Session pooler funciona em redes só com IPv4. A conexão direta exige IPv6 ou o complemento de IPv4.
Na lista, mantenha os dados de public, auth.users e auth.identities. Deixe de fora as sessões e tokens de auth, que não servem no projeto novo. Deixe de fora também as tabelas do schema storage: os registros dos arquivos são criados quando você envia os arquivos no passo 5.
Faça isso primeiro num projeto de teste. O Lovable alerta para dois pontos: registros que as migrações já inseriram podem colidir com os do arquivo, e os valores das sequências precisam vir junto. Não use --clean sem ler o que ele faz: ele apaga os objetos antes de restaurar.
Na nossa revisão, depois do restore de teste, comparamos a contagem de linhas de cada tabela de public e de auth.users nos dois bancos. Só então entramos com uma conta migrada e liberamos a virada.
Passo 4: login, com senhas e sem sessões
Os hashes de senha vêm no arquivo, então os usuários entram com a mesma senha. O guia de migração de usuários do Supabase explica por que as sessões caem: cada projeto assina os tokens com o próprio segredo, e o token antigo deixa de valer. Avise os usuários de que precisarão entrar de novo.
No projeto novo:
- Em Authentication → Sign In / Providers, ligue cada provedor que o app usava.
- No console de cada provedor (Google, GitHub e outros), troque a URL de retorno pela do projeto Supabase novo.
- Na página URL Configuration, preencha o Site URL com o endereço de produção e liste em Redirect URLs os endereços para onde o login pode voltar (Redirect URLs). O Site URL é usado nos e-mails de confirmação e de troca de senha.
Se alguma conta não voltar, ofereça um fluxo de redefinição de senha.
Passo 5: arquivos do storage
No Lovable, abra More → Storage e baixe os arquivos de cada bucket. No Supabase, abra Storage e envie para buckets com os mesmos nomes, mantendo as pastas. Se o banco guarda o caminho dos arquivos, ele depende desses nomes. Se guarda a URL completa, ela aponta para o endereço do projeto antigo e precisa ser atualizada.
Antes de apagar qualquer coisa, compare a quantidade de arquivos em cada bucket nos dois lados.
Passo 6: segredos e Edge Functions
Os segredos não estão no export nem no repositório. Recrie cada um na página Edge Function Secrets do Supabase ou pela CLI (Secrets):
supabase secrets set --env-file .env.producao
supabase secrets list
Nomes que começam com SUPABASE_ são reservados. SUPABASE_URL e as chaves do projeto já chegam às funções sem configuração.
O código das funções está em supabase/functions/. Publique com:
npx supabase functions deploy
Passo 7: tarefas agendadas
Liste as tarefas na área de jobs do Lovable e compare com o que existe no banco novo após o restore. Recrie as que faltam com cron.schedule em SQL. Tarefas que chamam o app por fora precisam de um agendador externo.
Confira o endereço e a credencial de cada tarefa. Ligue as tarefas do lado novo só na virada, para a mesma tarefa não rodar nos dois bancos.
Passo 8: teste e virada com escrita pausada
Deixe o projeto no Lovable como está. Numa cópia separada do app, configure VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY e VITE_SUPABASE_PROJECT_ID e faça o build de novo: essas variáveis entram no código na hora do build. No TanStack Start, configure também SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY e SUPABASE_PROJECT_ID.
Teste se o app abre, se grava e lê registros, se uma conta migrada entra, se envio e download de arquivos funcionam e se as funções respondem. Meça quanto tempo levaram a exportação e o restore.
Na virada, pela documentação do Lovable:
- Troque no código o que ainda passa pelo Lovable: conectores, recursos de IA e o endereço do backend embutido.
- Pause as gravações de usuários, tarefas, webhooks e integrações.
- Peça a exportação final e restaure no projeto novo.
- Copie os arquivos que mudaram desde a última cópia.
- No
.env, troque as variáveis do Supabase. Nosupabase/config.toml, troque oproject_id. - Ligue as tarefas agendadas do lado novo e reabra o app.
O tempo medido no teste é o tempo que o app fica sem gravar.
Antes de remover o Lovable Cloud
Remover o banco em More → Database → Manage → Settings → Remove database apaga o banco, os backups, as contas e os arquivos. Isso inclui as exportações guardadas no storage do projeto, e não tem volta (Lovable Cloud). Baixe e confira tudo antes.
O .backup contém hashes de senha e dados pessoais. Guarde em lugar seguro e apague as cópias soltas. A assinatura e o uso do Lovable Cloud continuam até você mudar o plano.
Fazer sozinho ou contratar?
Este guia basta para muitos projetos. O que muda a decisão é o custo de uma virada que dê errado.
| Situação | Caminho |
|---|---|
| App em teste, sem usuários reais, e alguém do time usa terminal e SQL | Faça sozinho com este guia, num projeto de teste primeiro |
| Usuários reais com login por Google ou outro provedor | Vale chamar uma equipe: sessões, URLs de retorno e redefinição de senha precisam fechar na mesma janela |
| Pagamento, webhooks ou tarefas agendadas gravando no banco | Vale chamar uma equipe, como a nossa: a pausa de escrita precisa cobrir todas as entradas |
| Dados pessoais no banco, prazo curto ou ninguém técnico no time | Peça o diagnóstico da Heartscale antes de exportar: você recebe o plano e o tempo estimado de pausa antes de mexer no banco |
Peça o diagnóstico da Heartscale
Nossa equipe mede o banco e o storage, lista as tarefas, os segredos e as funções do seu projeto e faz o restore num Supabase de teste antes da virada. Você recebe o plano da migração de plataforma, com o tempo estimado de pausa e o preço fechado.
O diagnóstico de lançamento custa R$ 99 (de R$ 398) e é abatido se você fechar a migração. Só trabalhamos em app de quem prova ser dono.