Como migrar do Lovable Cloud para o seu próprio Supabase

Lovable Cloud ou seu próprio Supabase: qual usar?

O Lovable Cloud é o backend embutido do Lovable: banco de dados, autenticação, storage, edge functions e IA, construído sobre a base open source do Supabase e pago com seus créditos do Lovable. Conectar seu próprio projeto no Supabase significa que a conta, as chaves e a fatura são suas. Nenhum dos dois está errado. Eles servem a estágios diferentes.

Fique no Cloud enquanto ainda está descobrindo o que o produto é: é o jeito mais rápido de ter um backend. Migre quando precisar de algo que o Cloud não oferece, como acesso direto ao banco de dados para engenheiros, seus próprios backups e recuperação point-in-time, uma região específica por conformidade, um acordo de tratamento de dados no seu próprio nome ou simplesmente nenhum vendor lock-in no sistema de registro.

O que a exportação do Lovable Cloud inclui, e o que deixa para trás?

As configurações avançadas do Lovable permitem exportar, pausar ou remover o Cloud. Segundo a documentação do Lovable, a exportação contém seu banco de dados completo, estrutura e dados, e as contas dos seus usuários com os hashes de senha. Ela não contém os arquivos do storage, o código das Edge Functions nem os segredos do projeto, e as configurações dos provedores de login e as chaves de API precisam ser configuradas de novo no destino. Funciona para bancos que usam até 15 GB de armazenamento, o arquivo de exportação pode ter no máximo 5 GB, e você pode pedir uma exportação a cada 24 horas.

Mais dois controles importam durante a migração. Pausar o Cloud para o banco de dados, a autenticação, o storage e as edge functions, então tudo o que envia e-mail, recebe pagamentos ou chama IA para também, enquanto o storage continua sendo cobrado. Remover o Cloud apaga a instância permanentemente e não pode ser desfeito. Não remova nada até a nova configuração rodar em produção por um tempo.

Como migrar do Lovable Cloud para o Supabase, passo a passo?

1. 01

   Crie e proteja o novo projeto

   Crie um projeto no Supabase na sua própria organização, na região de que precisa, em um plano com backups. Ative a autenticação multifator para todos com acesso ao painel.

2. 02

   Exporte e importe o banco de dados

   Exporte pelas configurações avançadas do Lovable e restaure a exportação no novo projeto do Supabase. Daqui em diante, mantenha o schema como migrações versionadas, para que ele possa ser reconstruído a partir do código.

3. 03

   Mova o que a exportação deixa de fora

   Copie os buckets e arquivos do storage, publique de novo as Edge Functions a partir do seu código e crie novos segredos e chaves de API. Trate toda chave antiga como aposentada em vez de copiá-la.

4. 04

   Conecte o Lovable ao novo backend

   A documentação do Lovable descreve como conectar seu próprio projeto no Supabase a um projeto novo do Lovable. Faça isso e combine como seu time vai continuar escrevendo prompts lá antes da troca.

5. 05

   Reconecte a autenticação

   Configure de novo seus provedores de login (Google, e-mail) no novo projeto e teste com uma conta real. O Lovable observa que os usuários logados no momento da troca precisam entrar de novo.

6. 06

   Verifique de novo as regras de acesso

   Rode o Security Advisor do Supabase e o teste com dois usuários do nosso checklist de segurança. As políticas nem sempre sobrevivem intactas a uma migração.

7. 07

   Ensaie, depois faça a virada

   Ensaie a migração inteira em uma cópia, depois troque a produção em um horário tranquilo, com um plano de rollback escrito. Mantenha o Cloud pausado, não removido, até ter certeza.

Meus usuários vão ter que redefinir as senhas?

Não, se você restaurar a exportação do Lovable em um projeto do Supabase: a documentação do Lovable diz que a exportação inclui as contas dos usuários e os hashes de senha, então os usuários mantêm as senhas. Teste antes da virada entrando no novo projeto com uma conta existente. O que os usuários vão notar é ter de entrar de novo se estavam logados na hora da troca, e qualquer login social que você tenha esquecido de configurar de novo.

O que costuma quebrar em uma migração do Lovable Cloud?

• Arquivos. Imagens e uploads ficam para trás, a menos que você mova o storage, e as URLs deles mudam.
• Trabalho em segundo plano. E-mails, tratamento de pagamentos e chamadas de IA vivem em Edge Functions, que a exportação não inclui.
• Webhooks. A Stripe e outros provedores continuam apontando para os endpoints antigos até você mudá-los, e os segredos de assinatura mudam com as novas funções.
• Regras de acesso. Uma política que dependia de algo específico do Cloud pode falhar fechada (funcionalidades quebram) ou aberta (dados vazam).
• O próprio Lovable. A documentação do Lovable descreve conectar o novo projeto do Supabase a um projeto novo do Lovable, então planeje como seu time vai continuar escrevendo prompts depois da migração.

Você deve migrar sozinho ou deixar engenheiros fazerem isso?

Um app pequeno, sem pagamentos, com poucos arquivos e poucos usuários é um projeto razoável de fim de semana seguindo os passos acima. O risco cresce com pagamentos no ar, muitos usuários e arquivos, porque um erro aparece como uploads perdidos, cobranças em dobro ou dados visíveis para as pessoas erradas. Nesses apps, a migração é um trabalho de engenharia com ensaio e plano de rollback. Nos nossos planos, ela faz parte do trabalho, seguida da operação do novo backend, com monitoramento e suporte de emergência em produção.