Como sair do Lovable: código, banco e domínio, passo a passo

Sair do Lovable não é apertar um botão. São três mudanças: o código, o banco e o endereço. Este guia segue a documentação oficial do Lovable (Deploying and hosting outside Lovable) e explica cada passo em português.

Antes de começar: o que sai e o que fica

O Lovable diz que você é dono do código e dos dados que cria, e que ambos podem ser exportados (Deployment, hosting and ownership). Mas nem tudo vai junto:

• Sai: o código (front e funções), o banco com os dados, as contas dos usuários com as senhas e os arquivos enviados.
• Fica: o editor e o agente de IA do Lovable, que não rodam fora da plataforma.
• Precisa de substituto: conectores de apps e recursos de IA que rodam pelo Lovable. Eles não são exportados.

Outro ponto da doc: cada parte que você tira passa a ser sua para manter, proteger e atualizar. Se o motivo da saída é custo, some o tempo de manutenção na conta.

Decida também se vai tirar só o site (o front) ou também o backend. É possível migrar só o front e manter o banco no Lovable Cloud por um tempo.

Passo 1: pegue o código

Há dois caminhos (GitHub e Deploying outside Lovable):

• Git sync, em todos os planos. Em Project settings → Git, conecte o GitHub. O Lovable cria um repositório novo, privado por padrão, e passa a sincronizar nos dois sentidos. Ele não liga a um repositório que já existe e sincroniza só um branch por vez, em geral o main.
• Download codebase, nos planos pagos. Baixa um .zip com o código daquele momento.

Prefira o Git sync. Ele mantém o histórico e deixa o servidor novo fazer deploy a cada push.

Nenhum dos dois leva os dados do banco nem os arquivos enviados pelos usuários. Isso fica para o passo 6.

Passo 2: descubra qual é a sua stack

Abra o package.json do repositório.

• Tem @tanstack/react-start? É TanStack Start, o modelo dos projetos criados a partir de 13/05/2026. Ele precisa de um servidor rodando, não só de arquivos estáticos.
• Não tem? É o modelo antigo, React + Vite. O build gera arquivos estáticos na pasta dist/, e qualquer hospedagem de site estático serve.

Essa diferença muda tudo daqui para frente. Muitos guias na internet foram escritos antes do TanStack Start e só cobrem o caso estático.

Passo 3: faça o build

Comandos da doc do Lovable:

React + Vite

npm ci
npm run build
# saída em dist/

TanStack Start, para servidor próprio ou container

npm ci
NITRO_PRESET=node-server npm run build
node .output/server/index.mjs
# escuta na porta 3000; PORT e HOST mudam isso

Se o repositório só tem bun.lock, use o Bun ou gere e versione um package-lock.json antes de rodar npm ci. Use Node 22.

Passo 4: configure as variáveis de ambiente

Os valores estão no arquivo .env do projeto. Variáveis que começam com VITE_ entram no código na hora do build: se mudar uma, precisa buildar de novo.

• No navegador: VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY e VITE_SUPABASE_PROJECT_ID.
• No servidor (TanStack Start): SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, SUPABASE_PROJECT_ID e os segredos das funções. Os segredos não estão no repositório. Você vai recriá-los.

Passo 5: coloque no servidor

Site estático (React + Vite) numa VPS: copie o dist/ para o servidor e configure o Nginx para mandar toda rota ao index.html:

location / {
  try_files $uri $uri/ /index.html;
}

Depois, ponha HTTPS, por exemplo com o Certbot.

TanStack Start: rode o servidor Node do passo 3 atrás de um proxy reverso que cuida do HTTPS. Aqui o try_files não se aplica: quem cuida das rotas é o servidor.

Docker: o Lovable sugere um build em duas etapas, com node:22-alpine para buildar e nginx:alpine para servir o dist/.

Se quiser um painel em vez de configurar tudo à mão, o Coolify instala numa VPS Linux, faz o deploy a partir do GitHub e cuida do HTTPS.

Passo 6: migre o banco do Lovable Cloud

Se o app usa o Lovable Cloud, o destino suportado é um projeto Supabase, gerenciado ou instalado por você (Deployment, hosting and ownership). A ordem sugerida pela doc:

1. Crie um projeto novo no Supabase e anote a URL, o ID e a chave publicável.
2. Aplique as migrações em ordem: supabase/migrations/ (pela data no nome) ou drizzle/migrations/ (pelo _journal.json).
3. Exporte os dados: More → Database → Manage → Settings → Export data. O arquivo é um .backup do PostgreSQL, não um SQL. Restaure com pg_restore num projeto de teste primeiro. Não use --clean sem ler o que ele faz: ele apaga objetos.
4. Configure de novo os provedores de login e as URLs de retorno.
5. Copie os arquivos de More → Storage para buckets com os mesmos nomes.
6. Recrie os segredos e publique as Edge Functions com npx supabase functions deploy.
7. Recrie as tarefas agendadas. Não deixe a mesma tarefa rodando nos dois bancos.
8. Aponte uma cópia de teste do app para o banco novo e confira.
9. Na virada, atualize o .env e o project_id do supabase/config.toml.

O que a exportação leva e o que não leva (Database backups):

• Leva: estrutura e dados do banco, contas de usuário e hashes de senha. Os usuários mantêm a senha. Quem estiver logado na hora da troca precisa entrar de novo.
• Não leva: arquivos do storage, código das Edge Functions, segredos, configuração dos provedores de login e chaves de API.
• Limites: banco de até 15 GB, arquivo de até 5 GB e uma exportação a cada 24 horas. Banco maior exige falar com o suporte.

O .backup tem hash de senha e dados pessoais. Guarde em lugar seguro e apague as cópias soltas depois.

Passo 7: teste antes de virar o tráfego

A doc lista quatro testes:

• Abra uma rota interna direto pelo endereço e recarregue. Erro 404 indica falta do fallback para index.html ou falta do servidor.
• Entre e saia do app. Erro de redirecionamento costuma ser a URL nova faltando na lista de retornos do login.
• Leia, grave e envie um arquivo.
• No TanStack Start, abra uma página renderizada no servidor e chame uma função de servidor.

Passo 8: vire o domínio

Aponte o domínio para o servidor novo, seguindo o passo a passo de DNS e certificado do seu provedor. O endereço lovable.app continua servindo a última versão publicada, e o botão Publish continua publicando só no Lovable.

Passo 9: troque o que para de funcionar

Fora do Lovable, deixam de funcionar (Deploying outside Lovable):

• conectores de apps e recursos de IA que rodam pelo Lovable;
• conectores de chat (servidores MCP), que só existem no chat do projeto;
• OAuth gerenciado e renovação automática de token, que dependem do backend do Lovable.

Procure no código as chamadas a esses recursos e troque por integrações suas. O Lovable também não monitora nem depura um servidor que é seu.

Passo 10: encerre a mudança

1. Planeje a cópia final dos dados. Pause as gravações de usuários, tarefas, webhooks e integrações. Faça a última exportação, copie os arquivos alterados, restaure e só então vire.
2. Meça o tempo de exportar e restaurar no teste, para saber quanto tempo o app fica parado.
3. Despublique o app no Lovable quando não quiser mais o lovable.app no ar.
4. Antes de remover o banco do Lovable Cloud, baixe e confira as exportações e os arquivos. A remoção apaga banco, backups, contas e arquivos e não tem volta (Lovable Cloud).
5. Lembre que exportar o código não cancela nada. A assinatura e o uso do Lovable Cloud continuam até você mudar o plano.

Quanto tempo leva

Depende do tamanho do banco, do número de integrações e de quantos recursos do Lovable o app usa. Um site estático sem banco é o caso mais simples: passos 1 a 5, 7 e 8. Um app com login, arquivos, funções e pagamentos pede um teste completo antes da virada. Comece pelo passo 2: a stack diz quase tudo sobre o tamanho do trabalho.

Peça o diagnóstico da Heartscale

Já migramos clientes do Lovable, do Wix e da Tray. Na Heartscale, o diagnóstico mapeia o que o seu app usa do Lovable, o tamanho do banco, as integrações que precisam de substituto e os riscos de segurança que vão junto na mudança. Você recebe um relatório com o plano de migração e o preço fechado.

O diagnóstico custa R$ 398 e é abatido se você fechar a migração. Só trabalhamos em app de quem prova ser dono.

Pedir o diagnóstico do meu app