---
title: "Como levar um app feito no Lovable para produção: o checklist que usamos"
url: https://samambai.com/pt/blog/como-levar-app-lovable-para-producao/
date: 2026-10-03
author: samambai
---

Publicar no Lovable coloca o app no ar. Produção é outra coisa: um segundo usuário entra, vê só o que é dele, e o serviço continua de pé no dia seguinte. O checklist abaixo separa o que a Lovable já faz do que continua manual.

Levar um app feito no Lovable para produção é conferir, com uma segunda conta, se cada pessoa vê só o que é dela, se os segredos não estão no navegador, se existe backup que alguém já restaurou e se o serviço não depende de um projeto gratuito que pode pausar. O botão Publish coloca uma versão no ar. O checklist abaixo é o que falta depois disso.

Este texto é o roteiro que usamos antes de chamar um app de pronto para usuário real. Ele serve para o fundador que já tem a tela funcionando e para o time interno que vai colocar dado de cliente atrás do login. Se o que você quer é alguém fazendo esse trabalho, o escopo está na página [levar o app do Lovable para produção](/pt/lovable-para-producao/).

## O que "em produção" quer dizer aqui

Preview é a tela que você abre enquanto constrói. Publish, na documentação da Lovable, gera um snapshot público com HTTPS. Endereço em `lovable.app` é gratuito em todos os planos. Domínio próprio entra nos planos pagos [1].

Produção, neste checklist, é um critério mais estreito. Uma pessoa que não é você cria conta, usa o fluxo principal, não consegue abrir a linha do vizinho, volta no dia seguinte e encontra o serviço de pé. Pagamento, se existir, passa por um provedor. O cartão não fica gravado na tabela.

A Lovable descreve o caminho recomendado para a maioria dos apps como ficar nela: preview, publicação, backend e domínio no mesmo lugar [2]. Sair é uma decisão, não um rito de passagem.

## O que a Lovable já resolve

O código é seu, sujeito às licenças de código aberto dos componentes. Você pode alterar, usar comercialmente e hospedar onde quiser [1]. Git sync existe em todos os planos e mantém o repositório no GitHub, GitLab ou Bitbucket. O download do código em zip existe nos planos pagos [1] [2].

A plataforma constrói aplicação web, não app nativo. Não gera projeto React Native. Se a meta é a App Store, o caminho oficial é um PWA ou um empacotamento feito fora da Lovable [1].

A pilha depende da data do projeto. Apps criados a partir de 13 de maio de 2026 (22 de junho de 2026 em workspace Enterprise) usam TanStack Start e executam código no servidor. Apps anteriores usam React e Vite e geram arquivos estáticos. Não há escolha de framework nem de banco: o banco é PostgreSQL, pelo Cloud embutido ou por um projeto Supabase [1].

Para saber qual é o seu, abra o `package.json`. Projeto TanStack Start lista `@tanstack/react-start`. O antigo não lista. Um host que só recebe arquivo estático não executa as funções de servidor de um app TanStack Start [2].

Certificações declaradas: SOC 2 Type II, ISO 27001:2022 e AIUC-1. A mesma FAQ diz que a Lovable não é compatível com HIPAA e não assina Business Associate Agreement. Os termos padrão não permitem dado de saúde protegido, número de cartão, número de conta financeira, documento oficial de identidade nem biometria dentro do app. Cobrança deve usar o pagamento embutido ou uma conta Stripe sua [1].

Desde 9 de setembro de 2026, planos Free e Pro podem usar prompts, código e arquivos do projeto para treinar modelos, salvo opt-out na conta. Dado de usuário final do app e dado de Business ou Enterprise ficam de fora por padrão [1].

## O que continua manual

Exportar o código não exporta o produto. Git sync e o zip trazem o fonte, os arquivos de configuração e as migrations. Não trazem os registros do banco nem os arquivos do storage [2]. O export de dados do Cloud, em More, Cloud, Overview, Advanced settings, também não inclui arquivos armazenados, código de Edge Function nem segredos [1].

Quando o destino é outro Supabase, a própria documentação de saída separa o automático do manual [2]:

| Peça | Como migra | O que você ainda faz |
| --- | --- | --- |
| Schema (tabelas, colunas, índices, políticas de RLS, funções, triggers) | Automático, via migrations SQL | Conferir no destino se a política que você acha que existe está mesmo aplicada |
| Buckets de storage (a estrutura e as políticas de acesso) | Automático, via migrations SQL | Copiar os arquivos, um a um |
| Provedores de login (Google, GitHub e outros) | Manual | Recriar o provedor e as URLs de redirect |
| Variáveis de ambiente e segredos | Manual | Colocar de novo cada chave. O segredo não viaja no export |
| Conteúdo das tabelas | Manual | CSV por tabela, ou export completo do banco, e importar no destino |
| Contas de usuário | Manual, parcial | O export do banco leva os hashes de senha. Quem estava logado entra de novo. O provedor de login se configura outra vez |
| Edge Functions, jobs agendados, conectores e recursos de IA | Manual | Código de função em `supabase/functions/`. Segredos à parte. Funções TanStack Start sobem com o app no host novo |

Mover só o Postgres não leva autenticação, storage, realtime nem Edge Functions. Isso está no guia de saída, e é o erro que mais aparece quando alguém "só fez o dump" [2].

Variáveis com prefixo `VITE_` entram no build. Trocar a URL do banco depois exige gerar o build de novo. Um app que usa o Cloud precisa, no browser, de `VITE_SUPABASE_URL` e `VITE_SUPABASE_PUBLISHABLE_KEY`. No servidor TanStack Start, o par sem o prefixo `VITE_` também entra. Segredo de função não está no repositório [2].

## O checklist

Faça na ordem. Segurança de dados vem antes de domínio bonito. Cada item cabe num teste de 15 minutos com uma segunda conta, criada num e-mail que não é o seu.

### Autenticação

1. Crie um usuário de teste que não seja o dono do projeto. Percorra cadastro, login, recuperação de senha e logout.
2. Confirme e-mail ligado. A checklist de produção da Supabase pede confirmação de e-mail e um SMTP seu, de preferência no mesmo domínio do app. Sem SMTP próprio, o limite de e-mails de autenticação é de 2 por hora, medido desde 3 de setembro de 2024. Com SMTP próprio, o padrão passa a 30 novos usuários por hora. Um lançamento público estoura os dois [3].
3. Validade do código de uso único em 3600 segundos ou menos. A Supabase recomenda esse teto, e um código mais longo se você precisar de mais entropia [3].
4. Se o login é Google ou outro OAuth, a URL de produção (e a de preview, se alguém usa) está na lista de redirects permitidos. Trocar de domínio sem isso derruba o login no dia da virada [2].
5. MFA no projeto Supabase, para a conta de administrador. A checklist pede MFA na conta e sugere mais de um owner na organização, para o app não ficar refém de um notebook perdido [3].
6. Link de e-mail de uso único pode ser consumido por um filtro corporativo que abre o URL antes da pessoa. A Supabase descreve o sintoma: o usuário clica e o link já foi gasto. O contorno é um botão no seu domínio, e desligar o rastreamento de clique do SMTP [3].

### Segredos

1. Procure no repositório, no zip e no bundle do browser por chave que comece com padrão de segredo: Stripe secret, service role, token de API. A chave publicável (`VITE_SUPABASE_PUBLISHABLE_KEY`) pode estar no front. Ela não é um segredo. Qualquer chave que ignore a política de linha não pode estar no front [2] [3].
2. Segredo de Edge Function e de função de servidor mora no ambiente do destino, não no Git. O export não os inclui [1].
3. Se o app sai da Lovable, quem opera o host novo passa a ser dono do pipeline, das variáveis, do cache, da disponibilidade e do log. A Lovable não monitora infraestrutura que não controla [2].

### RLS e dados

RLS é a regra que decide qual linha cada usuário pode ler ou escrever. A checklist da Supabase é direta: ligue RLS em todas as tabelas. Tabela sem RLS, com permissão concedida, pode ser lida e alterada por qualquer cliente que tenha a chave [3].

1. Abra o painel de tabelas e anote quais estão sem RLS. Uma tabela "de rascunho" esquecida vaza do mesmo jeito que a tabela principal.
2. Com a segunda conta, tente ler e editar um registro que não é dela. Troque o identificador na URL e na chamada. Se a linha voltar, a política não existe ou deixa passar todo mundo.
3. Repita para insert, update e delete. Uma política só de leitura deixa o usuário apagar a linha do vizinho.
4. Dado de mais de uma empresa no mesmo banco (o caso multi-tenant) precisa de uma coluna de dono e de uma política que a use. "Usuário vê o que é dele" não basta quando o dele é a academia inteira, e não a pessoa.
5. SSL obrigatório no banco e restrição de rede, se o plano permitir. São itens da mesma checklist [3].
6. Índice para a consulta que a tela faz o tempo todo. A Supabase manda olhar o Performance Advisor e testar carga de preferência num ambiente separado [3].

Não guarde no banco o que os termos da Lovable proíbem: dado de saúde protegido, cartão, conta financeira, documento oficial, biometria [1].

### Arquivos

1. Liste os buckets. A estrutura migra com a migration. O arquivo, não [2].
2. Abra um arquivo de outro usuário com a segunda conta. Política de storage é independente da política da tabela. As duas podem estar certas ou erradas em separado.
3. Se houver upload, teste o tamanho que um cliente real manda, não o PNG de 40 KB do preview.

### Ambientes

1. Separe preview e produção. O preview da Lovable é o lugar de experimentar. O banco de produção não é.
2. Se você hospeda o front fora, o build de produção usa as variáveis de produção. `VITE_` entra na hora do build. Um build feito com a URL de preview e publicado no domínio final aponta para o banco errado sem aviso visível [2].
3. Em projeto Supabase no plano Pro, a checklist sugere branching para testar migration antes de chegar na produção, e o fluxo de Deploy to production a partir do GitHub para não depender de um `db push` manual na máquina de alguém [3].
4. Node 22 é a versão que os exemplos oficiais de deploy usam [2].

### Observabilidade

1. Saiba onde olhar quando a tela branca aparecer na segunda-feira. Dentro da Lovable, o suporte dos planos pagos responde por e-mail em até 24 horas, em geral em dia de semana, depois que a IA de suporte não resolve [1]. Fora da Lovable, o log é seu [2].
2. Tenha um jeito de saber que o login quebrou sem esperar o cliente escrever. Um teste agendado do fluxo principal, com a conta de teste, basta no começo.
3. Anote quem é o segundo owner da organização Supabase [3].

### Custos e continuidade

1. Projeto Supabase no plano Free pode ser pausado depois de 7 dias de pouca atividade. Dá para religar pelo painel. O plano Pro é o que a Supabase indica para o projeto não pausar por inatividade. Backup do plano Free não está disponível para download [3].
2. Se o banco deve passar de 4 GB, a checklist pede Point in Time Recovery. A durabilidade de disco padrão citada é de 99,8% a 99,9%. PITR é o caminho quando um disco falhar e você precisar voltar a um segundo específico [3].
3. Crédito da Lovable acaba no meio do mês se o time continua pedindo mudança grande no chat. Plano pago inclui um pacote mensal. Top-up existe em Pro e Business. Isso é custo de construção, separado do custo de manter o app no ar [1].
4. Esconda o selo "Edit with Lovable" só se isso importa para o cliente. A opção existe nos planos pagos, por projeto, e some na hora, sem republicar [1].

## Sinais de que o app não está pronto

- A segunda conta vê a lista inteira de clientes, pedidos ou alunos.
- O cadastro funciona para você e falha para a terceira pessoa do dia, porque o e-mail de confirmação parou no limite de 2 por hora [3].
- O único backup é "a Lovable tem o projeto". Você nunca baixou um export nem restaurou numa cópia.
- O projeto Supabase está no Free e ficou uma semana sem acesso. Ele pode acordar pausado [3].
- A chave que fala com o Stripe, com o banco privilegiado ou com um fornecedor aparece no código que o browser baixa.
- O app guarda cópia de documento, cartão ou prontuário. Os termos padrão não cobrem isso [1].
- Ninguém além de você consegue publicar, e você viaja na semana do lançamento.
- A URL de produção ainda é a de preview, ou o domínio próprio aponta para um build feito com a variável de outro ambiente [2].

Um desses itens já segura o lançamento. Três juntos são o padrão de app que "funciona na demo".

## Erros comuns

Tratar o preview como homologação. O preview usa a sua sessão e os seus dados de teste. O buraco aparece com o segundo usuário.

Achar que RLS "já veio ligado" e não abrir o painel. A Lovable ajuda a escrever política, e a Supabase ainda coloca a revisão na sua checklist, não na dela [3]. Política ausente e política que deixa passar todo mundo falham do mesmo jeito para o cliente.

Exportar o zip e achar que o produto mudou de casa. Ficaram para trás registros, arquivos e segredos [1] [2].

Publicar o app TanStack Start num host de arquivo estático. A função de servidor não roda. O guia separa os dois tipos de projeto de propósito [2].

Subir o service de pagamento guardando o número do cartão "só por um tempo". O caminho aceito é o pagamento embutido ou o Stripe da sua conta [1].

## O que não fazer

Não desligue o projeto de origem no mesmo dia em que o destino sobe. Rode os dois até a segunda conta completar o fluxo no destino e até um arquivo real abrir.

Não coloque dado de produção no projeto em que o chat da Lovable ainda está experimentando schema. Cada mudança de tabela no meio do lançamento reabre a pergunta do RLS.

Não reescreva o app em outro framework porque um artigo antigo descreve Lovable como "React + Vite e só". A FAQ atual, de outubro de 2026, descreve TanStack Start para apps novos e React + Vite para os anteriores [1]. Reescrever é um projeto diferente de endurecer.

Não use o plano Free da Supabase como produção de cliente pagante. A pausa por inatividade e a ausência de backup baixável estão escritas na checklist [3].

## Quando dá para seguir sozinho

Siga sozinho se todas as frases abaixo forem verdadeiras.

O app tem um usuário, ou um grupo que compartilha a mesma conta de propósito. Não há dado de uma empresa misturado com o de outra. Você abriu o painel, viu RLS ligado nas tabelas que importam e testou com uma segunda conta. Você exportou o banco, restaurou numa cópia e abriu um registro. O projeto Supabase não está no Free, ou você aceita religar na mão se ele pausar e não tem cliente dependente disso. Não há cartão, prontuário nem documento oficial no banco. Você sabe em qual host o app roda e quem recebe o alerta se o login cair.

Nesse desenho, o checklist é uma tarde de trabalho. Anote o que testou. Daqui a um mês você não lembra.

## Quando chamar alguém

Chame alguém quando o app já tem cliente, ou vai ter na semana que vem, e você não consegue responder "quem vê esta linha?" sem abrir o código. O caso típico é multi-tenant: cada cliente da sua empresa tem os próprios usuários, arquivos e cobrança.

Também chame quando o destino deixa a Lovable por uma regra externa (residência de dado, pipeline da empresa, rede privada) e o guia de saída vira uma lista de tarefas, não um parágrafo [2]. Ou quando o time que construiu no chat não é o time que vai atender o incidente.

Uma agência em inglês, a VeryCreatives, publica na própria página que um sprint de endurecimento de app Lovable leva de 2 a 4 semanas e custa de US$ 5.000 a US$ 15.000, conforme o tamanho do app e o quanto o schema e o front precisam ser refeitos. Esse número é o preço desse fornecedor, não uma média de mercado. A página deles ainda descreve a pilha como um app React de página única. A FAQ atual da Lovable descreve outra pilha para apps criados a partir de maio de 2026 [1] [4]. Use o intervalo só como referência de quanto um estúdio cobra por esse trabalho, e confira a pilha no `package.json` do seu projeto.

Na samambai, o mesmo tipo de revisão começa num sprint de duas semanas, a US$ 1.200. Isso não é o escopo de US$ 5.000 a US$ 15.000. Um produto com ambiente separado, domínio e pagamento cabe em projeto a partir de US$ 3.000, com entrega a cada sprint, em geral de 4 a 8 semanas, e o escopo fecha depois de olhar o app. Os três formatos estão em [preços](/pt/precos/). A primeira conversa tem 30 minutos e não gera compromisso.

O trabalho usa o mesmo processo do estúdio: diagnóstico, estratégia, execução, evolução. No diagnóstico a gente lê o projeto com você. Na execução, agentes de IA ajudam a varrer política, diff e teste, e uma pessoa revisa antes de qualquer mudança ir para o ar. O acesso é o mínimo. O dado fica na sua conta. Não entra em treino de modelo público.

## Quando não contratar a samambai

Não contrate se você ainda não tem app. A Lovable existe para construir essa primeira versão. Chegar com um parágrafo de ideia e pedir "produção" é pular a etapa.

Não contrate se o prazo é menor que uma semana e o app tem login e dado de cliente. Dá para publicar. Não dá para revisar, testar com a segunda conta e deixar um backup restaurável nesse prazo sem cortar o teste.

Não contrate se você não pode compartilhar o projeto ou o repositório. Sem isso, a revisão é opinião sobre print.

Não contrate se o produto precisa guardar cartão, prontuário ou documento oficial dentro do app. Os termos padrão da Lovable não permitem, e a gente não contorna os termos [1].

Não contrate se o que você quer é um app nativo nas lojas. A Lovable não gera React Native [1].

Não contrate se a conversa é "reescreve tudo" e o app, na prática, precisa de política, domínio e backup. E o inverso também: se a regra da sua empresa exige sair da Lovable por completo, diga isso na primeira conversa. Endurecer em cima do Cloud é um escopo. Mudar de casa é outro.

## Um caso, sem o nome

Um SaaS B2B para academias nasceu no Lovable, com backend Supabase, e hoje roda em produção com clientes pagantes. É multi-tenant: cada academia tem os próprios alunos, e a política de linha é o que impede uma unidade de abrir a lista da outra. O caminho não foi reescrever o produto em outro framework. Foi tratar schema, acesso, ambiente e operação como trabalho de produção, com o código continuando a ser do dono do produto.

O mesmo critério cabe num portal interno ou num app de um cliente só. Muda o tamanho da política, não a pergunta. Quem pode ler esta linha?

Se a resposta ainda é "o preview funciona", o próximo passo é o checklist, ou a página do serviço em [lovable para produção](/pt/lovable-para-producao/). Se o que falta é ligar o app a CRM, planilha ou WhatsApp depois que ele estiver de pé, isso é outro trabalho, descrito em [automação com n8n](/pt/automacao-n8n/).