Como tirar meu app do Replit e hospedar fora
Para tirar o app do Replit, baixe o código pelo Download as zip ou pelo Git, exporte o banco de produção com pg_dump, recrie os Secrets e rode o app num servidor seu com os comandos do arquivo .replit. Depois, mova o domínio. O código sai fácil; banco, login e arquivos pedem cuidado.
Recomendação da Heartscale: faça o pg_dump do banco de produção com o app fora do ar e restaure primeiro num banco vazio, para conferir os dados antes da virada. Se o app usa Replit Auth, App Storage ou Connectors, resolva cada um antes de mover o domínio; com usuários reais, peça uma revisão do plano antes de começar.
Antes de começar: o que sai e o que fica
O Replit descreve a cópia manual de um app em Manually copy a project to another workspace. O guia é para outra conta do Replit, mas mostra o que não vai junto com o código. Fora do Replit, a lista é a mesma e cresce um pouco:
| Parte | Onde fica no Replit | Como sai |
|---|---|---|
| Código | Arquivos do projeto | Download as zip ou Git |
| Banco | PostgreSQL de desenvolvimento e de produção | pg_dump e pg_restore |
| Secrets | Secrets do editor e do deploy, separados | Recriados à mão |
| Arquivos enviados | App Storage (Google Cloud Storage) | Download dos objetos |
| Login | Replit Auth ou Clerk | Troca planejada |
| Integrações | Tools → Connectors | Substituídas por integrações suas |
| Domínio | Publishing → Domains | Troca de DNS ou transferência |
Se o app está num workspace de equipe, confira antes com o administrador. Com a opção Ban source code export ligada, o download do zip fica bloqueado.
Passo 1: pegue o código
Download as zip (Projects and files): abra o menu de três pontos no topo da árvore de arquivos e escolha Download as zip. Se falhar, abra o Shell e rode:
zip -r project.zip .
Projetos acima de 200 MB pedem um arquivo menor. A doc sugere excluir pastas que se recriam:
zip -r project.zip . -x ".cache/*" "node_modules/*" ".venv/*" "venv/*" ".pythonlibs/*" "build/*" "target/*" ".next/*" "__pycache__/*"
Não inclua a pasta .cache num zip manual. Segundo a doc, ela guarda valores de Secrets em cache.
Git: ligue sua conta do GitHub nos serviços conectados da conta, abra a ferramenta Git no projeto e conecte o repositório. O auto-sync do painel Git sincroniza nos dois sentidos, e um token de acesso pessoal fine-grained deixa a conexão mais estável. Lembre que o GitHub recebe só os arquivos com commit: arquivos ignorados e mudanças sem commit ficam para trás.
Prefira o Git. Ele guarda o histórico e permite deploy a cada push no servidor novo.
Passo 2: descubra como o app roda
O arquivo .replit controla o comportamento do app e fica oculto por padrão (Replit App Configuration). Ele está em formato TOML. Procure três coisas:
run: o comando do botão Run.- A seção
[deployment]:buildroda antes do deploy eruninicia o app publicado. São esses os comandos que o servidor novo vai usar. [[ports]]:localPorté a porta em que o app escuta.
O replit.nix lista os pacotes do sistema que o projeto usa, no array deps. Instale os equivalentes no servidor novo.
O tipo de deploy também diz muito (Publishing). Static serve um site que não muda conforme o usuário. Autoscale e Reserved VM rodam um servidor. Scheduled roda o app em horários marcados e vira uma tarefa agendada no servidor novo.
Passo 3: exporte o banco de produção
O Replit separa o banco de desenvolvimento do banco de produção, que atende o app publicado (Development and production databases). Os dados reais estão no de produção. O $DATABASE_URL do Shell aponta para o de desenvolvimento.
Para pegar a string de produção (Connection details): no painel Tools, abra Database, selecione Production Database e abra a aba Settings. O banco de produção aceita conexão de qualquer cliente compatível com PostgreSQL. O de desenvolvimento não aceita conexões externas.
Tire o app do ar antes da cópia final: o que for gravado depois do pg_dump não entra no arquivo. O comando da doc:
pg_dump -Fc "STRING_DE_PRODUCAO" --no-owner --no-privileges -f backup.dump
No destino, um PostgreSQL seu, gerenciado ou numa VPS, a doc restaura assim:
pg_restore --clean --if-exists --single-transaction --no-owner --no-privileges --exit-on-error -d "STRING_DO_BANCO_NOVO" backup.dump
O --clean apaga no destino os objetos com o mesmo nome antes de carregar. Rode num banco novo e vazio. Sem saída na tela, a restauração deu certo. Na nossa revisão, comparamos a contagem de linhas de cada tabela entre o banco do Replit e o banco novo antes de liberar a virada.
O backup.dump tem os dados dos usuários. Nunca faça commit dele num repositório. Guarde em lugar seguro e apague as cópias soltas depois.
Passo 4: recrie os Secrets
Os Secrets ficam em + na barra de abas do editor → Secrets (Add secrets). O Replit guarda os de desenvolvimento e os de deploy em lugares separados (Deployment and publishing). Confira os dois, porque os valores do app publicado podem ser outros.
Os valores não vão junto na cópia. Liste o nome de cada Secret, inclusive os Account Secrets ligados ao projeto, e recrie como variável de ambiente no servidor novo. A string do banco novo entra no lugar da antiga, no mesmo nome que o código lê, em geral DATABASE_URL.
Passo 5: leve os arquivos e troque as integrações
O App Storage roda sobre o Google Cloud Storage (App Storage). Para baixar, abra a aba App Storage, vá em Objects e use o ícone de download ao lado de cada arquivo. As bibliotecas oficiais do Replit se autenticam sozinhas dentro do Replit. A doc não diz se o bucket responde de fora. Planeje, então, um storage seu e ajuste o código que lê e grava arquivos.
As integrações de Tools → Connectors precisam ser religadas até numa cópia dentro do Replit. Fora dele, troque cada uma por uma integração sua, com chaves suas.
Passo 6: resolva o login
O Replit Auth usa o login e a infraestrutura do Replit, e os usuários entram com conta do Replit (Replit Auth). A doc não diz se ele funciona com o app hospedado fora. Trate como dependência e resolva antes da virada.
O Replit oferece uma migração do Replit Auth para o Clerk, feita pelo Agent, que leva os dados de identidade dos usuários (Migrate from Replit Auth to Clerk). O tenant do Clerk criado assim é gerenciado pelo Replit. Também é possível ligar um app do Clerk seu, mas a doc avisa que apagar o app gerenciado remove o tenant dele (Clerk Auth). Teste o login com usuários reais numa cópia antes de apagar qualquer coisa.
Passo 7: suba no servidor novo
Com os comandos do passo 2, o caminho é o de qualquer app Node ou Python: instale as dependências, rode o build, inicie com o run atrás de um proxy reverso com HTTPS. Se preferir um painel, o Coolify instala numa VPS Linux com pelo menos 2 núcleos e 2 GB de RAM e faz deploy a partir do GitHub.
Para um deploy Static, basta servir os arquivos gerados no build.
Passo 8: teste antes de virar
- Abra rotas internas direto pelo endereço e recarregue.
- Entre e saia com um usuário real.
- Leia, grave e envie um arquivo.
- Confira se cada integração responde com as chaves novas.
- Se havia deploy Scheduled, veja se a tarefa roda uma vez só, no servidor novo.
Passo 9: mova o domínio
Domínio de outro registrador. No Replit, ele usa um registro A e um TXT, configurados em Publishing → Domains (Custom domains and DNS). Na virada, desconecte o domínio do app no Replit e aponte o registro A no seu provedor para o servidor novo.
Domínio comprado pelo Replit. A transferência para outro registrador é feita pelo suporte do Replit, depois dos 60 dias de espera da ICANN (Domain purchasing). Enquanto isso, você pode editar o DNS em Tools → Domains → Replit Cloud, que aceita registros A, TXT e MX. A renovação automática tem um botão próprio, Auto renewal.
Passo 10: encerre no Replit
- Em Publishing, use Unpublish. O app sai do ar e para de gerar cobrança de deploy, mas arquivos, código e banco continuam lá (Deployment and publishing).
- Se algo der errado, Publish no projeto antigo devolve o app com os dados do momento em que saiu do ar.
- Depois de conferir o banco novo, remova o antigo em Database → Settings → Remove database. Há 7 dias para recuperar com o suporte; depois disso, não tem volta.
Quanto tempo leva
A doc do Replit prevê de 15 a 60 minutos de app fora do ar na virada, numa cópia entre contas. Fora do Replit, some o tempo de trocar login, storage e integrações. Os passos são parecidos com os de tirar o app do Bolt e de sair do Lovable. Veja também o serviço de migração de plataforma.
Fazer sozinho ou contratar?
Este guia basta quando o app é simples; a tabela mostra quando vale ter uma equipe ao lado.
| Situação | Caminho |
|---|---|
| Deploy Static ou app sem banco, e alguém no time que sobe um servidor Node ou Python | Faça sozinho com este guia |
| Banco de produção com dados de usuários reais | Chame uma equipe para o pg_dump, a restauração e a conferência na virada |
| Replit Auth, App Storage ou Connectors no app | Peça o diagnóstico da Heartscale: ele lista cada dependência e os riscos da virada |
| Prazo curto ou ninguém técnico no time | Contrate a migração com preço fechado |
Peça o diagnóstico da Heartscale
Nossa equipe mapeia o que o seu app usa do Replit: banco de produção, Secrets, App Storage, Replit Auth e Connectors. Você recebe o plano de migração, os riscos da virada e o preço fechado.
O diagnóstico de lançamento custa R$ 99 (de R$ 398) e é abatido se você fechar a migração. Só trabalhamos em app de quem prova ser dono.