As alternativas ao Lovable se dividem em duas categorias. Elas respondem a perguntas diferentes. Quando você está iniciando um produto, está selecionando um fluxo de trabalho e decidindo quem operará o backend depois que a primeira versão funcionar. Quando você já executa um aplicativo Lovable em funcionamento, seu primeiro trabalho é um inventário: a própria documentação do Lovable afirma que o código da aplicação é seu e que movê-lo é uma mudança de implantação em vez de uma reescrita. O trabalho pesado fica em outro lugar. Os dados e os serviços exigem o trabalho real. Abaixo estão cinco partes, em ordem: uma tabela de novo projeto, os fatos atuais de portabilidade, uma verificação de framework, uma tabela de aplicativo existente e um checklist de aceitação em produção.
Dois leitores, duas decisões diferentes
Ao começar do zero, compare como cada ferramenta se encaixa no seu fluxo de trabalho e o que você terá que manter depois que a demonstração funcionar. A demonstração é a parte fácil. O builder importa menos do que quem opera o banco de dados, o pipeline de implantação e o sistema de login seis meses depois.
Para um aplicativo que já funciona, aguarde antes de reconstruí-lo em outra ferramenta. Comece com o inventário. Identifique do que ele depende: onde o código fica, onde o frontend é executado, qual backend armazena os dados e quais recursos de IA e conectores passam pelo Lovable em tempo de execução.
E aqui está a parte que as pessoas pulam. Permanecer no Lovable é uma opção perfeitamente válida. O guia de propriedade do Lovable identifica sua configuração gerenciada como a recomendação para a maioria dos aplicativos e diz para mover componentes apenas quando você atingir uma restrição real, como uma exigência de residência de dados, rede não suportada ou uma política que exige hospedagem auto-gerenciada. Se nenhuma delas se aplicar e ninguém da sua equipe quer assumir operações extras, mover é um custo sem retorno.
Novo projeto: a tabela de decisão
Esta tabela representa meu julgamento. A tirei da própria documentação de cada fornecedor quando disponível. Não é um ranking e não faz nenhuma afirmação sobre qual ferramenta produz aplicativos melhores.
| Opção | Fluxo de trabalho que se adequa | Modelo de código e repositório | Responsabilidade de backend e implantação | Tarefa de comprovação de adequação |
|---|---|---|---|---|
| Lovable | Compilações orientadas por chat onde uma plataforma gerencia edição, hospedagem e backend | Código gerenciado no Lovable; sincronização Git com GitHub, GitLab ou Bitbucket em todos os planos | Lovable pode executar hospedagem e o backend integrado; você assume operações apenas pelas partes que move | Construa o fluxo, sincronize com Git, depois clone e execute-o localmente |
| v0 | Trabalho de prompt-para-aplicativo que termina em revisão e implantação | Código real; a documentação do v0 descreve a implantação ou abre uma solicitação de pull para revisão | Deploy com um clique na infraestrutura powered by Vercel; backend conecta por meio de integrações | Implante o fluxo, depois altere-o por meio de um pull request |
| Bolt | Construção baseada em navegador onde você tem seu próprio histórico do Git | Bolt documenta uma integração Git; confirme a viagem de ida e volta em um repositório de teste | Bolt Cloud inclui hospedagem, banco de dados integrado, autenticação, armazenamento e funções de servidor | Construa o fluxo com dados persistentes e login, publique-o e verifique o fluxo de trabalho Git |
| Replit | Construção e hospedagem dentro de um único workspace na nuvem | O projeto fica no workspace Replit; verifique suas opções atuais de Git | Replit documenta publicação através de Deployments; confirme qual tipo executa código de servidor | Publique o fluxo, reimplante e verifique se os dados persistem |
| Repositório próprio com ferramentas lideradas por desenvolvedores | Equipes com engenheiros, revisão de código e um pipeline existente | Seu próprio repositório, qualquer editor ou agente de código | Você executa CI/CD, hospedagem, banco de dados e autenticação | Crie um starter, construa o fluxo, implante-o através do seu pipeline |
A última linha descreve um fluxo de trabalho, não um produto pronto para usar. Você monta as peças você mesmo. Escolha um stack, um host e um agente ou editor, depois assuma todo o trabalho operacional listado mais adiante. Se você está avaliando frameworks para essa rota, Astro vs Next.js e a página Next.js e Supabase cobrem os pontos de partida padrão.
A tarefa de prova tem a mesma forma para cada candidato. Mantenha-a pequena, mas a torne real. Construa um fluxo de usuário realista com dados persistentes, autenticação e uma implantação ao vivo. Uma captura de tela gerada não prova nada. Registrar uma conta, persistir um registro, fazer logout, fazer login novamente e visualizar esse registro novamente prova muito.
O que Lovable realmente permite que você leve consigo
Os fatos atuais de portabilidade vêm do guia de implantação e guia de propriedade da Lovable:
- Git sync está disponível em todos os planos (GitHub, GitLab, Bitbucket). Download de codebase, um snapshot .zip único, está disponível em planos pagos.
- Ambos os caminhos fornecem o código-fonte da aplicação, incluindo configuração e os arquivos de migração do banco de dados. Nenhum inclui os registros no seu banco de dados ou os arquivos no armazenamento.
- Linhas de banco de dados e arquivos de armazenamento precisam de exportações separadas, e você as verifica no destino antes de desativar a original.
- Você pode manter Lovable como a ferramenta de desenvolvimento enquanto outro host serve a produção. Conecte o repositório através do Git sync e deixe o outro host fazer a implantação a partir dele.
A integração GitHub traz restrições que vale a pena notar. Algumas são operacionalmente incômodas. Lovable edita e sincroniza apenas uma branch por vez. Git sync sempre provisiona um novo repositório e não pode anexar um projeto a um existente, e reconectar após uma desconexão cria outro novo repositório. O repositório é padrão para privado. Deletá-lo interrompe a sincronização.
O código não fica bloqueado, então. Isso é útil, mas não é toda a migração. Armazenar o código-fonte no seu repositório não elimina as dependências de tempo de execução do Lovable. Tenha essa distinção em mente para a tabela do app existente.
Verifique o framework antes de escolher um host
A documentação do Lovable afirma que novos apps criados após 13 de maio de 2026 usam TanStack Start, que executa código do servidor. Apps antigos são diferentes. Eles dependem de React mais Vite e compilam para arquivos estáticos. A documentação de integração do Supabase menciona 22 de junho de 2026 para planos Enterprise em uma capacidade relacionada, pagamentos integrados com seu próprio projeto Supabase, então evite aplicar uma regra de data de criação genérica a toda conta.
Inspecione seu projeto real. Abra o package.json na aba Code. Um projeto TanStack Start lista @tanstack/react-start sob suas dependências. Um projeto antigo com React e Vite não lista.
As consequências de hospedagem diferem:
- TanStack Start: o host deve executar a parte do servidor: renderização no servidor, funções do servidor e rotas de API. Um host que recebe apenas arquivos estáticos não executa esses recursos. Armazenamento de objetos ou um CDN isolado não é o suficiente. Lovable aponta para uma plataforma que o Nitro detecta, um contêiner ou seu próprio servidor. Também verifique se o
package.jsonlistanitro, porque sem ele a compilação não empacota o app para um host fora do Lovable. - React e Vite antigos: implante a saída estática em
dist/em um host estático, CDN ou servidor web como Nginx, com fallback paraindex.htmlpara que as rotas do lado do cliente funcionem.
Outra armadilha: variáveis com prefixo VITE_ são inseridas no tempo de compilação, não lidas em tempo de execução. Isso pega equipes. Ao usar o backend integrado, Lovable instrui você a definir VITE_SUPABASE_URL e VITE_SUPABASE_PUBLISHABLE_KEY antes de executar npm run build.
Omiti aqui receitas de implantação por provedor. Isso é controle deliberado de escopo. O guia do Lovable detalha as etapas atuais, e para um projeto renderizado no servidor prescreve verificações como carregar uma página renderizada no servidor e executar uma função do servidor antes de mudar o tráfego.
App existente: quatro caminhos, comparados
| Caminho | O que fica | O que se move | Ainda cobrado ou operado pelo Lovable | Trabalho para verificar | Proprietário operacional |
|---|---|---|---|---|---|
| Manter a configuração gerenciada completa | Tudo | Nada | Hospedagem, backend integrado, recursos de IA e conectores; o uso de Cloud é retirado dos créditos do workspace | Que atende às suas necessidades de conformidade e lançamento | Lovable executa a infraestrutura; você é proprietário do produto |
| Mover apenas hospedagem de frontend | Backend integrado, recursos de IA, conectores; Lovable pode ser a ferramenta de edição | Compilação e implantação de frontend | Backend, AI e conectores continuam rodando através do Lovable | Variáveis de ambiente do host, segredos do servidor, URLs de redirecionamento de login, valores VITE_ em tempo de build, recursos do servidor no TanStack Start | Você para o pipeline do frontend e logs; Lovable para o backend |
| Mover o backend integrado para um projeto Supabase de sua propriedade | Código em sincronização com Git; frontend pode permanecer ou ser movido | Banco de dados, autenticação, armazenamento e funções para Supabase gerenciado ou auto-hospedado | Recursos de IA e conectores ainda podem rodar através do Lovable | Restauração de dados, autenticação, armazenamento, políticas de acesso, Edge Functions, segredos | Você, no painel do Supabase e sob sua cobrança do Supabase |
| Sair completamente do Lovable | Código-fonte | Frontend, backend, dados, mais substituições para chamadas de IA e conectores | Nada, uma vez que as substituições estejam em lugar e aceitas | A lista de verificação completa abaixo | Você, para tudo |
Duas coisas nessa tabela são fáceis de errar.
Primeiro, migrar um backend não é um interruptor de alternância. Lovable declara que não pode transferir um projeto do backend integrado para Supabase em uma única etapa, nem reverter o processo. A rota documentada é mais manual. Requer recriar o esquema e mover dados manualmente: exportar do backend ativo, conectar o novo e instruir Lovable a reconstruir o esquema.
Segundo, os destinos suportados são Supabase gerenciado e Supabase auto-hospedado. Mover apenas o banco de dados PostgreSQL deixa muito para trás: autenticação, armazenamento, recursos em tempo real e Edge Functions. Mudar para PostgreSQL simples ou outro provedor requer construir esses equivalentes você mesmo, um caminho que Lovable não suporta. Esse é trabalho de engenharia genuíno, não uma migração direta. Se você seguir esse caminho, a visão geral de bancos de dados serverless é um lugar sensato para comparar destinos.
Sair do backend integrado também remove ferramentas nativas. Você perde as visualizações em editor de Database, Users, Storage, Secrets, Jobs e Logs, backups diários com restauração por clique, e autenticação configurada por Lovable como login Google gerenciado. Executar seu próprio projeto Supabase requer sua própria assinatura Supabase e gerenciamento direto da infraestrutura.
E nada nas fontes diz que outro construtor importa um backend Lovable completo. Assuma que não vai.
Lista de verificação de aceitação em produção
Comece com um inventário. Para o projeto real, liste:
- Dados e esquema (os arquivos de migração ficam em
supabase/migrations/) - Usuários de autenticação e provedores
- Arquivos de armazenamento e políticas de acesso
- Inscrições em tempo real
- Edge Functions ou funções de servidor
- Segredos
- Tarefas agendadas e webhooks
- Acesso a IA e conectores de aplicativos
Depois trabalhe através disso na ordem:
- Clone o repositório e execute o código real localmente. Isso mostra o que ele instala, de que depende e lê do ambiente.
- Identifique o framework e o runtime (veja a verificação de
package.jsonacima). - Restaure a exportação de dados em um projeto de staging, não em produção.
- Baixe os arquivos de armazenamento em Mais → Storage e carregue-os no storage de staging.
- Teste cadastro, login e redirecionamentos OAuth, e verifique a continuidade da conta. A documentação de exportação de banco de dados do Lovable diz que restaurar em um projeto Supabase mantém as senhas dos usuários, e quem estava conectado no momento da mudança precisa fazer login novamente. Não assuma; valide e siga a orientação atual de migração de usuários do Supabase. Veja também a página de autenticação.
- Teste acesso a arquivos e permissões com contas reais de diferentes perfis.
- Verifique Row Level Security. Cada tabela precisa de políticas que restrinjam quem pode ler e escrever cada linha, e o Lovable diz para verificar elas próprio no painel do Supabase.
- Execute um fluxo crítico pago ou que mude estado em modo de teste, nunca cobrando clientes reais.
- Compare contagens de registros e abra arquivos representativos do storage.
- Verifique logs, backups, recuperação e um caminho de reversão.
- Substitua tudo o que funcionava através do Lovable: acesso a IA, conectores, tarefas agendadas.
- Só então remova os serviços originais.
O passo 12 merece um aviso. Leve a sério. Descartar o banco de dados do Lovable deleta sua exportação junto com seus arquivos, então baixe e inspecione-os antes. Nunca cole credenciais em tickets, chats ou no repositório ao lidar com isso.
Outra armadilha: se dois projetos Lovable compartilham um único projeto Supabase, eles sobrescrevem os segredos um do outro, incluindo LOVABLE_API_KEY, quebrando qualquer recurso que dependa disso.
Fique, vá híbrido ou saia
A maioria das decisões reais fica entre esses extremos.
- Uma exigência para um pipeline de deploy diferente pode precisar apenas de uma mudança no frontend.
- Uma necessidade de um banco de dados em sua própria conta pode precisar da migração do backend, e nada mais.
- Insatisfação com a experiência de autoria pode significar apenas trabalhar no repositório exportado com seu próprio editor, enquanto Lovable continua conectado via Git sync.
Designe um proprietário de manutenção e mapeie todas as dependências de runtime restantes antes de cancelar qualquer serviço. Mantenha o documento conciso. Precisa dizer quem faz deploy, quem restaura um backup, quem rotaciona secrets, e quais recursos ainda chamam Lovable. Se não conseguir nomear um proprietário, fique onde está por enquanto.
Se quiser uma segunda opinião sobre esse handover, envie o repositório, um mapa de deployment e o fluxo de usuário que requer supervisão de engenharia para o time de engenharia agentic para uma avaliação dos limites de propriedade e trabalho restante. Seja preciso sobre o pedido. É uma avaliação, não um resgate garantido com um clique.
FAQ
Consigo auto-hospedar o editor Lovable e o agent?
Não. Lovable afirma que o editor e o agente de IA funcionam como um serviço gerenciado e não podem ser auto-hospedados ou implantados dentro de um VPC de cliente. Os aplicativos que você constrói com eles, porém, podem ser hospedados em qualquer lugar.
Mudar para outro builder mantém meu backend?
Nada nas fontes indica que faz. Planeje por trabalho separado. Exporte seus dados e arquivos, transfira o codebase via Git ou um download, e configure autenticação, secrets e serviços de suporte novamente no destino.
O download .zip é suficiente se estou em um plano gratuito?
O download .zip do codebase direto do Lovable está disponível em planos pagos. Git sync é diferente. Como Git sync está disponível em todos os níveis, teste essa rota primeiro.
O aviso principal é claro: o código exportado pertence a você, mas os registros do banco de dados, arquivos de armazenamento, configuração de auth, e IA e conectores gerenciados pelo Lovable exigem migrações separadas, nenhuma das quais acontece automaticamente. Faça o inventário antes de fazer a transição. Verifique seu package.json, inventarie todas as dependências, e teste a migração em staging antes de cancelar qualquer coisa.