← todos os posts

"Migração assistida: como é sair do Lovable com alguém do lado na sessão 1"

"O app funciona e mora numa conta que não é sua. O que acontece na sessão de saída, o que ela não promete e a ficha de 20 minutos pra fazer hoje."

"Você precisa rodar comandos no terminal. Precisa de Node.js instalado. Precisa entender o que é localhost. [...] Pra quem não é [programador], é uma parede."

Quem escreveu isso foi um programador, no TabNews, em fevereiro de 2026, num texto sobre onde quem não programa trava. Tá na pesquisa deste blog. (Terminal é a janela preta onde se digita comando; Node.js, um programa que o app precisa pra rodar; localhost, o endereço do app rodando só no seu computador.)

A cena que vem depois dessa parede eu conheço de cor: o app está no ar, tem gente usando, você liga ao GitHub (o serviço onde o código fica guardado, no que se chama repositório), baixa o código, roda na sua máquina e aparece uma tela branca. Dois fins de semana depois, ele continua no Lovable, e a mensalidade continua chegando.

A Mentoria Dono do App tem um bônus pra exatamente esse ponto: a migração assistida. A saída feita junto comigo, na primeira sessão individual, com os 8 guias do material de resgate que eu escrevi pra isso. A primeira turma ainda não existe, então não tem caso de aluno aqui. Tem o formato.

Por que você travou ali

Não foi falta de jeito. Sair da plataforma não é um passo, são quatro, e cada um depende do anterior: código, banco, login, publicação. Já contei o que o botão de exportar não copia. O tutorial que você seguiu tratava os quatro como um só, e travou no primeiro erro sem te dizer em qual dos quatro você estava.

Tem outro detalhe que ninguém avisa: ficar dentro do Lovable não é ficar parado. Cada mudança que você pede lá vira um registro no GitHub, e cada mudança no GitHub volta pra lá. A documentação do Lovable chama isso de sincronização nos dois sentidos. Então a saída não precisa ser um salto no escuro: dá pra fazer com o app de pé, por partes.

O que acontece na sessão 1

Antes. Você me manda a ficha de saída (ela está logo abaixo) e a mensagem exata do erro em que travou da última vez, com print. Eu abro o seu repositório antes da sessão.

Durante. A gente faz a primeira chave, o código: ele sai do Lovable e roda na sua máquina, com você no teclado e eu olhando a sua tela. Se aparecer a tela branca, a gente segue o diagnóstico de três verificações do material, na ordem. Quase sempre é uma variável de ambiente, que é um valor de configuração (a chave do banco, por exemplo) que mora fora do código e que o tutorial pulou. No fim, você marca o primeiro ponto de retorno, a foto do código funcionando pra onde dá pra voltar.

Depois. Você sai com o código no seu repositório, rodando na sua máquina, e com a ordem escrita das outras três chaves: banco, login, publicação.

O que ela não promete

Que sai tudo em uma hora. Não sai, e quem promete isso não olhou o seu app. A sessão 1 resolve a chave em que a maioria trava. O banco, o login e a publicação acontecem nas semanas seguintes, dentro da fase Construa, e o seu app de verdade continua no ar o tempo todo. Nada é apagado na origem antes de a cópia estar conferida. Essa é a regra da migração inteira.

E ela não deixa o app seguro nem provado. Tirar da plataforma muda onde o app mora. Login que protege e regra testada são as fases seguintes.

O que você faz hoje: a ficha de saída, em 20 minutos

Não migra nada. Só descobre onde você está. Se o seu app usa o banco do próprio Lovable (o Lovable Cloud), é assim:

1. O GitHub está em dia? Se o projeto está ligado ao GitHub, abra o repositório e olhe a data da última alteração. Ela tem que bater com a última mudança que você pediu no Lovable. Se não estiver ligado, ligue: não muda nada no app.

2. Conte o que você tem. No Lovable, vá em More → Cloud → Database. A tela lista as suas tabelas (cada tabela é uma "planilha" do banco: clientes, pedidos, agendamentos) com o número de linhas de cada uma. Anote tabela, número e data. Isso é a contagem na origem: no dia da migração, a cópia só vale se os números baterem.

3. Peça a exportação. Em More → Cloud → Overview → Advanced settings fica o Export database. A documentação do Lovable diz que o arquivo traz o banco inteiro, estrutura e dados, incluindo as contas dos usuários com a senha guardada de forma embaralhada. Dá pra pedir uma exportação a cada 24 horas, e o link chega por e-mail. Baixe e guarde fora do computador.

4. Anote o que NÃO veio junto. Pela mesma documentação, a exportação não leva os arquivos guardados (fotos, PDFs que os clientes subiram), o código das funções que rodam no servidor, nem os segredos do projeto, que são as senhas e chaves dos serviços ligados. Liste os nomes desses segredos, nunca os valores.

E uma linha em vermelho: não aperte "Remove Lovable Cloud". A documentação avisa que apaga o banco de vez, sem volta. A ficha é só leitura.

Se o seu banco é um Supabase na sua própria conta, os passos 2 e 3 acontecem lá, no painel do Supabase. O resto vale igual.

Era a primeira chave

A ficha te diz onde você está. Ela não sobe o código na sua máquina, não migra o banco com contagem conferida, não troca o login sem obrigar todo mundo a criar senha nova e não publica no seu domínio. São quatro chaves, numa ordem que não troca, e cada uma tem um jeito de dar errado que a anterior esconde. A sessão 1 é a primeira com alguém do lado. As outras três têm semana marcada.

Fontes