Erros comuns ao publicar um app feito no Lovable (e como evitar)

Erros comuns ao publicar app no Lovable: domínio, segredos, RLS e dados expostos, login e e-mails, SEO e custos de créditos. Veja como evitar.

Os erros mais comuns ao publicar um app feito no Lovable são: esquecer de republicar depois de editar, configurar o domínio com registros DNS sobrando, deixar chaves secretas no front-end, publicar com RLS fraco no banco, login que quebra no domínio próprio, e-mails de confirmação que não chegam, SEO ignorado e créditos que acabam e derrubam o backend. Quase todos têm solução simples, desde que você saiba que existem antes de divulgar o link.

Este guia segue a ordem em que os problemas costumam aparecer, com base na documentação oficial do Lovable em novembro de 2026.

1. Achar que publicar é automático

No Lovable, o site publicado é uma cópia congelada do momento em que você clicou em Publicar. As edições seguintes ficam só no editor até você abrir o diálogo de publicação e publicar as mudanças.

Sintoma clássico: "corrigi o bug, mas o cliente continua vendo o erro". Não é cache; você só não republicou.

Dica: combine com a equipe quem pode publicar e quando. Republicar no meio de uma alteração pela metade leva o bug junto.

Visibilidade

Por padrão, qualquer pessoa com o link acessa o app publicado. A documentação mostra que dá para restringir a pessoas convidadas (e, nos planos Business e Enterprise, a membros do workspace). Útil para ferramentas internas que não deveriam estar abertas na internet.

2. Domínio próprio mal configurado

Publicar no endereço lovable.app é gratuito. Domínio próprio exige plano pago. Na configuração com um registrador externo (Registro.br, por exemplo), a documentação pede:

• Um registro A apontando para o IP informado pelo Lovable.
• Um registro TXT de verificação (com host _lovable).
• Remover registros A, AAAA ou CNAME antigos do mesmo host. É a causa mais comum de "o site antigo ainda aparece".

Outros pontos que travam:

• Cloudflare com proxy ligado (nuvem laranja) durante a verificação gera erros e deixa o domínio preso em "Verificando". Deixe os registros do Lovable como "DNS only" ou use a opção específica para proxy.
• Registros CAA que não autorizam as autoridades certificadoras usadas pelo Lovable impedem o certificado SSL. O domínio fica "Stalled" ou "Failed".
• Propagação de DNS costuma levar algumas horas, mas pode chegar a 72 horas. Não fique trocando registros a cada 10 minutos.
• www e domínio raiz: ao conectar o raiz, o Lovable conecta o www como domínio separado e redireciona. Só um domínio é o principal.

Atenção: registre o domínio no nome da empresa, com um e-mail da empresa. Domínio no CPF do freelancer que montou o projeto vira refém quando a parceria acaba.

3. Chaves secretas no front-end

Esse é um dos erros mais graves e mais comuns. O Lovable separa duas coisas:

• Variáveis VITE_ ficam no arquivo .env e são embutidas no código que vai para o navegador. Qualquer visitante consegue ler. Servem para valores públicos, como a URL do backend e a chave publishable do Supabase.
• Secrets ficam criptografados no backend e só são lidos pelas Edge Functions. É o lugar de chaves da OpenAI, Stripe, Resend, tokens de WhatsApp e afins.

O erro acontece quando você pede "integra com a API X" e a chave acaba numa variável VITE_ ou direto no código da tela. Funciona e vaza.

Como evitar:

• Chave secreta só em Secrets, usada por Edge Function.
• Se uma chave já apareceu no front-end ou no GitHub, troque a chave no provedor. Apagar o arquivo não apaga o histórico.
• Configure limite de gasto no provedor da API.

4. RLS fraco e dados expostos

Apps do Lovable com backend (Lovable Cloud ou Supabase próprio) deixam o navegador falar direto com o banco. Quem decide o que cada usuário pode ler ou alterar são as regras de Row Level Security (RLS). Tabela sem RLS, ou com regra que libera geral, é tabela aberta.

O Lovable roda uma verificação rápida quando você abre o diálogo de publicação. Segundo a documentação, ela checa regras de acesso do banco (tabelas sem controle por registro, regras que deixam todo mundo passar), proteção contra senhas vazadas, regras de storage e vulnerabilidades críticas em dependências. Existe também uma verificação profunda, que inclui segredos no código, mas ela não roda sozinha antes de publicar.

E o ponto mais importante: a documentação diz que as verificações não garantem segurança completa e recomenda revisão profissional para apps com dados sensíveis. Um alerta verde significa "nada óbvio foi encontrado", não "suas regras fazem sentido para o seu negócio".

Teste na prática: crie dois usuários e veja se um consegue ler ou alterar dados do outro. O passo a passo está em Supabase RLS explicado e no checklist de segurança para apps do Lovable.

5. Login e e-mails que quebram em produção

Login funciona no preview e falha no domínio

A documentação lista esse caso entre os erros comuns: o domínio novo não está nas URLs de redirecionamento da autenticação. Adicione o endereço publicado e o domínio próprio. Faça isso antes de anunciar, e teste cadastro, login, logout e recuperação de senha no domínio final.

E-mails de confirmação que não chegam

Sem configuração de envio próprio, existe um limite de e-mails de autenticação por hora. Num lançamento com muitos cadastros ao mesmo tempo, as confirmações param de chegar. A documentação recomenda configurar o envio com domínio próprio verificado, o que também melhora a entrega e deixa o remetente com a cara da sua marca.

Outros ajustes que valem antes de publicar:

• Decidir se a confirmação de e-mail é obrigatória (para a maioria dos apps, deveria ser).
• Ativar a verificação de senhas vazadas, que recusa senhas conhecidas em vazamentos.
• Exigir senha com mais do que o mínimo de 6 caracteres.
• Personalizar os textos dos e-mails em português.

6. Ignorar o SEO

Segundo a documentação, apps criados no Lovable a partir de 13 de maio de 2026 usam renderização no servidor (TanStack Start), então buscadores e visitantes recebem a página pronta. Projetos mais antigos entregam versões pré-renderizadas apenas a buscadores verificados, robôs de prévia de links e crawlers de IA, e podem ser atualizados para TanStack Start.

Mesmo com renderização no servidor, continuam sendo responsabilidade sua:

• Título e descrição únicos por página.
• Sitemap e cadastro no Google Search Console.
• Conteúdo real em texto, não só imagens.
• Domínio próprio (o lovable.app dificilmente constrói marca).

Dica: ferramentas de SEO de terceiros podem mostrar suas páginas como vazias em projetos antigos, porque não são robôs verificados. Confira no próprio Google Search Console. Mais detalhes em por que o Google não encontra seu site feito com IA.

7. Não entender os custos de créditos e de backend

No Lovable, os créditos pagam duas coisas diferentes:

• Construir: cada pedido à IA no editor.
• Rodar: hospedagem e backend do Lovable Cloud (banco, storage, Edge Functions, realtime), chamadas de IA que o seu app faz e conectores medidos.

Ou seja, o app publicado também consome créditos, e isso cresce com o uso. A documentação permite criar limites de gasto por workspace, projeto ou membro, e alertas de saldo baixo. Mas atenção ao efeito: se um limite pausar o Cloud, o backend para também no app publicado. A página carrega, mas login, banco e arquivos deixam de funcionar para os seus usuários.

Recomendações:

• Ative alertas de saldo baixo antes de qualquer bloqueio.
• Use limites que bloqueiem a construção, não o app em produção, a menos que você prefira o app parado à conta alta.
• Acompanhe o painel de uso do projeto nas primeiras semanas após o lançamento.
• Coloque limite de uso nas funções que chamam APIs pagas, para um robô não gastar seu saldo.

Lock-in do backend

A documentação informa que sair do Lovable Cloud para um Supabase próprio é um processo manual: exportar e restaurar o banco, mover arquivos, reconfigurar autenticação e segredos. A região dos dados também fica fixa depois de ativar o backend. Não é motivo para não usar, mas é algo para decidir conscientemente.

Tabela-resumo

Antes de clicar em Publicar

• Projeto sincronizado com o GitHub da empresa
• Nenhuma chave secreta em variáveis VITE_ ou no código da tela
• RLS revisado e testado com usuários diferentes
• Verificação rápida sem alertas críticos e verificação profunda executada
• Domínio configurado, SSL ativo, registros antigos removidos
• Domínio incluído nas URLs de redirecionamento do login
• Envio de e-mails configurado e testado
• Títulos, descrições e sitemap revisados
• Alertas e limites de gasto configurados
• Política de privacidade publicada

Se o projeto nasceu numa conversa com IA e cresceu mais rápido que o planejado, vale ler também o que é vibe coding e quando vira problema.

Quer uma revisão antes de lançar?

A Mobgeek faz o resgate de projetos feitos com IA, incluindo apps do Lovable: auditoria de RLS e segredos, ajustes de autenticação e e-mail, domínio, custos e SEO. A auditoria começa em R$ 1.990. Se quiser, descreva o seu app no orçamento.