Como colocar um projeto do Lovable em produção

O que o Lovable entrega e onde ele para

Colocar um projeto do Lovable em produção é possível, mas não é apertar “publicar” dentro da própria plataforma. Na prática, significa exportar o código para o GitHub, revisar RLS e segurança no Supabase, configurar domínio próprio com hospedagem fora do Lovable (em serviços como Vercel ou Netlify) e resolver o gap de SEO que toda aplicação de página única (SPA) carrega por padrão. É esse conjunto de passos, não o botão de deploy da plataforma, que separa um protótipo validado de um produto pronto para tráfego real.

Você descreveu o produto em português, viu as telas nascerem em minutos, testou o fluxo principal, e a sensação de “pronto, agora é só publicar” é real. O Lovable merece o crédito por isso: interface funcional, CRUD básico resolvido, banco de dados no Supabase já plugado, deploy de um clique num subdomínio da própria plataforma. Para tirar uma ideia do papel e colocar algo clicável na frente de usuários em poucos dias, é uma das ferramentas mais eficientes que existem hoje, e vale reconhecer isso sem ironia.

O ponto onde ele para é outro. Manter esse projeto em produção de verdade, com tráfego real, dados sensíveis e a expectativa de que tudo continue de pé daqui a seis meses, exige decisões que a geração automática não toma sozinha. Isso não é falha da ferramenta: nenhuma plataforma de geração rápida foi desenhada para revisar segurança de banco de dados ou otimizar SEO por você, ela otimiza para a tela funcionar agora. Este guia percorre esse caminho passo a passo, do primeiro export até o domínio no ar, mantendo tudo que já foi construído.

Exportando e assumindo o código (GitHub sync)

O primeiro passo prático é sair do modo “só existe dentro do Lovable”. A plataforma oferece sincronização bidirecional com o GitHub: você conecta um repositório e cada mudança feita pelo chat, ou diretamente no código, aparece como commit real. A partir do momento em que esse sync está ativo, o projeto deixa de ser propriedade só da ferramenta e passa a ser um repositório Git normal, que você pode clonar, versionar e abrir em qualquer editor.

Isso muda o jogo de forma silenciosa mas importante. Com o código no GitHub, dá para rodar linters, adicionar testes, configurar integração contínua e até trazer outras ferramentas de IA, como Cursor ou Claude Code, para trabalhar em cima do mesmo projeto. Vale reservar um tempo, antes de qualquer outra etapa, só para ler o histórico de commits e entender a estrutura geral: como os componentes estão organizados, onde ficam as chamadas ao Supabase, o que parece ter sido gerado rápido sem muito contexto. Esse mapeamento evita que você revise o projeto às cegas nos passos seguintes.

Domínio próprio e hospedagem fora do Lovable (Vercel, Netlify)

Um projeto vivendo num subdomínio da plataforma passa a impressão errada para quem chega: parece protótipo, não produto. Com o código já no GitHub, sair do Lovable como hospedagem é direto: projetos Lovable normalmente nascem como aplicações React com Vite, e tanto Vercel quanto Netlify importam esse tipo de repositório com poucos cliques, detectando o comando de build automaticamente.

O que exige atenção nessa migração é separar variáveis de ambiente de desenvolvimento das de produção, algo que dentro do Lovable costuma ficar tudo misturado num único ambiente. Configure o domínio próprio com certificado SSL (automático em ambas as plataformas), e aproveite o que se ganha ao sair de um ambiente fechado: deploys de preview por branch, rollback de um clique para uma versão anterior e logs de build mais detalhados quando algo falha. Esse tipo de disciplina de deploy é parte do que separa um projeto “no ar” de um projeto pronto para escalar, tema que aprofundamos no artigo sobre levar um protótipo de IA até a produção.

Supabase: o que revisar (RLS, policies, migrações)

Quase todo projeto do Lovable usa Supabase como banco de dados, e é aqui que mora o risco mais comum e mais grave antes de lançar. Por padrão, muitas tabelas geradas durante a construção rápida ficam com Row Level Security (RLS) desativado, ou ativado sem policies específicas, o que na prática significa que qualquer pessoa com a chave pública do projeto (visível no código do navegador, isso é esperado) consegue ler ou até alterar dados de outros usuários direto pela API do Supabase, sem precisar passar pela sua interface.

Antes de qualquer usuário real acessar o projeto, vale passar por esse checklist:

• Ativar RLS em todas as tabelas que guardam dado de usuário, sem exceção.
• Escrever policies explícitas para select, insert, update e delete, cada uma checando se auth.uid() corresponde ao dono do registro.
• Testar cada tabela sensível logado como um usuário comum, tentando acessar dado que não é seu, e confirmar que a chamada falha.
• Migrar de “editar tabela direto pela interface do Supabase Studio” para migrações versionadas, usando a CLI do Supabase ou arquivos SQL versionados no repositório, para que qualquer alteração futura no schema fique rastreável e reversível.

Esse último ponto costuma ser ignorado justamente porque a interface visual do Supabase é tão fácil de usar que parece dispensar disciplina. Ela não dispensa: um schema sem histórico de migração é uma bomba relógio silenciosa para o dia em que for preciso alterar uma coluna com dados de produção já dentro dela.

Auth e segurança pós-export

Depois de assumir o código, revise com atenção o fluxo de autenticação que o Lovable gerou. Confirme que a service role key do Supabase, que tem acesso irrestrito ao banco e ignora RLS, nunca aparece em código que roda no navegador, só em funções de servidor. Confira se existe confirmação de e-mail obrigatória antes do primeiro login, se o fluxo de redefinição de senha expira o link corretamente e se rotas administrativas checam o papel do usuário no servidor, não só escondem um botão na tela.

Vale também revisar se existe algum tipo de limite de tentativas em endpoints de login, para dificultar ataques automatizados de força bruta contra contas de usuários. Esses detalhes de segurança pós-export merecem tratamento sério, e não é exagero: tratamos o assunto de forma mais ampla, com os riscos que mais aparecem em projetos de Vibe Coding, no artigo sobre se Vibe Coding é seguro.

SEO num projeto Lovable: de SPA para prerender ou SSG

Aqui mora um limite técnico pouco falado. Projetos do Lovable nascem como single page applications: o navegador recebe um HTML quase vazio e o React monta o conteúdo depois, via JavaScript. Buscadores modernos conseguem indexar boa parte desse conteúdo, mas com atraso e menos consistência do que páginas que já chegam prontas no HTML, o que prejudica páginas de marketing que dependem de tráfego orgânico para funcionar.

Para telas internas do produto, atrás de login, isso importa pouco: ninguém encontra um dashboard privado pelo Google. Para landing page, blog e páginas institucionais públicas, importa bastante. Duas saídas práticas funcionam bem: usar um serviço de prerender que gera uma versão estática do HTML para os robôs de busca, ou migrar só as páginas públicas de marketing para um framework com renderização no servidor ou geração estática, como Next.js ou Astro, mantendo o produto logado como está. A segunda opção dá mais trabalho, mas rende resultado de SEO consistente no longo prazo, sem depender de um serviço externo intermediando o que o Google vê.

Manutenção e evolução do código gerado

Sessões longas de geração, principalmente quando o chat mistura pedidos de telas diferentes, tendem a deixar convenções inconsistentes: um componente chamado de um jeito aqui, de outro ali, lógica repetida em vez de reaproveitada. Isso não trava o produto no lançamento, mas encarece cada mudança futura, porque quem mexe no código precisa reaprender o padrão local antes de editar cada parte.

Um tempo investido já fora do Lovable, configurando o básico que qualquer projeto sério tem, se paga rápido: linter e formatter rodando no CI, checagem de tipos ativada de verdade (não só ignorada com comentários), e ao menos um monitoramento de erro em produção, como Sentry, avisando quando algo quebra para usuários reais. Esse investimento inicial parece burocracia, mas é o que evita que a segunda metade da vida do produto custe muito mais do que a primeira.

Vale também um comentário sobre como pedir ajustes à IA depois desse ponto. Continuar usando o Lovable, ou trazer outra ferramenta como Cursor ou Claude Code para o mesmo repositório, funciona bem quando cada pedido é pequeno e específico, com revisão humana antes de aceitar. O erro mais comum nessa fase de manutenção é voltar ao hábito de pedir mudanças grandes e aceitar tudo sem ler, o mesmo hábito que ajudou a criar o protótipo rápido e que, num projeto já em produção com usuários reais, custa muito mais caro quando dá errado.

Quando chamar engenharia

Alguns sinais indicam que vale trazer apoio técnico dedicado em vez de continuar sozinho: a auditoria de RLS revelou brechas reais em tabelas com dado sensível, o produto está prestes a receber os primeiros clientes pagantes, ou existe uma regra de negócio complexa demais para o padrão genérico que a IA reproduz bem. Nenhum desses sinais significa que o trabalho feito até ali foi perdido, significa que chegou a hora de somar experiência de quem já fez essa travessia várias vezes.

Um relato direto ajuda a ilustrar isso: a própria MVP Plus migrou o site institucional que você está lendo agora de um scaffold inicial construído no Lovable para a stack atual, seguindo exatamente esse caminho de exportar, revisar e assumir o código. É um processo conhecido de dentro, não só uma recomendação teórica.

Conclusão

Colocar um projeto do Lovable em produção é totalmente viável, e o caminho passa por etapas concretas: exportar o código via GitHub, sair da hospedagem padrão para um domínio próprio, revisar RLS e policies do Supabase com rigor, auditar autenticação, resolver o gap de SEO da SPA e organizar manutenção de longo prazo. Nada disso desmerece o Lovable como ferramenta de geração; só reconhece que gerar interface rápido e operar produto em produção são duas etapas diferentes, com necessidades diferentes.

Se o seu projeto Lovable já validou a ideia e agora precisa desse trabalho de revisão e produção feito com segurança, converse com o time da MVP Plus sobre o Vibe Squad.