Levamos seu app do Lovable para produção

Um app que abre no preview do Lovable entra em produção quando uma pessoa que não é você consegue criar conta, ver só o que é dela e voltar no dia seguinte com os dados intactos. Publicar no botão Publish coloca o site no ar. Não revisa quem pode ler cada linha do banco.

Para quem é

Esta página é para quem já tem um app funcionando no preview, ou publicado num endereço lovable.app, e precisa que ele aguente usuário real. O caso típico é um fundador, uma agência ou uma operação interna que validou a tela e agora vai colocar login, dado de cliente e, às vezes, cobrança.

Também serve para o time que quer continuar iterando no Lovable e, ao mesmo tempo, ter um ambiente de produção com dono. A documentação oficial descreve esse desenho híbrido: o repositório fica sincronizado, a Lovable continua editando e mostrando o preview, e outro host serve o app ao vivo Fonte [1].

Não é uma página para quem ainda está na ideia. Se ninguém usa o preview, o próximo passo é seguir construindo na própria Lovable, que foi feita para isso.

O que a Lovable já resolve

A Lovable se descreve como o caminho mais simples para um app pronto para rodar, e o caminho recomendado para a maioria dos casos é deixar preview e produção nela Fonte [1]. Ao publicar, o projeto ganha URL pública com HTTPS. Endereço em lovable.app é gratuito em todos os planos. Domínio próprio entra nos planos pagos Fonte [3].

O código é seu. Você pode alterar, usar comercialmente e hospedar onde quiser, respeitando as licenças de código aberto dos componentes. O banco, o storage e a configuração são portáteis. A Lovable diz que não depende de um armazenamento proprietário Fonte [1].

A plataforma declara certificações SOC 2 Type II, ISO 27001:2022 e AIUC-1. Também diz, com clareza, que 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 dado biométrico dentro do app. Pagamento deve passar pelo meio de pagamento embutido ou por uma conta Stripe sua, sem guardar o cartão no banco Fonte [3].

O editor da Lovable em si não pode ser instalado na rede do cliente. O app que você constrói pode Fonte [1].

A pilha mudou em 2026. Apps criados a partir de 13 de maio de 2026 (22 de junho de 2026 em workspaces Enterprise) usam TanStack Start, que executa 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 backend embutido (Cloud) ou por um projeto Supabase seu Fonte [3].

O que entregamos

O sprint de endurecimento cobre o que a documentação trata como responsabilidade sua no momento em que o backend sai da mão da Lovable, ou quando o app continua nela mas já guarda dado de gente de verdade Fonte [1] Fonte [2].

• Revisão de segurança e de dados. Mapa do que o app guarda, de quem pode ler e do que não deveria estar ali.
• Row Level Security (RLS) no Postgres. A Supabase avisa que tabela em schema exposto, sem RLS e com permissão aberta, pode ser lida e alterada por qualquer papel que tenha grant. Ligar RLS sem política fecha o acesso pela chave publicável até existir política. A chave secreta, a que age como service_role, ignora o RLS e não pode ir para o navegador Fonte [5].
• Segredos. Chave de API, token de Stripe e senha de SMTP ficam no servidor ou no cofre do projeto, nunca no bundle do frontend. Na migração, a própria Lovable marca segredos como passo manual: o export não leva esses valores Fonte [2] Fonte [3].
• Autenticação. Provedores (e-mail, Google e o que o app já usa), URLs de redirect do domínio novo, confirmação de e-mail, prazo de código de uso único e, quando o risco pede, segundo fator. A Supabase recomenda confirmação de e-mail ligada, código com validade de no máximo uma hora e SMTP do seu domínio, porque o limite padrão de e-mail de autenticação é baixo para um lançamento Fonte [4].
• Domínio, HTTPS e o caminho de publicação. Se o app fica na Lovable, domínio próprio no plano pago. Se o frontend sai, pipeline com rollback, variável de ambiente e fallback de rota. App antigo em React e Vite precisa devolver index.html nas rotas do cliente. App em TanStack Start precisa de um host que rode servidor, não só um CDN de arquivo estático Fonte [2].
• Backups. No plano Free da Supabase, backup de banco não fica disponível para download, e projeto com pouca atividade pode ser pausado depois de sete dias. O plano Pro evita essa pausa por inatividade. Point-in-Time Recovery existe para quem precisa voltar a um segundo específico Fonte [4].
• Monitoramento. Log de autenticação, erro de função e um alerta que uma pessoa lê. A Lovable não monitora infraestrutura que ela não controla Fonte [2].
• CI/CD. Mudança de schema saindo do Git, não de um db push feito na máquina de alguém na sexta-feira. A Supabase descreve o caminho de ligar o repositório e publicar a partir da branch principal Fonte [4].
• Performance. Índice nas colunas que a política de RLS filtra, consulta quente identificada, e uma passada no que o usuário sente no celular.
• Documentação. O que está em produção, onde está a chave, como restaurar e quem acionar.

O checklist longo, com o que migra sozinho e o que não migra, está no artigo Como levar um app feito no Lovable para produção.

Como funciona

O processo é o mesmo das outras frentes: diagnóstico, estratégia, execução, evolução. No app que já existe, ele vira quatro momentos concretos.

1. Diagnóstico. Acesso de leitura ao projeto (ou ao repositório sincronizado) e uma lista do que está exposto. A conversa inicial tem 30 minutos e não gera compromisso. Se o encaixe for ruim, a resposta é essa, por escrito.
2. Sprint de endurecimento. Duas semanas, um foco. Em geral a ordem é dado e RLS primeiro, porque é o buraco que vaza com a chave que já está no frontend. Segredos, autenticação, domínio, backup e pipeline vêm em seguida.
3. Entrega. O app no domínio combinado, políticas testadas com um usuário que pode e um usuário que não pode, backup restaurado pelo menos uma vez em ambiente de teste, e um documento curto de operação.
4. Acompanhamento. O período depois da entrega faz parte do projeto. Quem quer evolução contínua entra na parceria mensal.

Quem constrói aqui trabalha com agentes de IA no próprio processo (construção, testes e uma auditoria separada de quem escreveu o código). A revisão final é humana. Dado de cliente fica na conta do cliente, com acesso mínimo, em prática compatível com LGPD e GDPR, e não entra em treino de modelo público.

Prazos e preço

O sprint custa US$ 1.200 por duas semanas e pode ser cancelado quando você quiser. O projeto fechado começa em US$ 3.000, com escopo, prazo e preço definidos, entrega a cada sprint e suporte depois da entrega. A parceria começa em US$ 900 por mês, com roadmap contínuo e uma conversa mensal. O detalhe dos três formatos está em Preços.

Na prática deste serviço: um endurecimento com escopo fechado (RLS, segredos, autenticação, domínio e backup) cabe em um ou dois sprints. Um produto com vários inquilinos, cobrança e ambiente separado de produção costuma ser projeto, de 4 a 8 semanas. Esses prazos são os mesmos que a operação publica para projeto completo. Não são garantia de um app que ninguém ainda abriu.

Agências em inglês publicam outra faixa para o mesmo tipo de trabalho. A VeryCreatives, no próprio site, descreve um sprint de endurecimento de 2 a 4 semanas entre US$ 5.000 e US$ 15.000, conforme o tamanho do app e o quanto o schema e o frontend precisam ser refeitos. É preço de quem vende o serviço, não uma média de mercado Fonte [6]. O número serve para situar o comprador. O escopo de um sprint de US$ 1.200 não é o escopo de um projeto de US$ 15.000.

O que não fazemos

• Não reescrevemos o produto do zero quando o que falta é endurecer o que já existe.
• Não assumimos um app que ninguém deixou abrir. Sem o projeto ou o repositório, não há diagnóstico.
• Não guardamos número de cartão no banco. A restrição está nos termos da Lovable, e o caminho de pagamento é o provedor Fonte [3].
• Não transformamos o app web em app nativo de loja como parte deste sprint. A Lovable não gera projeto React Native. PWA ou um empacotamento externo é outro trabalho Fonte [3].
• Não instalamos o editor da Lovable dentro da VPC do cliente. Isso a plataforma declara que não faz Fonte [1].
• Não prometemos que a Lovable vai caber para sempre. Se a restrição for residência de dado, rede privada ou uma política interna que exige host auditado, o caminho oficial é mover o pedaço que esbarra nisso, não fingir que o plano recomendado cobre o caso Fonte [1].

Quando não contratar

Continue só na Lovable se o app ainda é um teste, com você e mais uma pessoa, sem dado pessoal de cliente e sem cobrança. Publicar e seguir iterando é o caminho que a própria documentação chama de recomendado Fonte [1].

Contrate um time de produto, não um sprint de endurecimento, se a decisão em aberto é o que construir. Endurecer a tela errada só torna a tela errada mais difícil de apagar.

Peça outro fornecedor se você precisa de um framework que a Lovable não gera, ou de um contrato HIPAA. A FAQ oficial é direta nos dois pontos Fonte [3].

Um caso real, sem o nome

Um SaaS B2B multi-tenant para academias nasceu no Lovable, com backend Supabase, e hoje roda em produção com clientes pagantes. O nome da empresa não é público. O fato que importa para quem está lendo é o formato: várias academias no mesmo app, cada uma enxergando só a própria base, com gente pagando para usar.

Esse formato é exatamente onde RLS mal escrita vaza. A política não pode ser "usuário autenticado lê a tabela". Ela tem de amarrar a linha à academia daquele login, e o teste tem de provar o contrário: outra academia, mesmo autenticada, não lê a linha. A Supabase trata isso como defesa dentro do banco, não como um filtro que vive só na tela Fonte [5].

Se o seu caso é integração e rotina, e não um app, o caminho vizinho é automação com n8n. Se a pergunta é de preço antes de escopo, comece por Preços.