Como Migrar do Lovable para a Mythex (Código, Dados e Domínio)

Para migrar do Lovable para a Mythex, tire o código do Lovable através da sua integração com o GitHub, depois traga-o para um projeto Mythex ligando o repositório ou importando um arquivo, volte a adicionar os seus segredos e teste no Preview antes de publicar. O frontend costuma mudar sem alterações. As decisões reais são sobre o backend: manter o seu projeto Supabase existente, ou mover os dados para outro sítio.

Este guia percorre toda a mudança por ordem e é honesto sobre as partes que dão trabalho.

Antes de começar: o que se move de facto

Uma app do Lovable é várias coisas, e cada uma move-se de forma diferente.

Escreva esta tabela para a sua própria app primeiro. Leva dez minutos e evita a maioria das surpresas.

Passo 1: Tire o seu código do Lovable

A documentação do Lovable (a partir de setembro de 2026) descreve duas formas de sair:

• Sincronização com o GitHub. O Lovable pode exportar e sincronizar nos dois sentidos o seu projeto com o GitHub, e a documentação indica suporte ao github.com em todos os planos. Ligue o GitHub no Lovable, e o seu código aterra num repositório que lhe pertence. Tenha em conta que o Lovable sincroniza um ramo de cada vez.
• Transferir a base de código. Nos planos pagos do Lovable pode transferir o código diretamente em Definições do projeto → Git.

Para uma migração, o GitHub é o melhor caminho: tem o histórico completo e pode continuar a sincronizar enquanto testa a nova configuração. Veja a documentação da integração com o GitHub do Lovable para os passos atuais.

Antes de sair do Lovable, abra o repositório e procure:

• Um ficheiro .env ou .env.example, que lista as variáveis de ambiente que a app espera
• Uma pasta supabase/, que pode conter migrações da base de dados e código de Edge Functions
• Os scripts do package.json, que mostram como a app é construída e executada

Passo 2: Decida o que fazer com o backend

Esta é a escolha que mais importa. As apps do Lovable costumam usar o Supabase para a base de dados e o início de sessão, quer através de um projeto Supabase que ligou por si próprio, quer através do Lovable Cloud.

Opção A: Manter o seu próprio projeto Supabase

Se a sua app já comunica com o seu próprio projeto Supabase, este é o caminho mais simples. O código da app continua a chamar o mesmo URL do Supabase com as mesmas chaves, por isso os seus dados, utilizadores e ficheiros ficam exatamente onde estão. Move apenas o frontend.

Opção B: Sair do Lovable Cloud

Se a sua app usa o Lovable Cloud, o Lovable documenta uma exportação da base de dados em Mais → Cloud → Visão geral → Definições avançadas. Segundo a documentação do Lovable (a partir de setembro de 2026):

• A exportação contém a base de dados completa, estrutura e dados, incluindo as contas de utilizador e os respetivos hashes de palavras-passe.
• Não inclui os ficheiros do armazenamento, o código das Edge Functions nem os segredos do projeto. As definições dos fornecedores de início de sessão também não estão incluídas.
• As exportações abrangem bases de dados até 15 GB, o ficheiro pode ter no máximo 5 GB, e pode pedir uma exportação a cada 24 horas.
• Não existe uma migração com um clique do Cloud para o Supabase, e os destinos suportados para mover o backend do Cloud são o Supabase gerido ou o Supabase auto-alojado.

Por isso, o caminho prático costuma ser: restaurar a exportação no seu próprio projeto Supabase, recriar os buckets de armazenamento, as Edge Functions e as definições de autenticação lá, e tratá-lo então como a Opção A. Veja as definições avançadas da documentação do Lovable para os detalhes.

Opção C: Mover tudo para a base de dados da Mythex

A Mythex pode atribuir a um projeto uma base de dados Postgres dedicada. Mover os dados para lá é possível, mas significa reescrever todos os sítios onde a app usa a biblioteca cliente do Supabase, e a Mythex não tem início de sessão incorporado para utilizadores finais, por isso também teria de ligar um fornecedor de autenticação separado. Isso é uma reconstrução real do backend, não uma migração. Faça-o mais tarde, se for mesmo necessário, quando a app já estiver a correr na Mythex com o Supabase.

Passo 3: Traga o código para a Mythex

Crie um projeto novo e vazio na Mythex. Depois, faça uma destas opções:

• Importar um arquivo. Abra Definições do projeto → Exportar → Importar para este projeto e envie um .zip, .tar.gz ou .tgz. O botão Download ZIP do GitHub dá-lhe um ficheiro que funciona aqui.
• Ligar o GitHub e puxar. Ligue o GitHub nas definições do projeto, associe o repositório e faça pull. A sincronização com o GitHub é uma funcionalidade do Pro.

A importação substitui os ficheiros do projeto, por isso use um projeto vazio. Quaisquer ficheiros .env no arquivo são removidos na importação, para que nenhum segredo entre por engano. Depois de uma importação bem-sucedida, a Mythex pode abrir um novo chat em que o agente instala as dependências, percebe como executar a app e coloca o Preview a funcionar. Pode orientar esse chat como qualquer outro. Os detalhes estão em Depois de importar.

Se o Preview não arrancar por si, peça:

Este projeto foi exportado do Lovable. É uma app React + TypeScript + Tailwind que usa Supabase. Instale as dependências, descubra o comando de desenvolvimento a partir do package.json e coloque o Preview a funcionar. Ainda não altere nenhum código da app.

Passo 4: Volte a adicionar os seus segredos

Abra Definições do projeto → Segredos e adicione cada valor de que a sua app precisa. Para uma app com Supabase, isso costuma significar o URL do projeto Supabase e a chave pública (anon ou publishable). Obtenha os nomes a partir do .env.example ou do sítio onde o código os lê.

Duas regras:

• Só as chaves públicas pertencem às variáveis do frontend. Numa app Vite, tudo o que tem o prefixo VITE_ fica incorporado no JavaScript que cada visitante descarrega.
• Nunca coloque a chave service role do Supabase no código do frontend. Se uma função do servidor precisar dela, fica no servidor.

Depois peça ao agente para confirmar que a app os lê:

Verifique quais variáveis de ambiente esta app lê. Liste as que ainda não estão definidas nos segredos do projeto, e não imprima os respetivos valores.

O nosso guia sobre variáveis de ambiente e segredos explica a diferença entre valores públicos e privados.

Passo 5: Teste antes de mudar fosse o que fosse

A sua app do Lovable continua no ar, por isso não há pressa. Teste a versão na Mythex no Preview com fluxos reais:

• Registar-se, iniciar sessão, terminar sessão e repor a palavra-passe
• Criar, editar e eliminar um registo
• Carregar um ficheiro, se a app o fizer
• Qualquer coisa que chame uma Edge Function ou uma API de terceiros

O Supabase tem uma definição fácil de deixar passar: os URLs de redirecionamento permitidos para os emails de início de sessão e de reposição de palavra-passe. Adicione lá os seus endereços de preview e publicados da Mythex, ou os inícios de sessão vão voltar ao domínio antigo.

O comando /test da Mythex faz com que o agente clique no seu preview como um utilizador e reporte os fluxos avariados. O nosso guia sobre como testar a sua app antes do lançamento tem uma lista de verificação mais completa.

Passo 6: Publique e mude o domínio

Quando tudo funcionar, publique a partir do workspace para obter um endereço <slug>.mythex.app. Teste novamente aí, porque a app publicada é um snapshot separado do seu projeto.

No Pro pode ligar o seu próprio domínio. Atualize os registos DNS no seu fornecedor de domínio, adicione o novo endereço aos URLs de redirecionamento permitidos do Supabase e só então desative a versão do Lovable. O nosso guia sobre como ligar um domínio personalizado cobre o DNS passo a passo.

Erros comuns

• Mover a base de dados e o frontend ao mesmo tempo. Mova primeiro o frontend, prove que funciona com o backend existente, e só depois decida sobre os dados.
• Esquecer as Edge Functions. Se a app chama Edge Functions do Supabase, ou ficam no Supabase ou têm de ser reescritas como código de servidor. Não correm dentro de um frontend Vite.
• Colocar a chave service role no frontend. Dá acesso total à sua base de dados a quem abrir as ferramentas de programador.
• URLs de redirecionamento de autenticação em falta. O início de sessão funciona no Preview e depois falha no domínio real.
• Mudar o DNS antes de testar o URL publicado. Teste primeiro o endereço mythex.ai; as alterações de DNS demoram a desfazer.
• Importar para um projeto que já tem trabalho. A importação substitui os ficheiros. Use um projeto novo.

Quando faz sentido ficar no Lovable

Seja honesto consigo próprio sobre o motivo da mudança. O Lovable oferece edições visuais ponto a ponto no preview e um backend como produto com o Lovable Cloud, e a Mythex não tem nenhuma delas. Se é isso que usa no dia a dia, mudar custa-lhe mais do que ganha. A Mythex encaixa melhor se quer um editor de código e um terminal reais ao lado do chat, um único saldo de créditos para construir e alojar, ou se quer usar uma stack diferente. O nosso guia de alternativas ao Lovable e a página Mythex vs Lovable comparam-nas com mais detalhe.

Lista de verificação da migração

• Listou todas as partes da app: código, base de dados, utilizadores, ficheiros, funções, segredos, domínio
• Código sincronizado com um repositório GitHub que lhe pertence
• Decisão sobre o backend tomada (manter o Supabase, ou exportar do Lovable Cloud)
• Código importado para um projeto Mythex vazio, com o Preview a funcionar
• Segredos adicionados novamente; nenhuma chave privada nas variáveis VITE_
• URLs de redirecionamento de autenticação atualizados para os novos endereços
• Registo, início de sessão, fluxos de dados principais e carregamentos testados no Preview
• Publicado e testado novamente no endereço mythex.ai
• DNS movido; versão antiga desativada só depois de confirmar a nova

Para o lado da Mythex, veja GitHub, exportação e importação na documentação.

Perguntas