# Lovable e Supabase: como pôr o app feito com IA em produção
> O Lovable leva o app até o cliente. Antes de o link sair, alguém precisa conferir quem lê cada dado, onde fica o backup e quem cuida depois, e essa lista é trabalho seu.
Por Alexandre Leite, Colaboratório. Publicado em 2026-10-21, atualizado em 2026-10-21.
Fonte: https://colaborato.rio/blog/lovable-e-supabase/
## Em 30 segundos
- Lovable e Supabase são as duas metades do app: o Lovable escreve as telas e o código, e o Supabase guarda o banco, o login e os arquivos, dentro do Lovable Cloud ou numa conta sua. Pôr em produção é conferir, antes de o cliente entrar, quem lê cada dado, o backup, o domínio e a cópia do código.
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](https://colaborato.rio/blog/o-que-e-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](https://docs.lovable.dev/features/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](https://supabase.com/docs/guides/troubleshooting/identify-lovable-cloud-or-supabase-backend), 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](https://docs.lovable.dev/integrations/supabase):
| | Lovable Cloud | Supabase próprio |
| --- | --- | --- |
| Conta | Não precisa de outra | Conta e projeto no Supabase |
| Quem cobra | Créditos do workspace no Lovable | Assinatura do Supabase |
| Onde você mexe | Aba Cloud, dentro do Lovable | Painel do Supabase |
| Backup, tamanho e pausa | O Lovable cuida | Você cuida no 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.
1. 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](https://docs.lovable.dev/features/projects/preview) 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](https://docs.lovable.dev/features/drafts) 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](https://docs.lovable.dev/features/projects/history) 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](https://docs.lovable.dev/integrations/git-sync-overview) 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](https://supabase.com/docs/guides/platform/going-into-prod) 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](https://colaborato.rio/blog/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](https://docs.lovable.dev/tips-tricks/security-best-practices) 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](https://docs.lovable.dev/features/database) 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](https://supabase.com/docs/guides/platform/backups) 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](https://docs.lovable.dev/tips-tricks/launch-on-a-custom-domain) 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](https://docs.lovable.dev/features/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](https://colaborato.rio/blog/sai-dessa-vibe-errada/) é 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](https://colaborato.rio/blog/o-que-e-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](https://docs.lovable.dev/features/logs) 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](https://colaborato.rio/blog/automacao-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](https://colaborato.rio/blog/creditos-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](https://colaborato.rio/blog/quanto-custa-criar-um-aplicativo/) 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](https://colaborato.rio/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](https://wa.me/5521992438381?text=Oi%21%20Li%20o%20artigo%20%22Lovable%20e%20Supabase%3A%20como%20p%C3%B4r%20o%20app%20feito%20com%20IA%20em%20produ%C3%A7%C3%A3o%22%20no%20site%20e%20queria%20conversar.) e me conte em qual item ele parou.
## Perguntas frequentes
### Como conectar o Lovable ao Supabase?
O dono ou administrador do workspace liga a organização do Supabase ao Lovable uma vez, em Connectors. Depois, quem edita o projeto abre More, Cloud e escolhe o projeto do Supabase na lista. A integração existe em todos os planos, e o plano gratuito do Supabase basta pra começar.
### Como migrar Lovable Cloud para Supabase?
Não existe migração automática, em nenhuma das duas direções. O caminho da documentação é exportar o banco em Advanced settings, conectar o novo projeto do Supabase e pedir ao Lovable que recrie a estrutura. A exportação leva estrutura e dados, e deixa de fora arquivos, funções e segredos, que você leva à parte.
### O Supabase é gratuito?
Tem plano gratuito, e ele basta pra começar a integração com o Lovable. Para produção, pese dois pontos da documentação do Supabase: o backup diário automático começa no plano Pro, e app do plano gratuito com pouca atividade em 7 dias pode ser pausado. No Lovable Cloud, o banco é pago com os créditos do workspace.
### Qual a segurança do Supabase?
A segurança dos dados no Supabase depende das regras de RLS, que dizem quem lê e quem escreve cada linha de cada tabela. Tabela sem regra fica aberta para qualquer cliente do app ler e alterar. Ligue o RLS em todas as tabelas, escreva a regra do seu negócio e proteja a conta do Supabase com segundo fator.
### O que é e para que serve o Supabase?
O Supabase é uma plataforma de banco de dados PostgreSQL que traz junto login, armazenamento de arquivos, funções no servidor e atualização em tempo real. Num app do Lovable, ele é a parte que guarda o que o app precisa lembrar, seja no Lovable Cloud, montado sobre ele, seja numa conta sua.