Quando o app feito no Lovable precisa sair do Lovable, e quando não precisa

O que quer dizer "sair do Lovable"#

Sair do Lovable pode querer dizer três coisas: tirar a hospedagem do app, tirar o banco de dados da nuvem embutida na ferramenta, a Lovable Cloud, ou parar de construir conversando com a IA. As duas primeiras se fazem sem a terceira. A própria documentação do Lovable descreve esse arranjo, com o desenvolvimento no Lovable e o app no ar em outro lugar.

A documentação do Lovable lista três arranjos. No primeiro, que é o que eles recomendam, tudo fica no Lovable. No segundo, o Lovable continua sendo onde se desenvolve e o app em produção roda numa plataforma como Vercel, Netlify ou a nuvem da AWS. No terceiro, toda a infraestrutura é da empresa. Nos dois últimos, o que liga o Lovable à produção é o GitHub: o código sincroniza nos dois sentidos com um repositório, e a hospedagem publica a partir dele. E o código é de quem construiu, segundo a mesma documentação.

Quando o app não precisa sair do Lovable#

O app não precisa sair do Lovable enquanto ainda está validando a ideia, enquanto a conta mensal é pequena e previsível e enquanto nenhum pagamento ou dado sensível depende de uma regra que rode no servidor. Nessa fase, a velocidade que a ferramenta entrega vale mais do que qualquer economia de infraestrutura, porque ainda é preciso poder mudar de ideia rápido.

Um produto com algumas dezenas de usuários, que ainda está descobrindo se alguém paga por ele, ganha pouco com uma hospedagem própria e passa a ter mais uma conta para cuidar. Quando alguém nos procura nessa fase achando que precisa migrar, a nossa recomendação costuma ser ficar.

Um dos motivos para querer sair, aparecer no Google, também perdeu força em 2026. Segundo a documentação do Lovable, desde 13 de maio de 2026 todo projeto novo nasce com renderização no servidor, num formato chamado TanStack Start, e a página chega pronta para qualquer visitante ou robô. Os projetos anteriores podem ser atualizados para esse formato pela própria ferramenta.

Mesmo quando a migração faz sentido, ela raramente pede reescrever o app. No Sistema Forja, um app feito no Lovable que auditamos quando ele já tinha 1.312 usuários ativos, o diagnóstico considerou a arquitetura adequada para aquela escala, e o que mudou foi onde o banco e a hospedagem moravam.

Os sinais de que o app precisa sair, e o caminho para cada um#

Os sinais de que o app precisa sair do Lovable são a conta da nuvem crescendo sem explicação, o produto virando um ativo que precisa estar no nome da empresa, a busca orgânica sendo o motor do negócio e o dinheiro passando pelo app. Cada sinal pede um caminho diferente, e só alguns deles pedem reconstruir uma parte do app.

Quando a reconstrução aparece na tabela, ela é sempre de uma parte. A interface e os fluxos que o dono construiu conversando com a IA quase sempre ficam, e o motivo está explicado em o que dá para salvar de um código gerado por IA.

Quando a conta da Lovable Cloud passa a pesar#

A conta da Lovable Cloud passa a pesar quando o app tem uso de verdade, porque banco, hospedagem e funções do servidor são cobrados com os mesmos créditos que pagam a construção por conversa. No Sistema Forja, a infraestrutura custava cerca de R$ 2.000 por mês na nuvem da ferramenta e passou a custar cerca de US$ 20 por mês em contas do próprio cliente.

Segundo a documentação do Lovable, o uso da Cloud sai do mesmo saldo de créditos da construção. Os planos recebem uma cota mensal de 20 créditos para a Cloud, o que passa dela sai do saldo geral, e os planos pagos têm recarga automática. O dono vê um número só e tem dificuldade de separar quanto foi para construir e quanto foi para manter o app no ar. Com um Supabase próprio, o consumo do banco passa a ser cobrado pelo Supabase, no plano de quem é dono da conta.

No Sistema Forja, uma plataforma de hábitos, metas e finanças pessoais construída pelos próprios fundadores no Lovable, havia uma cobrança diária que passou dias debitando sem ninguém perceber, e compra de crédito acima do consumo real. Com o banco num Supabase próprio e o site numa hospedagem dedicada, a conta caiu para cerca de US$ 20 por mês, com backup automático e sem tirar o produto do ar.

Essa troca tem um detalhe que pega quem não sabe. A documentação do Lovable diz que não existe migração em um clique da Lovable Cloud para um Supabase próprio: é preciso exportar os dados, criar um projeto novo ligado ao Supabase e refazer a estrutura do banco, e usuários e arquivos também vão à mão. No Forja, isso significou abrir um projeto novo no Lovable, já ligado ao banco do cliente, e foi nele que o cliente seguiu trabalhando.

Quando o app precisa aparecer no Google e nas respostas de IA#

O app precisa de renderização no servidor quando o negócio depende de ser achado em busca. Uma página que só se monta no navegador chega vazia para boa parte dos robôs. Segundo uma análise da Vercel com a MERJ, publicada em dezembro de 2024, os robôs de IA da OpenAI, da Anthropic, da Meta, da ByteDance e da Perplexity não executam JavaScript. Os do Google e da Apple executam.

Um app de página única, o formato dos projetos do Lovable até maio de 2026, entrega uma página quase vazia e um programa que monta o conteúdo no navegador. Um robô que lê só o que chega do servidor vê o site inteiro como uma página só. O Google executa o JavaScript depois de uma fila de renderização, e a documentação do Google recomenda renderizar no servidor, porque nem todo robô roda JavaScript.

Um job board que chegou para nós feito no Lovable parou exatamente aí. O dono construiu um site de vagas com área do candidato, painel da empresa e administração, e os últimos pedidos que ele fez à ferramenta, em junho, eram todos para o site aparecer no Google. A resposta da própria ferramenta foi que aquele projeto não fazia renderização no servidor, com a recomendação de levar o site para Next.js, fora do Lovable.

Hoje a documentação do Lovable conta outra história. Os projetos antigos recebem uma versão pré-renderizada das páginas, entregue só a robôs verificados: Google, Bing, as prévias de link e os buscadores de IA do ChatGPT, da Perplexity, do Claude e do Gemini. A documentação descreve essa ajuda para o app publicado pelo próprio Lovable e não diz o que acontece com ela quando a hospedagem vai para fora. O mais seguro é contar que ela fica para trás e atualizar o projeto para o formato novo antes de migrar.

No job board, a renderização era só a primeira parede. Um site de vagas depende de cada vaga e cada empresa serem uma página própria, com título próprio, que o robô consiga ler. No app dele, boa parte das páginas que o mapa do site anunciava devolvia o conteúdo da página inicial, e as páginas de cidade levavam a um endereço que não existia. Trocar a hospedagem não resolve isso. No escopo que estamos modelando, o site público é construído do zero com renderização no servidor, e o que ele fez no Lovable virou a referência de telas e de comportamento de um sistema sob medida.

Quando o dinheiro passa pelo app#

Quando o app cobra assinatura, libera plano ou movimenta crédito, a regra que decide isso precisa rodar no servidor e conferir cada aviso que chega do meio de pagamento. É a parte do app em que o código gerado por conversa mais costuma falhar, e a que mais vale reconstruir, mesmo que o resto do produto continue no Lovable.

No Sistema Forja, os endpoints de pagamento aceitavam requisição sem autenticação e sem verificação de assinatura, e quem descobrisse o endereço podia simular uma compra aprovada. A correção foi refazer essa camada, para que um aviso sem o segredo correto seja recusado antes de qualquer processamento. O app continuou no Lovable, e o resto do produto não foi reescrito.

No job board, a cobrança nem existia. A única decisão de negócio que o dono já tinha fechado, grátis para o candidato e pago pela empresa, era justamente o que o app não fazia: não havia meio de pagamento ligado, nenhuma empresa estava presa a um plano, e a tela de pagamentos do painel mostrava números de exemplo. A IA desenha a tela de cobrança num pedido só, mas o aviso do meio de pagamento, a tentativa que falha e o plano que cai quando o cartão não passa só existem quando alguém escreve a regra.

Antes de cobrar o primeiro cliente pelo app, vale fazer um diagnóstico do app feito com IA que comece por essa camada.

Como tirar a hospedagem do Lovable e continuar editando por ele#

Dá para tirar a hospedagem e o banco do Lovable e continuar construindo pela ferramenta. O código passa a morar num repositório do GitHub na conta da empresa, a hospedagem publica a partir dele, e o Lovable trabalha numa branch separada da que está no ar. Foi assim que o Sistema Forja foi devolvido ao cliente, que seguiu editando o app pelo Lovable.

No Forja, o produto foi entregue rodando nas contas do próprio cliente: o repositório no GitHub dele, a hospedagem na Vercel ligada a esse repositório, o banco no Supabase dele e o domínio apontado para o novo arranjo. Cada alteração feita pela conversa no Lovable vira um registro numa branch de trabalho, que não vai para o ar. Para publicar, alguém junta essa branch à principal, e a hospedagem atualiza o app sozinha. A documentação do Lovable confirma as peças: a sincronização com o GitHub vale nos dois sentidos e acompanha uma branch por vez, escolhida nas configurações do projeto.

Há dois cuidados. O primeiro é o banco. No arranjo que entregamos existe um banco só, sem ambiente de homologação, e uma mudança de estrutura feita pela conversa vale na hora, antes mesmo de a branch ir para o ar. Isso foi entregue por escrito ao cliente, como um risco que ficou na mão dele. O segundo é o formato do projeto: segundo a documentação, os projetos criados a partir de 13 de maio de 2026 rodam código no servidor e precisam de uma hospedagem que execute esse código, e não só de um lugar que sirva arquivos.

O que o dono passa a cuidar quando a hospedagem sai do Lovable#

Quando a hospedagem sai do Lovable, o dono ganha a conta no nome da empresa, o acesso direto ao banco e um custo que dá para ler. Em troca, passa a responder pelo que o Lovable cuidava sozinho: monitoramento, certificado do domínio, operação do banco, login e o que fazer quando o app cai num sábado à noite.

A documentação do Lovable é direta sobre isso: a ferramenta não monitora nem corrige uma infraestrutura que ela não controla, e a lista inclui a publicação, o certificado, os registros de erro, a operação do banco, o login e a verificação de segurança. Se ninguém na empresa sabe cuidar disso, alguém precisa ser contratado para cuidar, mesmo que por poucas horas no mês.

Sair da hospedagem compensa quando a infraestrutura própria vai custar menos do que a conta de hoje e existe alguém para cuidar dela. Enquanto não houver quem cuide, o melhor é ficar no Lovable e entender a conta de créditos antes de mudar qualquer coisa.

Perguntas frequentes#

Dá para continuar editando pelo Lovable depois de tirar a hospedagem?#

Dá. Com o projeto sincronizado com um repositório do GitHub, a hospedagem publica a partir dele e o Lovable continua sendo o lugar onde se constrói, num arranjo que a própria documentação do Lovable descreve. No Sistema Forja, o cliente seguiu editando pelo Lovable numa branch de trabalho e publicando ao juntar essa branch à principal.

Um app feito no Lovable aparece no Google?#

Aparece. Segundo a documentação do Lovable, os projetos criados desde 13 de maio de 2026 têm renderização no servidor, e os mais antigos recebem uma versão pré-renderizada entregue a robôs verificados, como Google, Bing e os buscadores de IA. Para ranquear, o site ainda precisa de uma página própria, com título próprio, para cada coisa que as pessoas buscam.

O que dá trabalho ao trocar a Lovable Cloud por um Supabase próprio?#

Segundo a documentação do Lovable, não existe migração em um clique. A estrutura do banco vai pelas migrações, mas dados, usuários, arquivos e provedores de login vão à mão, e é preciso criar um projeto novo no Lovable já ligado ao Supabase. No Sistema Forja, a troca foi feita sem tirar o produto do ar e sem perder nenhum registro.

O código feito no Lovable é meu?#

Segundo a documentação do Lovable, o app, o código e o conteúdo criados lá pertencem a quem criou, respeitadas as licenças de terceiros. O código sincroniza com o GitHub em todos os planos. Na prática, o que garante a posse é o repositório, a hospedagem e o banco estarem em contas no nome da empresa.

Preciso reescrever o app em outra tecnologia para ele crescer?#

Quase nunca o app inteiro. O que costuma ser refeito é uma parte: a camada que recebe o pagamento, a integração com outro sistema ou o site público, quando a busca é o produto. No Sistema Forja, o diagnóstico considerou a arquitetura adequada para a escala daquele momento, e o cliente seguiu evoluindo o app pelo Lovable.

Fontes#

• Lovable, opções de publicação, hospedagem e propriedade (os três arranjos, a posse do código e os destinos do banco): https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership
• Lovable, publicar e hospedar fora do Lovable (o que migra à mão, a hospedagem para projetos com servidor e o que passa a ser de quem hospeda): https://docs.lovable.dev/tips-tricks/external-deployment-hosting
• Lovable, Lovable Cloud (sem migração em um clique para o Supabase): https://docs.lovable.dev/features/cloud
• Lovable, conectar ao Supabase (quem cobra o consumo do banco): https://docs.lovable.dev/integrations/supabase
• Lovable, créditos e uso (a cota mensal da Cloud e a recarga automática): https://docs.lovable.dev/introduction/credits-and-usage
• Lovable, sincronizar o projeto com o GitHub (sincronização nos dois sentidos, uma branch por vez): https://docs.lovable.dev/integrations/github
• Lovable, SEO e busca por IA (renderização no servidor desde 13 de maio de 2026 e pré-renderização para robôs verificados): https://docs.lovable.dev/features/seo-aeo
• Lovable, atualizar um projeto para TanStack Start: https://docs.lovable.dev/features/upgrade-to-tanstack-start
• Vercel e MERJ, "The rise of the AI crawler", 17 de dezembro de 2024: https://vercel.com/blog/the-rise-of-the-ai-crawler
• Google Search Central, noções básicas de SEO para JavaScript: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

Próximo passo#

Se o seu app foi feito no Lovable e você está em dúvida entre ficar, tirar a hospedagem e o banco ou reconstruir uma parte, é a pergunta que respondemos no diagnóstico de vibe coding. Olhamos o código, o banco e a conta, e dizemos o que fica, o que muda de lugar e o que precisa ser refeito, como fizemos no Sistema Forja.