Lovable e Supabase: como pôr o app feito com IA em produção

Segunda de manhã, a estreia já tem data: na quinta, os primeiros clientes recebem o link do app que você montou no Lovable. No bloco de notas, a lista do que falta tem três linhas: domínio, login com Google e apagar os pedidos de teste.

O app funciona na demonstração faz semanas. O que a lista não diz é onde mora cada coisa. O pedido de teste que você apagar no preview some só do preview? Quem consegue ler a tabela de clientes depois que o link sair, e de onde volta um registro apagado por engano na sexta?

O Lovable serve para produção, e o caminho até lá é uma lista curta, com a maior parte dela no banco de dados, que é onde entra o Supabase. A decisão de usar a ferramenta está no post sobre o que é Lovable. Aqui é o como, item por item, com a documentação oficial consultada em 19 de outubro de 2026.

Lovable e Supabase: Lovable Cloud ou Supabase próprio

O Supabase é uma plataforma de banco de dados PostgreSQL que traz junto login, armazenamento de arquivos e funções que rodam no servidor. No app feito com inteligência artificial no Lovable, o Lovable escreve as telas e o código, e o Supabase guarda o que o app precisa lembrar. Quem procura lovable supabase (ou supabase lovable, na ordem inversa) quer saber, antes de tudo, qual dos dois arranjos o próprio app usa.

• Lovable Cloud. É o backend embutido, ligado por padrão. A documentação do Lovable Cloud diz que ele é montado sobre a base aberta do Supabase, sem conta separada: banco, usuários e arquivos ficam numa aba dentro do próprio Lovable. Segundo a documentação do Supabase, esse projeto não aparece no seu painel do Supabase, e as chaves de administrador não ficam com você.
• Supabase próprio. Você cria a conta no Supabase, liga a organização ao Lovable e conecta o projeto. Banco, cobrança, backup e configuração de login passam a morar no painel do Supabase, na sua mão.

A diferença, pela página da integração com o Supabase:

Para a maioria dos projetos, o Cloud é o caminho mais curto até produção, e é assim que a documentação o apresenta. O Supabase próprio faz sentido quando você quer o painel, as chaves e a fatura no seu nome, ou quando já tem um projeto lá. Um ponto pesa na escolha: não existe migração automática entre os dois, em nenhuma direção. Trocar depois é exportar os dados, conectar o banco novo e pedir ao Lovable que recrie a estrutura, então vale decidir antes do primeiro cliente. A região onde o Cloud guarda os dados também não muda depois de ligada.

Como conectar o Lovable ao Supabase

São duas ações, que muitas vezes ficam com pessoas diferentes:

1. O dono ou administrador do workspace liga a organização do Supabase ao Lovable, uma vez só, em Connectors, na opção Supabase.
2. Quem edita o projeto abre More, depois Cloud, clica em "Already have a Supabase project? Connect it here" e escolhe o projeto na lista.

Depois disso, o Lovable cria as tabelas, roda cada mudança de estrutura com a sua aprovação no chat e publica as funções direto no seu projeto do Supabase. A integração existe em todos os planos, e o plano gratuito do Supabase basta pra começar.

Preview, teste e app publicado usam o mesmo banco

Aqui mora o tropeço de quem vai abrir o app: tratar o preview como um ambiente de teste separado. A documentação compara o preview do Lovable a um ambiente de teste, porque as telas que o visitante vê só mudam quando você publica. Com o banco, a conta muda: preview e app publicado usam o mesmo backend e os mesmos dados. Mudou no banco, mudou nos dois.

Na semana da estreia, isso aparece assim:

• Apagar o pedido de teste no preview apaga de verdade. E o cliente que entrar na quinta encontra tudo o que você cadastrou testando, a menos que alguém limpe antes.
• O rascunho também usa o dado real. Os rascunhos do Lovable separam as mudanças de código, mas o que você cadastra testando dentro de um deles entra no banco de verdade.
• Voltar uma versão desfaz o código, e o dado fica. O histórico de versões restaura o projeto e as funções, mas não devolve registro apagado nem desfaz mudança feita no banco.
• Branch no GitHub não cria outro banco. A página da sincronização com o GitHub avisa que o app rodando na sua máquina, com a configuração do projeto, lê e escreve no mesmo backend do app publicado.

Tem mais um detalhe, nas permissões do Cloud: a opção que deixa o Lovable incluir, alterar e apagar dados nas tabelas vem marcada como "Always allow". Com cliente usando, vale trocar para "Ask each time", em Connectors, na opção Cloud.

Nada disso é defeito do Lovable. Um banco só simplifica tudo enquanto o app é só seu. Com cliente dentro, ele pede uma regra simples: dado de teste com conta de teste, e limpeza combinada antes da estreia.

Banco, login e backup: o que conferir antes de abrir

Os três itens que mais pesam moram no Supabase, seja ele o seu ou o que roda por baixo do Cloud.

Regras de acesso no banco. No Supabase, quem lê e quem escreve cada linha de cada tabela é decidido pelas regras de RLS (row level security, segurança por linha). A lista de produção do Supabase pede RLS em todas as tabelas, porque tabela sem regra deixa qualquer cliente do app ler e alterar o que está nela. A documentação do Lovable vai além e diz que a falta dessas regras é o jeito mais comum de dado de app vazar.

Já contei no post sobre criar app com IA o que aconteceu em 2025 quando essa regra faltou.

O Lovable escreve regras básicas sozinho, e elas são mais fáceis de mudar antes de existir dado real. Peça no chat com a regra do seu negócio por extenso ("cada cliente vê e edita só os pedidos dele; o financeiro vê todos") e confira o resultado no painel.

Login. No Cloud, você liga login por e-mail, Google, Apple e outros pelo próprio Lovable. Com Supabase próprio, os provedores de login se configuram no painel do Supabase. Nos dois casos, um item costuma ficar pra trás: a documentação sugere desligar a confirmação de e-mail durante o teste, pra conta de teste entrar na hora, e religar antes de abrir para usuário real. Ponha esse item na lista da quinta. Com conta própria, a lista do Supabase pede ainda segundo fator de autenticação para quem administra o projeto.

Backup. No Cloud, o Lovable faz um backup diário do banco e guarda cerca de 14 dias. Restaurar é definitivo: o que entrou depois do backup escolhido se perde. No Supabase próprio, o backup diário automático começa no plano Pro, com 7 dias guardados; no plano gratuito, a recomendação é exportar os dados por conta própria e guardar fora. Nos dois, os arquivos que os usuários enviam (fotos, PDFs) ficam fora do backup do banco. Antes da estreia, saiba onde fica o botão de restaurar, quem pode apertar e quantos dias você perde se precisar dele.

Domínio, GitHub e versão: o que fica no Lovable

Domínio. Publicar sobe uma foto do projeto num endereço que termina em lovable.app, com HTTPS incluído. Domínio próprio entra nos planos pagos, e o guia de domínio próprio do Lovable dá três caminhos: comprar pelo próprio Lovable, conectar um domínio que você já tem (duas entradas no DNS do seu provedor) ou transferir o domínio. O certificado de segurança sai sozinho em todos. Faça isso no começo da semana, porque o domínio leva um tempo até ficar no ar.

Publicar de novo. Mudança feita depois de publicar não vai ao ar sozinha. O botão Publish mostra um ponto quando há novidade, e você sobe com "Publish changes". Ao abrir o botão, o Lovable roda uma varredura rápida de segurança que confere as regras de acesso do banco. Por padrão, o que ela encontra não impede a publicação, então resolva o que aparecer como crítico antes de mandar o link.

GitHub e versão. Quem procura lovable github quer guardar o código fora da plataforma, e é isso que a sincronização faz. Cada mudança feita no Lovable vira um registro num repositório seu, e o que um programador sobe por lá volta para o projeto. Junto com o histórico de versões, ela cuida do código. O dado continua dependendo do backup do item anterior.

Quem vê qual dado continua sendo decisão sua

O Lovable escreve a regra que você pedir, e escreve bem. A checagem automática de segurança dele, nas palavras da própria documentação do Cloud, não é uma auditoria completa. O que nenhuma ferramenta sabe sozinha é quem, na sua empresa, pode ver o quê, e essa decisão vem antes do prompt.

O primeiro passo do protocolo antivibe é mapear o terreno. Aqui, isso cabe em três perguntas respondidas por escrito antes da estreia:

• Quem vê qual dado. Cliente, atendente, financeiro e você: cada um enxerga quais tabelas e quais linhas.
• O que acontece se cair. De onde volta o dado apagado, quantos dias de backup existem e quem sabe restaurar.
• Quem mantém. Quem lê os registros de erro, quem publica as correções e quem responde quando o cliente reclama.

Com as respostas no papel, o pedido ao Lovable deixa de ser "faz a segurança" e vira a regra da sua operação. É o mesmo ponto do post sobre vibe coding: a IA leva o app longe, e o que vem depois é decisão. Escreva as três respostas antes de mandar o link.

O que monitorar depois que o cliente entra

Na primeira semana com cliente, três lugares merecem uma visita por dia:

• Registros de erro. Os logs do Cloud mostram pedidos, funções, banco, logins e erros, e dá pra colar um registro no chat e pedir a correção ao Lovable. Com Supabase próprio, eles ficam no painel do Supabase. Se o app manda e-mail ou conversa com outras ferramentas numa automação de processos, é ali que a falha aparece primeiro.
• Segurança. O Lovable confere o banco de novo depois de cada mudança de estrutura e aponta o que achou. Leia o aviso antes de publicar a mudança seguinte.
• Saldo e plano. No Cloud, o banco é pago com os mesmos créditos da construção, e contei no post sobre os créditos do Lovable o que acontece quando o saldo zera. No Supabase gratuito, app com pouca atividade em 7 dias pode ser pausado. Os outros custos depois do lançamento estão no post sobre quanto custa um aplicativo.

Erro e queda são a parte fácil de medir. Saber se o app está servindo pra alguma coisa leva mais tempo.

Eu já levei do zero ao ar um produto completo feito com IA: dez testers usando, e o primeiro tester contratado aos 45 dias. Foi um primeiro sinal real, ainda longe de uma hipótese validada, e hoje esse produto está paralisado. Abrir para cliente mostra que o app aguenta gente de verdade usando. Se ele resolve o problema de quem usa, só as semanas seguintes dizem.

Volto à segunda de manhã. A lista do bloco de notas ganha linhas: regra de acesso em cada tabela, confirmação de e-mail ligada, backup conferido, pedidos de teste limpos, domínio no ar e código no GitHub. Se ela travou em algum item, montei uma página sobre o que fazer com um app feito com IA que precisa chegar ao cliente. E se quiser que eu olhe o que já existe e separe o que vale evoluir, entre em contato e me conte em qual item ele parou.