Como Exportar e Auto-Alojar uma App Criada com IA

Para auto-alojar uma app criada com IA, tire o código (um descarregamento ou uma sincronização com um repositório GitHub que seja seu), recrie os segredos como variáveis de ambiente, mova ou recrie a base de dados e publique-a num alojamento que corresponda ao que a app é: um alojamento estático para uma interface simples, ou uma plataforma que execute servidores ou contentores para tudo o que tenha um back end. O código costuma ser a parte fácil. Os dados, os segredos e os serviços que o construtor executava discretamente por si é que dão trabalho.

Porque exportar, afinal

Há boas razões para levar o seu código consigo, e algumas menos boas.

Boas razões:

• Propriedade e seguro. Uma cópia do código no seu próprio repositório protege-o se o construtor mudar os preços, as funcionalidades ou os termos.
• Passagem para programadores. Uma equipa de engenharia vai querer o código em Git, nas suas ferramentas habituais e no seu processo de revisão.
• Requisitos específicos. Residência de dados, um fornecedor de cloud em particular, políticas de segurança da empresa ou uma infraestrutura que o construtor não oferece.
• Escala ou custo a um tamanho em que gerir a sua própria infraestrutura compensa de facto.

Razões menos boas: mudar uma app pequena, com meia dúzia de utilizadores, para poupar um pequeno valor mensal. O auto-alojamento transfere trabalho para si — atualizações, cópias de segurança, monitorização, correções de segurança. Pode ser a troca certa; faça-a apenas de forma consciente.

Um meio-termo sensato: continue a construir e a alojar onde está, mas sincronize com o seu próprio repositório GitHub desde o início. Fica com o seguro sem o trabalho operacional. Se o Git lhe for novo, leia o que é o GitHub.

O que uma exportação contém e não contém

Antes de confiar numa exportação, abra-a e verifique. Normalmente:

Os segredos ficam de fora de propósito — um arquivo que possa enviar por email ou submeter ao repositório nunca deve conter chaves ativas. As dependências ficam de fora porque são reconstruídas a partir do ficheiro de lock.

Passo 1: tire o código

Duas formas comuns:

• Descarregue um arquivo do projeto. Rápido, e adequado para uma mudança pontual ou uma cópia de segurança.
• Sincronize com o GitHub. Melhor para tudo o que é contínuo: histórico completo, fácil de clonar em qualquer lado, e a maioria dos alojamentos publica diretamente a partir de um repositório GitHub a cada envio.

Em qualquer dos casos, clone ou descompacte num computador (ou num ambiente de desenvolvimento na cloud) e procure um README. Se não existir, peça à IA no construtor que escreva um antes de sair:

Escreva um README para correr este projeto fora desta plataforma: a stack, as versões de runtime necessárias, os comandos de instalação e de build, o comando de arranque e a porta, cada variável de ambiente que o código lê (nomes e finalidade, sem valores) e como se executam as migrações da base de dados.

Este pedido poupa horas, porque obriga a passar para o texto as partes implícitas da configuração.

Passo 2: corra primeiro localmente

Antes de publicar em qualquer lado, prove que a app corre sozinha:

1. Instale o runtime indicado no README — Node.js, Python, Java, .NET — numa versão compatível.
2. Instale as dependências (npm install, pnpm install, pip install -r requirements.txt, ou o equivalente).
3. Crie um ficheiro .env local com as variáveis de ambiente, usando chaves de teste sempre que possível. Mantenha-o fora do Git. O que são variáveis de ambiente e segredos explica a ideia.
4. Aponte para uma base de dados — um Postgres local, ou uma base de dados de desenvolvimento gratuita de um fornecedor gerido.
5. Execute as migrações, depois arranque a app e percorra os fluxos principais.

Tudo o que falhar aqui também falhará num alojamento, e é muito mais fácil depurar na sua própria máquina. Surpresas comuns: um URL fixo no código da pré-visualização do construtor, uma variável de ambiente em falta que o construtor injetava automaticamente, ou um serviço (armazenamento de ficheiros, redimensionamento de imagens) que só existia na plataforma.

Passo 3: mova os dados

Se a app tiver utilizadores reais, os dados importam mais do que o código.

• Exporte a base de dados. Para Postgres, o pg_dump produz um ficheiro que pode restaurar com pg_restore ou psql na nova base de dados. Peça à IA do construtor que o execute se não tiver acesso direto, e que explique o que produziu.
• Mova os ficheiros carregados. Se os utilizadores carregaram imagens ou documentos, estão num armazenamento de objetos separado da base de dados. Copie-os para o seu novo armazenamento (por exemplo, um bucket compatível com S3) e atualize os URLs guardados se incluírem o antigo domínio.
• Planeie a transição. Para uma app em produção, a abordagem simples é uma janela curta de manutenção: parar as escritas, fazer uma última exportação, restaurá-la no novo alojamento, mudar o DNS e reabrir. Escreva primeiro cada passo.
• Teste uma restauração numa base de dados de teste antes da mudança real.

Se o Postgres lhe for desconhecido, o que é o Postgres explica o essencial.

Passo 4: escolha onde a alojar

Adapte o alojamento ao que a app é. Os nomes abaixo são exemplos de fornecedores conhecidos em cada categoria a setembro de 2026, não um ranking; confirme as funcionalidades e os preços atuais nos respetivos sites.

Vai também precisar de:

• Uma base de dados gerida — muitos alojamentos de apps oferecem Postgres, e serviços dedicados como Neon ou Supabase fornecem-no de forma autónoma. Vale a pena usar um serviço gerido: as cópias de segurança e as atualizações ficam a cargo de outra pessoa.
• Armazenamento de objetos para carregamentos, se a app os tiver.
• Envio de emails, pagamentos e fornecedores de IA — normalmente basta definir as mesmas chaves de API no novo alojamento.

Sendo justos quanto aos compromissos: os alojamentos de plataforma (as primeiras quatro linhas) são mais rápidos de configurar e manter, mas tem menos controlo e os custos podem subir com o tráfego. Um servidor virtual costuma ser mais barato com carga constante e fica totalmente sob o seu controlo, mas fica consigo a aplicação de correções, o TLS, as cópias de segurança, a monitorização e a recuperação. Se ninguém da equipa quiser essa tarefa, escolha uma plataforma. Para as bases do que envolve o alojamento web, veja o que é o alojamento web.

Passo 5: publique e mude

1. Ligue o repositório ao alojamento, ou envie uma imagem de contentor.
2. Defina as variáveis de ambiente no painel do alojamento — todas as que estão no README, com valores reais.
3. Defina os comandos de build e de arranque e a porta. Muitos alojamentos passam a porta numa variável de ambiente PORT; a app deve escutar nessa porta e em todas as interfaces (0.0.0.0), e não apenas em localhost.
4. Execute as migrações na nova base de dados.
5. Teste no URL temporário do alojamento antes de mexer no DNS.
6. Atualize os serviços externos que apontam para o seu URL antigo: webhooks de pagamento, URLs de redirecionamento OAuth para o início de sessão, links de email, origens permitidas.
7. Mude o domínio atualizando os registos DNS para o novo alojamento. Como ligar um domínio personalizado explica os registos.
8. Mantenha a implementação antiga a funcionar durante algum tempo até ter a certeza, e depois desative-a.

O passo 6 é o que mais se esquece: os inícios de sessão e os pagamentos que falham em silêncio depois de uma mudança costumam dever-se a um URL de callback que ainda aponta para o antigo alojamento.

Passo 6: assuma as operações

Depois de auto-alojar, as tarefas que o construtor tratava passam a ser suas. No mínimo: cópias de segurança automáticas da base de dados com uma restauração testada, registo de erros, alertas de disponibilidade, atualizações de dependências e uma nota de quem tem acesso a cada conta. Como levar um protótipo de IA para produção percorre esta lista com mais detalhe.

Lista de verificação da exportação

• Código num repositório que seja seu, com um README que cubra execução, build e variáveis de ambiente
• A app corre localmente a partir de um clone limpo
• Base de dados exportada e restauração testada; ficheiros carregados copiados
• Alojamento escolhido para o tipo de app, com base de dados e armazenamento geridos
• Todas as variáveis de ambiente definidas com valores reais no novo alojamento
• Webhooks, redirecionamentos OAuth e links de email atualizados
• DNS mudado, implementação antiga mantida durante algum tempo e depois removida
• Cópias de segurança, monitorização e lista de acessos em funcionamento

Exportar a partir da Mythex

Na Mythex é dono do código que cria. No plano Pro pode descarregar o projeto como arquivo em Definições do projeto → Exportar, ou ligar o GitHub e enviar e obter alterações do seu próprio repositório; os planos gratuitos podem ver o código apenas em modo de leitura, mas não exportá-lo nem sincronizá-lo. Os segredos e a pasta node_modules ficam de fora das exportações, por isso recrie os seus segredos no novo alojamento. A documentação cobre os passos em exportar e executar noutro lado e em GitHub, exportação e importação. Também pode continuar a alojar na Mythex e usar a sincronização com o GitHub apenas como a sua cópia própria e via de passagem; se mudar, desative a app na Mythex depois de o novo alojamento estar ativo.

Perguntas