Posso tirar meu app do Lovable e hospedar em outro lugar?

Pode. O Lovable diz que você é dono do código e dos dados e que ambos podem ser exportados. O código sai pelo Git sync, em todos os planos, ou pelo Download codebase, nos planos pagos, e o banco do Lovable Cloud vai para um projeto Supabase seu.

Os usuários perdem a senha quando o app sai do Lovable Cloud?

Não. A exportação do banco leva as contas de usuário e os hashes de senha, então os usuários mantêm a senha. Quem estiver logado na hora da troca precisa entrar de novo.

O que para de funcionar depois de sair do Lovable?

Param os conectores de apps e os recursos de IA que rodam pelo Lovable, os conectores de chat (servidores MCP) e o OAuth gerenciado com renovação automática de token. Você precisa trocar essas chamadas por integrações suas.

Meu app do Lovable precisa de servidor ou basta uma hospedagem estática?

Depende da stack. Se o package.json tem @tanstack/react-start, é TanStack Start e precisa de um servidor Node rodando. Se não tem, é React + Vite, e o build gera arquivos estáticos em dist/ que qualquer hospedagem estática serve.

Exportar o código cancela a assinatura do Lovable?

Não. A assinatura e o uso do Lovable Cloud continuam até você mudar o plano. Antes de remover o banco do Lovable Cloud, baixe e confira as exportações e os arquivos, porque a remoção não tem volta.

Vale a pena contratar alguém para tirar o app do Lovable?

Vale quando o app tem usuários reais, login, pagamento ou dados pessoais, ou quando ninguém do time sabe fazer build, DNS e restore de banco. A Heartscale faz um diagnóstico de lançamento por R$ 99 (de R$ 398), abatido se você contratar a migração em até 15 dias.

lovablePublicado em 26/10/2026 · Equipe Heartscale

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.

Recomendação da Heartscale: monte primeiro uma cópia de teste, com o banco restaurado num Supabase separado, e só vire o domínio depois dos quatro testes do passo 7. Se o app tem usuários reais, login ou pagamento, peça uma revisão do plano antes de pausar as gravações.

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:

Crie um projeto novo no Supabase e anote a URL, o ID e a chave publicável.
Aplique as migrações em ordem: supabase/migrations/ (pela data no nome) ou drizzle/migrations/ (pelo _journal.json).
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.
Configure de novo os provedores de login e as URLs de retorno.
Copie os arquivos de More → Storage para buckets com os mesmos nomes.
Recrie os segredos e publique as Edge Functions com npx supabase functions deploy.
Recrie as tarefas agendadas. Não deixe a mesma tarefa rodando nos dois bancos.
Aponte uma cópia de teste do app para o banco novo e confira.
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.

Na nossa revisão, antes de qualquer build, buscamos no código cada chamada a conector, recurso de IA ou OAuth gerenciado do Lovable e anotamos o substituto de cada uma. É essa lista que define o tamanho da migração.

Passo 10: encerre a mudança

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.
Meça o tempo de exportar e restaurar no teste, para saber quanto tempo o app fica parado.
Despublique o app no Lovable quando não quiser mais o lovable.app no ar.
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).
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.

Fazer sozinho ou contratar?

Este guia basta para muitos casos, e o que pesa na decisão é quanto custa o app parar ou perder dados na virada.

Situação	Caminho
Site estático (React + Vite), sem usuários reais, e alguém do time usa terminal e DNS	Faça sozinho com este guia: passos 1 a 5, 7 e 8
App em TanStack Start, com funções de servidor ou recursos do Lovable para substituir	Vale chamar uma equipe: o servidor e as integrações novas precisam estar prontos antes da virada
Usuários reais com login, pagamento ou dados pessoais no banco	Vale chamar uma equipe, como a nossa: a cópia final dos dados e a virada precisam caber numa pausa curta
Prazo curto ou ninguém técnico no time	Peça o diagnóstico da Heartscale antes de exportar: você recebe o plano de migração e o preço fechado

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 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.

Pedir o diagnóstico do meu app