Está vindo de outro host para o Server Manager? O assistente Importar de outro host acessa seu servidor antigo, procura sites WordPress, sites estáticos e bancos de dados, e depois copia um deles como um pacote .tar.gz. Em seguida, o pacote entra no assistente de restauração, que faz a instalação de fato neste servidor, com sua aprovação em cada etapa.
A origem é somente leitura. Nada no seu host antigo é modificado. O assistente verifica, copia o que precisa e desconecta. Você pode executá-lo de novo depois para migrar outro site.
O que posso migrar?
O assistente reconhece três tipos de "coisa para mover":
| Tipo | O que ele encontra | O que fica aqui |
|---|---|---|
| Site WordPress | Um wp-config.php + banco de dados acessível (preenche credenciais automaticamente quando consegue ler) | Instalação completa do WordPress em contêiner, com um banco de dados novo, e suas mídias + plugins + temas restaurados |
| Site estático | Uma raiz de documentos com index.html (em /var/www/, /home/<user>/public_html/, layouts comuns do cPanel…) | A árvore de arquivos em /var/www/<your-new-domain>/, servida pelo Caddy |
| Banco de dados | Uma instância MySQL / MariaDB acessível pelo login SSH da origem | Um novo contêiner de banco de dados com uma cópia restaurada via mysqldump |
Ele não migra: aplicativos web arbitrários (frameworks Node/Python/PHP além de WordPress — para isso, use Implantar a partir de um repositório git), email/caixas de correio, registros DNS ou qualquer coisa fora das convenções padrão de webroot/banco de dados.
Como acessar seu host antigo — SSH ou cPanel
O assistente aceita duas formas de conexão:
| Tipo de origem | Quando escolher |
|---|---|
| Login SSH | Você tem acesso ao shell (o mesmo login que usaria com o comando ssh). A maioria dos provedores de servidores oferece isso por padrão. |
| API do cPanel | Você só tem cPanel e não tem SSH (comum em hospedagem compartilhada). Usa o token de API do próprio cPanel em vez de um login Linux. |
Se não tiver certeza, tente SSH primeiro — é o caminho com menos atrito. Troque de aba se a conexão falhar ou se o seu host só oferecer cPanel.
Passo a passo
Barra superior → menu → Importar de outro host.
Escolha o tipo de origem, preencha as credenciais e clique em Escanear a origem.
O modo Login SSH pede: host (IP ou domínio do servidor antigo), porta (geralmente 22), nome de usuário (root, ubuntu, seu usuário do cPanel etc.) e uma senha ou uma chave privada OpenSSH. Já salvou essas mesmas credenciais como um servidor no Server Manager? Clique em Usar credenciais de um servidor salvo para preencher automaticamente a partir dele.
O modo API do cPanel pede: a URL completa do cPanel (incluindo a porta — geralmente https://your-domain:2083), seu nome de usuário do cPanel e um token de API. Pegue o token no cPanel → pesquise por "Manage API Tokens" → Create — o cPanel só mostra o token uma vez, então copie e cole imediatamente.
O que o assistente faz com as credenciais. Elas ficam somente nesta sessão do navegador e são enviadas por HTTPS diretamente para a origem. Não gravamos essas credenciais em disco neste servidor nem as armazenamos entre execuções do assistente.
O assistente acessa a origem e percorre caminhos comuns de web/banco de dados por cerca de 10–30 segundos, agrupando por tipo tudo o que reconhecer.
Escolha um item para migrar nesta execução (ainda não existe seleção múltipla — reabra o assistente para o próximo). O cartão selecionado fica com um contorno pêssego.
Se o escaneamento não retornar nada, o assistente informa quais raízes verificou + eventuais avisos (erros de permissão, wp-config ilegível etc.). Ajuste as credenciais da origem ou a organização dos caminhos se o item ausente estiver em uma raiz fora do padrão.
Esta etapa varia conforme o tipo:
- WordPress → escolha o domínio onde o site migrado será hospedado (pode ser o mesmo de antes — você troca o DNS depois — ou um domínio totalmente novo) e confirme as credenciais do banco de dados (preenchidas a partir de
wp-config.phpse ele for legível). - Site estático → opcionalmente, escolha um domínio. Deixe em branco para servir pelo IP do servidor por enquanto; você pode vincular um domínio depois pelo painel do serviço.
- Banco de dados → escolha um título para o novo banco de dados neste servidor e, raramente, sobrescreva as credenciais do
mysqldump.
Clique em Iniciar a importação.
O Server Manager puxa os dados da origem e monta neste servidor um pacote no formato do Server Manager. As linhas de progresso são atualizadas em tempo real (criando arquivo, transferindo, calculando hash etc.). No lado da origem, são apenas leituras — sem gravações e sem arquivos temporários deixados para trás.
Não feche a janela durante a importação. Se fizer isso, a transferência em andamento será abortada e você precisará reiniciar. A limpeza acontece automaticamente — arquivos parciais em /tmp/helm-restore/ neste servidor são limpos em até 24 horas, ou você pode limpá-los imediatamente pela tela de erro se algo falhar.Quando o pacote é montado, o modal de migração fecha e o assistente de restauração abre com o pacote recém-chegado já selecionado. É o mesmo modal usado no fluxo Mover para outro servidor quando o pacote chega, com o mesmo botão de um clique Restaurar este pacote.
Clique em Restaurar este pacote e o chat assume: o Faro lê o manifest, inicia a instalação neste servidor e pausa para você aprovar cada comando — docker compose up, a edição do Caddyfile, o wp search-replace caso o domínio tenha mudado etc.
Ao terminar, o site migrado aparece como um cartão de workload na sua tela inicial — igual a qualquer outro que você tenha implantado nativamente aqui.
Se você usou um domínio novo para o destino, pronto — o Caddy emite um certificado TLS para ele em cerca de 30s e o site fica no ar.
Se você usou o mesmo domínio do host antigo, a migração rodou contra o IP do seu servidor antigo. Para redirecionar o tráfego, atualize o registro A no seu provedor de DNS para apontar para este servidor. Dentro do tempo de propagação do DNS (geralmente 1–10 min), o tráfego passa para a cópia migrada e o Caddy renova o certificado automaticamente no novo IP. A instalação antiga na origem continua servindo o mesmo domínio até o DNS propagar; você pode desligá-la na origem quando estiver satisfeito com a migração.
Aviso sobre DNS na tela de conclusão. O assistente mostra um alerta se o domínio de destino ainda não estiver apontando para cá — o Caddy não consegue obter um certificado HTTPS até o DNS propagar. A etapa de restauração também para e avisa se o DNS ainda não estiver configurado.
Perguntas comuns
Meu site vai ficar fora do ar durante a migração? Não — a origem continua servindo tráfego o tempo todo. A migração apenas copia. Você só tem indisponibilidade no momento em que troca o DNS (ou nunca, se estiver usando um domínio novo no novo servidor).
E plugins / temas / código personalizado no WordPress? Vão junto. A migração captura os arquivos do WordPress (temas, plugins, uploads) E o banco de dados em um snapshot consistente. Depois da restauração, o site se comporta da mesma forma — mesmo conteúdo, mesmas URLs (ou URLs reescritas se você escolheu um domínio diferente).
Meu banco de dados é maior que o espaço livre em disco na origem. Não vai funcionar do jeito que está — o mysqldump precisa, por um breve período, de espaço temporário na origem equivalente ao tamanho do dump. Libere espaço na origem primeiro ou migre manualmente por dumps SQL (baixe o dump → envie para cá via Restaurar de um backup).
Posso migrar de algo além de SSH/cPanel? Hoje, não — a lógica de escaneamento/sondagem só conhece esses dois shells. Para outros painéis (Plesk, DirectAdmin etc.), o caminho é: acesse a origem manualmente por SSH, use tar no seu webroot, use mysqldump no seu banco de dados, empacote tudo em um .tar.gz que corresponda ao layout de pacote de backup e importe via Restaurar de um backup. Se você precisar da especificação exata do formato do pacote para montar um manualmente, peça via Contato e nós compartilhamos.
E se a migração falhar no meio? A tela de erro oferece um botão Limpar agora de um clique, que remove todos os diretórios de staging gravados parcialmente em /tmp/helm-restore/. Do lado da origem, nada foi modificado. É seguro executar o assistente de novo desde o início.
Isso sobrescreve um site existente neste destino? Só se você aceitar isso explicitamente na etapa de restauração. O padrão na passagem para o chat é instalar lado a lado — você escolheria "clonar para novo domínio" (ou, para bancos de dados, "clonar ao lado" com um sufixo) se já houver um workload no domínio de destino.
Algo fica na origem depois da migração? Nenhum artefato adicionado por nós. O assistente faz apenas chamadas de leitura; a única coisa que grava na origem é o mysqldump (em migrações de WordPress + banco de dados), que produz um arquivo que o assistente baixa e apaga imediatamente. Depois que o assistente desconecta, a origem fica no mesmo estado de antes.
Segredos — eles são reutilizados ou rotacionados? A senha do banco de dados em wp-config.php é usada para executar o mysqldump na origem e depois descartada. O site restaurado sobe com credenciais de banco de dados novas geradas na passagem para o chat — nenhuma credencial da origem vaza para a nova instalação.
O que NÃO está no escopo aqui
- Restauração de pacote para pacote (você já tem um
.tar.gzexportado de outro lugar) → veja diretamente Restaurar de um backup. - Movimentação de servidor para servidor dentro do Server Manager (origem + destino são gerenciados pelo Helm) → veja Backups → Mover para outro servidor. Esse caminho é mais eficiente: sem etapa de sondagem, sem reconstrução de manifest.
- Troca de engine (você usa nginx/Apache e quer Caddy aqui) → veja Migrar para Caddy. É outro problema; esse fluxo reescreve configurações no lugar, não puxa um pacote.
- Email + DNS → fora do escopo. Configure separadamente via Conectar um domínio e Configurar email para seu domínio.
Referência
Caminhos de origem que o escaneamento SSH verifica:
/var/www/*/— raiz comum de vhost Nginx / Apache/srv/www/*/— alternativa no estilo Debian/home/*/public_html/— raiz de documentos no estilo cPanel/home/*/domains/*/public_html/— raiz de documentos no estilo DirectAdmin- WordPress: qualquer um dos anteriores que contenha um
wp-config.php - Bancos de dados: enumerados via
mysql -e "SHOW DATABASES"usando o~/.my.cnfdo usuário SSH, se existir
Endpoints de escaneamento do cPanel usados:
WebVhosts(lista raízes de documentos de vhosts)MysqlFE/listdbs(lista bancos de dados)- Sondagem da árvore de arquivos por vhost em busca de
wp-config.php
Staging em disco durante a migração:
- Lado da origem: mysqldump temporário em
/tmp/, apagado imediatamente depois - Este servidor:
/tmp/helm-restore/<id>/<bundle>.tar.gz— mesmo caminho usado pelo assistente de restauração
Formato do pacote: formato próprio do Server Manager, intercambiável com o que a aba Backup produz — então migrar e depois restaurar é byte a byte idêntico a fazer backup e depois restaurar (a diferença é só de onde veio o pacote).