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

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

O Lovable Cloud é o backend integrado do Lovable: base de dados, autenticação, armazenamento, edge functions e IA, construído sobre a base de código aberto do Supabase e pago com os seus créditos do Lovable. Ligar o seu próprio projeto Supabase significa que é o titular da conta, das chaves e da fatura. Nenhum dos dois está errado. Servem fases diferentes.

Fique no Cloud enquanto ainda está a descobrir o que o produto é: é a forma mais rápida de ter um backend. Mude quando precisar de algo que o Cloud não lhe dá, como acesso direto à base de dados para engenheiros, as suas próprias cópias de segurança e recuperação para um ponto no tempo, uma região específica por razões de conformidade, um acordo de tratamento de dados em seu nome, ou simplesmente nenhuma dependência de fornecedor no sistema de registo.

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

As definições avançadas do Lovable permitem exportar, pausar ou remover o Cloud. Segundo a documentação do Lovable, a exportação contém a base de dados completa, estrutura e dados, e as contas dos seus utilizadores com os hashes das palavras-passe. Não contém os ficheiros do armazenamento, o código das Edge Functions nem os segredos do projeto, e as definições dos fornecedores de início de sessão e as chaves de API têm de ser configuradas de novo no destino. Funciona para bases de dados que usem até 15 GB de armazenamento, o ficheiro exportado pode ter no máximo 5 GB e pode pedir uma exportação a cada 24 horas.

Há mais dois controlos que importam durante uma mudança. Pausar o Cloud para a base de dados, a autenticação, o armazenamento e as edge functions, por isso tudo o que envia e-mails, recebe pagamentos ou chama IA também para, enquanto o armazenamento continua a ser faturado. Remover o Cloud elimina permanentemente a instância e não pode ser anulado. Não remova nada até a nova configuração estar a funcionar em produção há algum tempo.

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

1. 01

   Crie e proteja o novo projeto

   Crie um projeto Supabase na sua própria organização, na região de que precisa, num plano com cópias de segurança. Ative a autenticação multifator para todas as pessoas com acesso ao painel.

2. 02

   Exporte e importe a base de dados

   Exporte a partir das definições avançadas do Lovable e restaure a exportação no novo projeto Supabase. A partir daqui, mantenha o esquema como migrações versionadas, para que possa ser reconstruído a partir do código.

3. 03

   Mova o que a exportação deixa de fora

   Copie os buckets e os ficheiros do armazenamento, volte a implementar as Edge Functions a partir do seu código e crie novos segredos e chaves de API. Trate todas as chaves antigas como retiradas em vez de as copiar.

4. 04

   Ligue o Lovable ao novo backend

   A documentação do Lovable descreve como ligar o seu próprio projeto Supabase a um novo projeto Lovable. Faça-o, e combine antes da mudança como é que a sua equipa continua a escrever pedidos lá.

5. 05

   Volte a ligar a autenticação

   Configure de novo os seus fornecedores de início de sessão (Google, e-mail) no novo projeto e teste com uma conta real. O Lovable nota que os utilizadores com sessão iniciada no momento da mudança têm de voltar a iniciar sessão.

6. 06

   Volte a verificar as regras de acesso

   Corra o Security Advisor do Supabase e o teste com dois utilizadores da nossa lista de segurança. As políticas nem sempre sobrevivem intactas a uma mudança.

7. 07

   Ensaie e depois mude

   Ensaie a mudança completa numa cópia e depois mude a produção numa hora calma, com um plano de reversão escrito. Mantenha o Cloud pausado, não removido, até ter a certeza.

Os meus utilizadores vão ter de redefinir as palavras-passe?

Não, se restaurar a exportação do Lovable num projeto Supabase: a documentação do Lovable diz que a exportação inclui as contas dos utilizadores e os hashes das palavras-passe, por isso os utilizadores mantêm as palavras-passe. Teste antes da mudança, iniciando sessão no novo projeto com uma conta existente. O que os utilizadores vão notar é terem de voltar a iniciar sessão, se tinham sessão iniciada no momento da mudança, e qualquer início de sessão social que se tenha esquecido de configurar de novo.

O que costuma avariar numa migração do Lovable Cloud?

• Ficheiros. Imagens e carregamentos ficam para trás a menos que mova o armazenamento, e os URLs 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 fornecedores continuam a apontar para os endpoints antigos até os alterar, e os segredos de assinatura mudam com as novas funções.
• Regras de acesso. Uma política que referia algo específico do Cloud pode falhar fechada (funcionalidades avariadas) ou aberta (fugas de dados).
• O próprio Lovable. A documentação do Lovable descreve ligar o novo projeto Supabase a um novo projeto Lovable, por isso planeie como a sua equipa continua a escrever pedidos depois da mudança.

Deve migrar sozinho ou pôr engenheiros a fazê-lo?

Uma app pequena sem pagamentos, com poucos ficheiros e meia dúzia de utilizadores é um projeto razoável para um fim de semana com os passos acima. O risco aumenta com pagamentos reais, muitos utilizadores e ficheiros, porque um erro aparece como carregamentos perdidos, cobranças a dobrar ou dados visíveis para as pessoas erradas. Nessas apps, a mudança é um trabalho de engenharia com ensaio e plano de reversão. Nos nossos planos faz parte do trabalho, seguida da operação do novo backend, com monitorização e apoio de emergência em produção.