> ## Documentation Index > Fetch the complete documentation index at: https://docs.replit.com/llms.txt > Use this file to discover all available pages before exploring further. # Copiar manualmente um projeto para outro workspace > Copie um app em produção para outro workspace ou conta manualmente: copie o código, configure o novo app, direcione seus usuários para ele com o mínimo de tempo de inatividade e saiba como desfazer isso Este guia mostra como copiar um app para outro workspace ou conta manualmente. Você copia o código, configura o novo app, copia seus dados e depois direciona seus usuários para o novo app. Nada é movido ou excluído. O projeto antigo permanece exatamente onde está, e as duas cópias não permanecem sincronizadas. Quando terminar, você escolhe se quer manter ou excluir o antigo. Procurando a transferência integrada em um clique? Veja [Transferir App para Equipes](/pt/teams/identity-and-access-management/transfer-app-to-teams). Use este guia quando essa opção não estiver disponível ou quando você precisar copiar entre contas. ## Antes de começar Você precisa de: * Acesso tanto ao projeto antigo quanto ao novo workspace ou conta. * Cerca de uma hora de tempo dedicado para a troca final. As etapas anteriores podem acontecer ao longo de vários dias. * Se seu app tiver um endereço web personalizado, acesso a onde você gerencia esse domínio. Duas coisas não são copiadas automaticamente e consomem a maior parte do tempo: seu **banco de dados** e seu **endereço web**. Este guia aborda ambos. Se o administrador do seu workspace ativou [Bloquear exportação de código-fonte](/pt/teams/enterprise-privacy-settings#ban-source-code-export), você não pode baixar o projeto como zip. Converse com o administrador do seu workspace antes de começar—ele pode confirmar se uma cópia manual é permitida e como mover o código e o banco de dados. ## Planeje o tempo de inatividade Pense nisso como abrir uma segunda loja e depois fechar a primeira. Há um curto período em que a loja antiga está fechada e a nova ainda não está aberta. Durante esse tempo, ninguém pode usar seu app. **Por quanto tempo o app fica offline?** Geralmente de 15 a 60 minutos. Depende de quantos dados seu banco de dados contém e da rapidez com que seu endereço web é atualizado. **Vou perder dados?** Só se alguém adicionar dados ao app antigo depois que você copiar o banco de dados. Para evitar isso, você tira o app antigo do ar *antes* de fazer a cópia final. Este guia está organizado para que isso aconteça. **Posso desfazer isso?** Sim. O projeto antigo não é excluído. Se algo der errado, publique o app antigo novamente e ele funcionará exatamente como antes. **Quando devo fazer isso?** Escolha um horário em que poucas pessoas usem seu app. Avise seus usuários com antecedência, se possível. ## Etapa 1: Copiar o código para um novo projeto Escolha um método. O app antigo permanece ativo durante esta etapa. Ambos os métodos transportam seu código. O GitHub sempre transporta seu histórico de commits, enquanto um zip transporta o histórico apenas quando inclui a pasta `.git`: | | Via GitHub | Via arquivo zip | | -------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | **Arquivos de código** | Somente arquivos que você commita e envia (push) | Tudo no disco, incluindo alterações não commitadas | | **Histórico de commits** | Histórico completo no remoto | Histórico completo se o zip incluir a pasta `.git`. Sem histórico se você excluir `.git` para ficar abaixo do limite de importação | | **Pastas de dependência** | Segue seu `.gitignore` | Excluídas (`node_modules`, `.venv`, `build` e similares); reinstaladas na importação | | **Requisitos** | Uma conta GitHub conectada a ambas as contas Replit | Nenhum | | **Sincronização contínua** | Ambas as cópias podem fazer push e pull no mesmo repositório | Nenhuma—cópia única | | **Ideal para** | Projetos que você quer manter em backup no Git a longo prazo | Cópias únicas e rápidas | ### Via GitHub No projeto antigo, abra o [painel Git](/pt/features/workspace-tools/git-interface), conecte um repositório GitHub e, em seguida, commite e envie (push). Use um repositório privado, a menos que você queira o código público. Se o novo workspace pertencer a uma conta Replit diferente, a conta GitHub dela precisa de acesso ao repositório. Para um repositório privado, adicione essa conta GitHub como colaboradora ou use uma organização GitHub compartilhada. Faça login na nova conta, abra [replit.com/import](https://replit.com/import), selecione **GitHub**, conecte a conta GitHub e escolha o repositório. Veja [Importar de um provedor](/pt/build/import-from-providers) para solução de problemas. Abra o novo projeto e confirme que os arquivos e o histórico de commits estão presentes. O Replit instala as dependências e configura os comandos de execução durante a importação. O GitHub recebe apenas o que você commita e envia. Arquivos correspondidos pelo `.gitignore` e alterações não commitadas ficam de fora. Nunca commite valores de secrets ou dumps de banco de dados no repositório. ### Via arquivo zip No projeto antigo, selecione o menu de três pontos no topo da árvore de arquivos e escolha **Baixar como zip**. Se o download funcionar e o arquivo tiver menos de 200 MB, pule para a próxima etapa. Um arquivo zip maior que 200 MB pode ser baixado com sucesso. No entanto, a [importação de ZIP](/pt/build/import-from-providers#limitations) rejeita arquivos acima de 200 MB, então o Replit não pode usá-lo para criar o novo projeto. Se o download falhar ou o zip tiver mais de 200 MB, crie um menor: 1. No projeto antigo, abra a ferramenta **Shell**. 2. Cole este comando e pressione Enter. Ele cria um arquivo chamado `project.zip` e deixa de fora pastas que o Replit pode reconstruir por conta própria: ```bash theme={null} zip -r project.zip . -x ".cache/*" "node_modules/*" ".venv/*" "venv/*" ".pythonlibs/*" "build/*" "target/*" ".next/*" "__pycache__/*" ``` 3. Verifique o tamanho. Cole este comando e pressione Enter. Ele exibe o tamanho em MB, como `150M` para 150 MB: ```bash theme={null} du -h project.zip ``` 4. Se o tamanho for maior que 200 MB, reduza o arquivo deixando de fora seu histórico de edições. Cole as duas linhas e pressione Enter: ```bash theme={null} rm project.zip zip -r project.zip . -x ".cache/*" ".local/*" ".git/*" "node_modules/*" ".venv/*" "venv/*" ".pythonlibs/*" "build/*" "target/*" ".next/*" "__pycache__/*" ``` Só exclua `.local` e `.git` quando precisar reduzir o zip para menos de 200 MB. Essas exclusões não excluem nenhuma das pastas do projeto antigo. No entanto, um zip sem `.git` não inclui o histórico de commits do projeto. Use o método do GitHub se precisar preservar o histórico. 5. Encontre `project.zip` na árvore de arquivos, selecione o menu de três pontos ao lado dele e selecione **Download**. A pasta `.cache` armazena estado interno do Replit, incluindo valores de secrets em cache. Sempre a exclua dos arquivos zip que você criar manualmente. Se seu projeto tiver outras pastas geradas grandes, adicione-as à lista de exclusão. Faça login na nova conta, abra [replit.com/import](https://replit.com/import), selecione **ZIP** e envie o arquivo. Abra o novo projeto e confirme que seus arquivos estão presentes. Se o zip incluir a pasta `.git`, seu histórico de commits veio junto. Se você usou o comando de arquivo menor, o novo projeto começa sem histórico de commits. O Replit reinstala as dependências excluídas durante a importação. ## Etapa 2: Configurar o novo app O app antigo ainda está ativo. Nesta etapa, você deixa o novo app totalmente funcional com uma *cópia de teste* dos seus dados, para que a troca final mais tarde seja rápida. Os valores de secrets (chaves de API, senhas) nunca saem do projeto antigo. Abra a ferramenta [Secrets](/pt/core-concepts/project-editor/app-setup/secrets) em ambos os projetos e copie cada um manualmente. Inclua quaisquer secrets de deployment. Reconecte cada integração em **Tools → Connectors** no novo projeto. Veja [Recrie o que não é copiado](#recrie-o-que-nao-e-copiado) para App Storage, colaboradores e todo o resto. [Publique](/pt/features/publishing/overview) o novo projeto. Ele recebe seu próprio endereço web `replit.app` e seu próprio banco de dados de produção vazio. Não conecte seu domínio personalizado ainda. Siga [Copiar o banco de dados](#copiar-o-banco-de-dados) abaixo, usando o banco de dados de **produção** no novo projeto como destino. Isso lhe dá dados reais para testar. A Etapa 3 substitui esta cópia pelos seus dados mais recentes. Abra o novo app no endereço `replit.app` e use-o da forma que seus usuários usariam. Corrija qualquer coisa que esteja quebrada antes de continuar. Seus usuários ainda não foram afetados. ## Etapa 3: Direcionar seus usuários para o novo app Esta é a parte com tempo de inatividade. Faça-a em uma única sessão. No projeto antigo, abra a ferramenta **Publishing** e selecione **Unpublish**. Seu app agora está offline. Ninguém pode adicionar novos dados a partir deste ponto, então a cópia que você fará a seguir estará completa. Siga [Copiar o banco de dados](#copiar-o-banco-de-dados) abaixo, usando o banco de dados de **produção** no novo projeto como destino. Esta cópia tem todos os seus dados mais recentes. Se seu app usa um domínio personalizado: no projeto antigo, abra **Publishing → Domains** e desconecte o domínio. No novo projeto, abra **Publishing → Domains** e [conecte-o](/pt/features/publishing/custom-domains#connect-a-domain-you-already-own). Atualize os registros no seu provedor de domínio (por exemplo, GoDaddy ou Namecheap) se o Replit solicitar. O novo endereço pode levar de alguns minutos a algumas horas para funcionar para todos. Até então, alguns visitantes podem ver um erro. Se seu app usa apenas um endereço `replit.app`, compartilhe o novo endereço com seus usuários. Abra seu endereço web e confirme que o novo app carrega com seus dados. Seu app está online novamente. ## Copiar o banco de dados A cópia do código não afeta seu banco de dados. Copie os dados com as ferramentas `pg_dump` e `pg_restore` do PostgreSQL, disponíveis no Shell de ambos os projetos. Tanto a Etapa 2 quanto a Etapa 3 apontam para aqui. Os comandos são os mesmos a cada vez. Somente o *destino* muda. Dados escritos depois que você executa `pg_dump` não entram na cópia. Para a cópia final na Etapa 3, tire o app antigo do ar primeiro. Abra a ferramenta **Shell** no projeto antigo. Cole este comando e pressione Enter. Ele cria um arquivo chamado `backup.dump` na sua árvore de arquivos: ```bash theme={null} pg_dump -Fc "$DATABASE_URL" --no-owner --no-privileges -f backup.dump ``` Isso exporta o banco de dados de **desenvolvimento**. Seus dados em produção geralmente estão no banco de dados de **produção**. Para exportar esse: 1. Abra a ferramenta **Database**, selecione o banco de dados de produção e abra **Settings**. 2. Copie a string de conexão. 3. No comando acima, substitua `"$DATABASE_URL"` pela string de conexão, mantendo as aspas. Veja [Detalhes de conexão](/pt/features/data-and-storage/connection-details) se você não conseguir encontrá-la. Na árvore de arquivos do projeto antigo, selecione o menu de três pontos ao lado de `backup.dump` e faça o download. Depois envie-o para o novo projeto com a opção **Upload files** da árvore de arquivos. Se você copiou o código pelo GitHub, não commite o dump. Mova-o separadamente para que seus dados nunca cheguem ao repositório. Abra a ferramenta **Shell** no novo projeto. Cole este comando e pressione Enter: ```bash theme={null} pg_restore --clean --if-exists --single-transaction --no-owner --no-privileges --exit-on-error -d "$DATABASE_URL" backup.dump ``` Como está escrito, isso importa para o banco de dados de **desenvolvimento** do novo projeto. Isso é o que você quer na Etapa 2. Para a cópia final na Etapa 3, você quer o banco de dados de **produção** em vez disso. No novo projeto, abra a ferramenta **Database**, selecione o banco de dados de produção, abra **Settings**, copie a string de conexão e use-a no lugar de `"$DATABASE_URL"`. Isso descarta quaisquer objetos correspondentes no banco de dados de destino e depois carrega os dados. Quando terminar sem saída, funcionou. Se `pg_restore` falhar com erros de role ou de política, seu banco de dados usa roles personalizadas do PostgreSQL que ainda não existem no novo projeto. [Entre em contato com o suporte](https://replit.com/support) para obter ajuda. Se o novo projeto usar um [banco de dados de desenvolvimento legado do Neon](/pt/features/data-and-storage/development-and-production#legacy-development-database), o fluxo de publicação oferece **Set up your production database with your current development data**. Isso copia o que estiver no banco de dados de desenvolvimento no momento em que você publica. É adequado para testes, mas para a troca final use as etapas acima para obter os dados mais recentes. ## Recrie o que não é copiado O restante da configuração do projeto vive fora do sistema de arquivos. Recrie cada parte no novo projeto: | Item | O que fazer | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Secrets** | Os valores de secrets nunca saem do projeto antigo. Adicione-os novamente na ferramenta [Secrets](/pt/core-concepts/project-editor/app-setup/secrets) do novo projeto, incluindo os secrets de deployment. | | **Account Secrets** | [Vincule-os](/pt/core-concepts/project-editor/app-setup/secrets#manage-account-secrets) no novo projeto. Se o novo projeto estiver em uma conta diferente, adicione-os a essa conta primeiro. | | **App Storage** | Os buckets não são movidos. Dentro da mesma conta, [adicione o bucket existente](/pt/features/data-and-storage/object-storage#bucket-access-management) ao novo projeto. Entre contas diferentes, baixe os objetos e envie-os para um novo bucket. | | **Conectores** | Reconecte cada integração em **Tools → Connectors** no novo projeto. Veja a [visão geral de integrações](/pt/features/integrations/overview). | | **Deployments** | A cópia não está publicada. [Publique-a](/pt/features/publishing/overview) a partir do novo workspace, como na [Etapa 2](#etapa-2-configurar-o-novo-app). | | **Domínios personalizados** | Remova o domínio do deployment antigo, vincule-o ao novo e atualize seus registros DNS. Abordado na [Etapa 3](#etapa-3-direcionar-seus-usuarios-para-o-novo-app). | | **Colaboradores** | Convide os colaboradores novamente e configure o [acesso](/pt/teams/identity-and-access-management/groups-and-permissions) no novo workspace. | | **Histórico do Agent** | As conversas do Agent e as reversões de [checkpoint](/pt/features/version-control/checkpoints-and-rollbacks) permanecem com o projeto antigo. Os commits de checkpoint viajam com seu histórico do Git, mas você não pode revertê-los a partir da cópia. | ## Se algo der errado O projeto antigo ainda está lá. Para voltar atrás: 1. No projeto antigo, abra a ferramenta **Publishing** e selecione **Publish**. 2. Se você moveu um domínio personalizado, mova-o de volta da mesma forma. Seu app está no ar novamente com os dados que tinha quando você o tirou do ar. Nada foi perdido. ## Limpeza Espere cerca de uma semana para ter certeza de que o novo app está funcionando. Depois: * Remova `backup.dump` de ambos os projetos e do seu dispositivo. Cada cópia contém uma exportação completa dos seus dados. * Opcionalmente, exclua o projeto antigo. ## Recursos relacionados * [Transferir App para Equipes](/pt/teams/identity-and-access-management/transfer-app-to-teams): A transferência integrada para mover um projeto para dentro ou entre workspaces de equipe * [Importar de um provedor](/pt/build/import-from-providers): Todas as fontes de importação suportadas * [Corrigir um app publicado usando um banco de dados compartilhado](/pt/features/data-and-storage/shared-database-migration): Mais solução de problemas de `pg_dump` e `pg_restore`