← todos os posts
Segurança 9 min de leitura

"Exportar o código não é sair da plataforma: os 5 passos entre o zip e o app rodando no seu nome"

"Baixou o zip e o app continua morando na plataforma. Os 5 passos que faltam, na ordem, e o ensaio de 1 hora que prova três deles sem desligar nada."

"Deploy, GitHub e configurações de ambiente são os pontos mais comuns de travamento."

Quem escreveu isso não foi um crítico de vibe coding. Foi um curso brasileiro de vibe coding para não-dev, explicando na página de venda por que oferece suporte por WhatsApp. Quem vende o caminho já sabe onde as pessoas param. É a leitura de um curso, não estatística, mas descreve bem o fim de semana que você talvez já tenha tido: ouviu que dá pra sair da plataforma, apertou o botão de exportar, baixou o zip, e na segunda-feira o app continuava no mesmo lugar, com a mesma mensalidade.

Por que o zip não te tirou de lá

Porque exportar é um dos cinco passos, e é o único que a plataforma faz por você com um botão.

Não é palpite meu. A documentação do próprio Lovable, na página sobre hospedar fora dele, diz que nem a sincronização com o GitHub nem o download do código levam os dados do banco ou os arquivos guardados. Diz que o botão Publish "continua publicando só na hospedagem do Lovable", e que exportar o código não cancela a assinatura. Você não leu errado. Ninguém escreveu o resto.

O inventário e a ficha de saída te dizem onde você está. Este post é o passo seguinte: o caminho do zip até o app rodando numa conta com o seu nome, e um ensaio que você faz hoje sem desligar nada.

Os 5 passos, na ordem

1. Repositório no seu nome. Repositório é a pasta do código guardada no GitHub, com histórico de cada mudança. O zip é uma foto parada; o repositório é a fonte viva, que se atualiza a cada pedido que você faz na plataforma. O que importa aqui é de quem é a conta onde ele foi criado.

2. Banco próprio. Um projeto de banco de dados (Supabase, na maioria dos casos) criado no seu e-mail, com a estrutura das tabelas, os dados, as contas dos usuários, os arquivos e as funções que rodam no servidor.

3. Chaves. As variáveis de ambiente: valores de configuração que moram fora do código, como o endereço do banco e a chave de acesso. Já traduzi isso aqui. O código sem elas abre em branco.

4. Deploy. Deploy é pôr o app no ar num serviço de hospedagem seu (Vercel, Netlify), que pega o código do repositório e monta o site.

5. Domínio. Apontar o seu endereço pra nova hospedagem e avisar o login de que o endereço mudou.

A ordem não troca. Deploy sem chave abre em branco, a chave do banco novo não existe antes do banco novo, e domínio apontado antes da conferência é teste feito em cima dos seus clientes.

Agora o detalhe que muda o jogo, e que está na mesma documentação do Lovable: ela descreve um caminho chamado "só o frontend" (frontend é a parte do app que aparece na tela). Você hospeda o app fora e continua usando o banco que já existe. Isso quer dizer que os passos 1, 3 e 4 dá pra fazer hoje, com o banco de verdade intocado e o app dos seus clientes no ar como sempre. O passo 2 é o difícil, e o 5 é o do dia da troca.

O ensaio de hoje: uma hora, sem terminal

O objetivo é ter, até o fim do dia, uma cópia do seu app rodando num endereço .vercel.app, saindo de um repositório seu, numa hospedagem sua. Ninguém além de você vai usar esse endereço. É ensaio.

Os caminhos abaixo são do Lovable, que é onde a maioria dos leitores deste blog está. Bolt e Replit têm o equivalente com outros nomes.

Passo 1: confira de quem é o repositório

No Lovable, abra a integração com o GitHub. A documentação diz que o repositório é criado na conta ou organização ligada ao seu espaço de trabalho, e que ele nasce privado. Abra o GitHub e confira três coisas:

  • O repositório está na sua conta, não na de um sócio, de um freelancer ou da agência que começou o projeto.
  • A data da última mudança bate com o último pedido que você fez no Lovable.
  • Ele é privado.

Se estiver na conta de outra pessoa, peça a transferência. Pela documentação, a sincronização continua se o seu espaço no Lovable também estiver conectado à conta nova; senão, o projeto desconecta. E não apague o repositório: apagar interrompe a sincronização.

Passo 3: separe as chaves certas

Antes do deploy, as chaves. A documentação do Lovable lista as que um app comum precisa, e diz que os valores estão no arquivo .env do projeto (abra no editor de código do Lovable ou no próprio GitHub):

VITE_SUPABASE_URL
VITE_SUPABASE_PUBLISHABLE_KEY
VITE_SUPABASE_PROJECT_ID

Copie os três nomes e os três valores num bloco de notas. Pode copiar sem medo: tudo que começa com VITE_ já vai pro navegador de qualquer visitante do seu app. É chave pública por definição, e é por isso que o arquivo pode ficar no repositório.

A regra que você não quebra nem no ensaio: chave secreta não entra aqui. Nada com service_role, secret ou sk_live no nome ou no valor. Se o seu app usa funções no servidor com segredos (pagamento, e-mail), elas continuam rodando dentro do Lovable no ensaio. Só anote os nomes desses segredos na sua lista. Eles são assunto do passo 2.

Passo 4: o deploy

  1. Crie uma conta na Vercel entrando com o seu GitHub.
  2. Vá em New Project, escolha o repositório do app e, antes de clicar em Deploy, abra Environment Variables e cole as três chaves, nome e valor, uma por linha.
  3. Clique em Deploy e espere. A Vercel reconhece sozinha o tipo de projeto; a documentação dela descreve exatamente esse caminho: conectar o GitHub, escolher o repositório, clicar em Deploy, e a partir daí cada mudança no repositório gera uma publicação nova.

Sobre dinheiro: a Vercel diz que o plano grátis é só pra uso pessoal, não comercial. Pra um ensaio que só você abre, uso o grátis. App com cliente pagante vai pro Pro, cobrado em dólar por pessoa, e isso entra no custo mensal antes da troca.

A conferência

Pegue o endereço .vercel.app que apareceu e abra numa janela anônima (sem cache, sem login guardado). Ponha ao lado o seu app no endereço do Lovable. Agora:

  1. Abre? Tela branca quase sempre é chave faltando ou com valor errado. Confira letra por letra no painel da Vercel e mande publicar de novo, porque a chave nova só vale na publicação seguinte.
  2. Entra? Faça login com uma conta de teste, nunca a de um cliente. Lembre que esse app fala com o banco de verdade: olhe, não apague, não crie pedido falso no meio dos reais.
  3. Os dados aparecem? A mesma lista nos dois endereços.
  4. Recarregue numa página interna. Se der erro 404, falta uma regra que manda todo endereço pro mesmo arquivo do app. A documentação do Lovable avisa disso nos apps criados antes de maio de 2026. Peça à IA: "adicione a regra de reescrita da Vercel pra que toda rota abra o app. Não mude mais nada."
  5. Login com Google deu erro de redirecionamento? Esperado. É o passo 5 aparecendo mais cedo: o serviço de login tem uma lista de endereços permitidos, e o .vercel.app não está nela. Anote. Não mexa no login de produção pra fazer ensaio.

Cada coisa que não funcionou vira uma linha na lista, com o número do passo ao lado. E marque quanto tempo levou: é metade da resposta pra pergunta do inventário, "se a conta sumisse hoje, quanto tempo até estar no ar?".

O que o ensaio não fez, e por quê

O ensaio provou que o seu código monta fora da plataforma, numa conta sua, com as chaves certas. Ele não tirou o banco de lá. E é no passo 2 que mora a maior parte do trabalho, que a documentação do Lovable lista sem enfeite: criar o projeto Supabase no seu nome, aplicar a estrutura das tabelas na ordem certa, restaurar os dados com uma ferramenta de linha de comando (o arquivo exportado não é planilha), religar os provedores de login, copiar os arquivos que os clientes subiram, cadastrar os segredos das funções, recriar as tarefas agendadas sem que a mesma rode duas vezes, e testar tudo num deploy separado antes de trocar.

A boa notícia vem no mesmo texto: a exportação leva as contas dos usuários com a senha embaralhada, então seus clientes não precisam criar senha nova. E a regra de ouro, que o post de backup já ensinou: conta os registros na origem, conta no destino, e só apaga a origem quando os dois números baterem.

Só depois disso vem o passo 5. Domínio apontado pro endereço novo, o endereço novo na lista de permitidos do login, e o app do Lovable despublicado quando tudo estiver conferido. A documentação lembra que remover o Cloud apaga o banco de vez, junto com as exportações guardadas lá. Isso é a última coisa que se faz, não a primeira.

Era uma parede de cinco tijolos

O zip foi o tijolo 1. O ensaio de hoje, se deu certo, colocou o 3 e o 4. O 2 é o que exige ordem, contagem e alguém conferindo o que você não sabe que não sabe. O 5 é o dia da troca, com os clientes sem perceber nada.

E sair da plataforma é só a primeira fase de ser dono. Tirar o app de lá muda onde ele mora. Não deixa o login protegendo, não testa a regra de quem vê o quê, não te diz o que fazer quando quebrar numa sexta à noite. Cada uma dessas tem o seu portão, e eles vêm nessa ordem: primeiro o que é seu, depois o que está provado, depois o que se mantém no ar.

Fontes