O que aconteceu ao Lovable

O que é e porque importa

Em abril de 2026 o The Register contou o alerta de um investigador sobre o Lovable, e o Lovable explicou depois o incidente no seu blog: entre fevereiro e abril, por causa de um problema no seu backend, os chats e o código dos projetos públicos podiam ser vistos por outros utilizadores. O Lovable diz que os projetos privados não foram afetados e que o problema está corrigido. Se tens um projeto lá, lê o post deles.

Não tenho nada contra o Lovable. Esta história só me lembrou o quanto importa saber onde vive o teu projeto e quem guarda as chaves dele. Se vive dentro de uma plataforma, a segurança da plataforma é a tua. Se vive numa pasta tua, com as tuas chaves, os erros são teus, e pelo menos podes corrigi-los.

A questão é que um projeto não é só o código: há os dados, as contas dos utilizadores, os ficheiros carregados, as chaves, o domínio. Cada peça sai por uma porta diferente, e se te esqueces de uma, dás por isso quando um utilizador já não consegue entrar.

Aqui em baixo está como tirar tudo. Uso os menus do Lovable, mas a lógica vale para qualquer plataforma. E serve mesmo que fiques: ter uma cópia tua é bom senso.

Uma regra antes de tudo: não apagues nada enquanto o novo não funcionar.

1. O código

No Lovable: Project settings → Git → GitHub. Ligas a tua conta e mandas criar o repositório: o Lovable cria-o privado e mantém-no sincronizado nos dois sentidos, o que mudas no Lovable vai para o GitHub e vice-versa.

A sincronização segue um só branch, normalmente main. Enquanto estiver ativa, faz os testes num branch à parte e não mexes no projeto dentro do Lovable.

Se o teu plano o tiver, no mesmo menu há também «Download codebase»: o zip de todo o código. Bom como cópia de segurança, mas não se atualiza.

Depois clonas o repositório para o teu computador, a partir do botão «Code» da página do repo no GitHub. A partir daqui é uma pasta tua.

2. A base de dados

O código leva a estrutura da base de dados, não os dados. A estrutura está nas migrations: ficheiros SQL, normalmente na pasta supabase/migrations, que recriam tabelas, colunas e regras de acesso. Os dados, ou seja, as linhas a sério, exportas à parte.

Para o esquema e os dados, com o backend integrado do Lovable (Lovable Cloud) usas a exportação da base de dados nas definições avançadas: More → Cloud → Overview → Advanced settings → Export data. O link chega por email. É um arquivo de backup do Postgres, não um ficheiro SQL para colar: restaura-se com pg_restore. Se, pelo contrário, tens a string de ligação da base de dados, usas pg_dump. No Supabase encontras a string no botão «Connect» do painel do projeto, e o guia deles usa o comando supabase db dump.

Importas para um Postgres ou Supabase teu, novo e vazio.

3. Os utilizadores

As contas de login não viajam com as tabelas: se só mudares os dados, os utilizadores ficam para trás.

A exportação completa do Lovable Cloud, pelo contrário, inclui-os, com as palavras-passe guardadas de forma cifrada. Se a restaurares num projeto Supabase, os utilizadores mantêm a palavra-passe. Duas coisas, porém, não passam: as sessões, por isso todos vão ter de voltar a fazer login, e as definições dos métodos de acesso, tipo «Iniciar sessão com o Google», que voltas a configurar no novo.

Se vens por outro caminho e as palavras-passe não se podem levar, prepara um email de «redefine a tua palavra-passe» para enviar no dia da mudança.

4. Os ficheiros carregados

Fotos, documentos, avatares: não estão na base de dados nem no código. No Lovable Cloud encontra-los em More → Cloud → Storage. Descarrega-os e volta a carregá-los no novo armazenamento, em buckets (as «pastas» do armazenamento) com os mesmos nomes.

Depois conta os ficheiros antes e depois.

5. As chaves

As variáveis secretas não saem nem com o código nem com a exportação da base de dados. E no Lovable os segredos não se podem voltar a ler, só substituir: o valor vais buscá-lo ao serviço que to deu.

Faz a lista de todas: base de dados, API, pagamentos, email. Põe-nas no teu .env no computador e nas definições do novo alojamento. As chaves privadas nunca vão para o código nem para o git, e nunca numa variável que comece por VITE_: essas acabam no browser, por isso aí só valores públicos.

Depois gera-as de novo: chaves novas, as antigas revogadas. Uma chave que continua válida numa plataforma que já não usas é uma porta deixada aberta.

6. Domínio e login

Aponta o domínio para o novo alojamento, seguindo as instruções de quem te aloja. O endereço lovable.app fica com o Lovable e continua a mostrar a última versão que publicaste lá.

Depois atualiza os URL de redirecionamento do login: o endereço novo tem de ser acrescentado aos autorizados pelo teu sistema de login. Se usas «Iniciar sessão com o Google» ou parecidos, atualiza-o também aí. Se te esqueceres, o login parte-se precisamente no domínio novo.

Com o Claude Code, dentro da pasta

Abre o terminal na pasta do projeto e arranca o Claude Code (cd para a pasta, depois claude). Lê os ficheiros sozinho. Eu dou-lhe estes pedidos, por esta ordem.

Lê este projeto e faz-me a lista de tudo o que depende da plataforma de onde vem: variáveis, serviços, URL, funções no servidor.

Este é o teu mapa. As funções no servidor são as que correm fora do browser: nos projetos Lovable com Supabase costumam estar em supabase/functions e têm de ser publicadas à parte no novo backend.

A próxima acrescento eu: dá-te a lista das chaves do ponto 5 sem teres de as procurar à mão.

Faz-me a lista de todas as variáveis de ambiente que o projeto usa: onde são lidas, quais acabam no browser e quais têm de continuar secretas. Não escrevas os valores.

Põe-no a correr localmente com a minha base de dados nova e diz-me o que falta.

É aqui que aparecem as chaves esquecidas e as tabelas vazias. O Claude Code pede-te autorização antes de alterar ficheiros ou correr comandos, conforme o modo de permissões que escolheste: lê o que ele vai fazer antes de dizeres que sim.

Verifica que nenhuma chave está escrita no código nem no histórico do git.

Se encontrar uma no histórico, apagar o ficheiro não chega: fica nos commits antigos. Essa chave geras de novo, e pronto.

7. Publica, testa e só depois desliga o antigo

Quando tudo funcionar localmente, publica num alojamento que controles tu. Depois testa as coisas que se partem primeiro:

1. O login: entra com uma conta que já existia e cria uma nova.
2. Um carregamento de ficheiro, e que volte a abrir.
3. Os pagamentos, se os tiveres, em modo de teste.

Só então desliga o antigo.

Os erros mais comuns

• Apagar o projeto antigo assim que tens o repositório. Mantém-no ligado até que login, ficheiros e pagamentos funcionem no novo.
• Pensar que o repositório é o projeto todo. O código leva a estrutura; dados, utilizadores, ficheiros e segredos saem cada um por si.
• Importar os dados para uma base de dados já usada. Parte de um Postgres novo e vazio.
• Copiar as chaves antigas para o novo e ficar por aí. Gera-as de novo e revoga as antigas.
• Esquecer os URL de redirecionamento. Acrescenta o domínio novo aos autorizados pelo login antes de o mudar.

Checklist

• Repositório no GitHub, privado, clonado no computador
• Estrutura e dados na nova base de dados, vazia antes da importação
• Login testado com uma conta antiga e uma nova
• Ficheiros descarregados, carregados de novo e contados
• Chaves na lista, geradas de novo, antigas revogadas
• Domínio e URL de redirecionamento atualizados
• O antigo desligado em último lugar

Perguntas frequentes