Como migrar n8n de VPS para outro provedor: DNS, SSL e validação pós-migração

Meta descrição: Aprenda como migrar n8n de VPS para outro provedor com DNS, SSL e checklist de validação. Passo a passo seguro para não perder nada.

Migrar o n8n de uma VPS para outro provedor parece simples (“é só subir outro servidor e apontar o domínio”), mas é justamente aí que muita gente se complica: perde credenciais, quebra webhooks, fica com certificado SSL inválido ou descobre tarde demais que não tinha backup consistente do banco.

Neste guia, você vai aprender como migrar n8n de VPS para outro provedor com um processo seguro e previsível, cobrindo três pilares:

• Dados e ambiente: como garantir que workflows, credenciais, execuções e configurações sobrevivam à mudança.
• DNS: como fazer a troca com o mínimo de downtime e sem “sumir” do ar para alguns usuários.
• SSL/HTTPS: como instalar o Let’s Encrypt e deixar o acesso seguro rapidamente.

A ideia aqui é ser didático para iniciantes, mas sem esconder as partes importantes. Ao final, você terá um checklist pós-migração do n8n para validar tudo: editor, webhooks, filas, integrações externas e logs.

Dica de ouro: migração boa é a que você consegue repetir. Então trate esse processo como um pequeno “playbook”: preparação → cópia/restauração → DNS → SSL → validação.

Se você seguir a ordem sugerida, você reduz muito as chances de ficar preso em problemas clássicos como “o workflow funciona manualmente mas não dispara por webhook” (geralmente DNS/HTTPS) ou “as credenciais sumiram” (variáveis de ambiente e chave de criptografia).

Checklist de preparação para migrar o n8n entre VPS

Antes de mexer em DNS e SSL, a melhor forma de evitar dor de cabeça é preparar a migração com calma. O objetivo desta etapa é responder: o que exatamente precisa ser copiado? E como volto atrás se algo der errado?

Comece mapeando como seu n8n está rodando hoje:

• Está em Docker Compose? (o mais comum em VPS)
• Usa PostgreSQL (recomendado) ou SQLite?
• Tem Redis/Queue Mode (para alto volume)?
• Está atrás de Nginx/Traefik como proxy reverso?
• Quais domínios/subdomínios atendem o n8n? (ex.: n8n.seudominio.com)

Depois, identifique os itens críticos que normalmente causam perda de dados ou quebra de acesso:

1) Backup do banco de dados

Se você usa Postgres, o banco é “o coração” do n8n: workflows, credenciais (criptografadas), execuções, usuários… tudo passa por ele. Faça um dump antes de qualquer alteração.

2) Chave de criptografia das credenciais (muito importante)

O n8n criptografa credenciais com uma chave definida em variável de ambiente. Se você restaurar o banco em outro servidor, mas não levar a mesma chave, as credenciais ficam ilegíveis. Em instalações Docker, isso costuma estar em algo como N8N_ENCRYPTION_KEY no .env ou no docker-compose.yml.

3) Arquivos persistentes/volumes

Dependendo do setup, você pode ter:

• Pasta de dados (ex.: ~/.n8n ou volume n8n_data)
• Certificados (se você gerencia SSL manualmente)
• Configuração do proxy reverso

4) Plano de janela de migração + TTL do DNS

Se você puder planejar uma janela de manutenção, melhor. Um truque prático é reduzir o TTL do registro DNS algumas horas antes (por exemplo, para 60–300 segundos). Assim, quando você trocar o IP, a propagação tende a ser mais rápida.

Também vale checar integrações externas que dependem do seu domínio:

• Webhooks de Stripe, WhatsApp, Telegram, GitHub, etc.
• Allowed redirect URLs (OAuth do Google, Microsoft…)

Se você mantiver o mesmo domínio durante a migração, a maior parte dessas integrações continua funcionando, desde que o HTTPS e os webhooks voltem corretamente.

Por fim, se você é iniciante e quer reduzir risco, crie um “ensaio”:

• Suba o n8n novo em um subdomínio temporário (ex.: n8n-novo.seudominio.com)
• Restaure o banco lá
• Valide tudo
• Só depois faça o corte do DNS para o domínio oficial

Essa abordagem dá confiança antes do “momento do switch”.

🤖 Um próximo passo natural: aprender n8n e Agentes de IA de forma estruturada

Se você chegou até aqui, provavelmente já está usando o n8n para algo sério (ou está prestes a colocar em produção). E uma coisa que ajuda muito, principalmente para iniciantes, é ter um caminho estruturado que junta instalação em VPS, domínio, SSL, segurança e, claro, a parte mais legal: criar agentes de IA e automações vendáveis.

Eu indicaria dar uma olhada na Formação Agentes de IA (n8n) da Hora de Codar: ela tem 11+ cursos, 221+ aulas, 20h+ e 21+ projetos, além de comunidade ativa. O ponto forte é que você aprende construindo, do básico ao avançado, sem depender de programação.

Link para conhecer: https://app.horadecodar.com.br/lp/formacao-agentes-de-ia-n8n?utm_source=blog

Se o seu objetivo é parar de “apagar incêndio” com infraestrutura e começar a criar automações realmente robustas (e até montar portfólio), esse tipo de trilha bem guiada economiza muito tempo.

Como transferir dados e restaurar o ambiente n8n no novo servidor

Com o planejamento pronto, a parte prática é: copiar dados + reproduzir o ambiente no novo servidor. Aqui, o foco é minimizar diferença entre “antes” e “depois”.

1) Suba a base do novo servidor

No novo provedor, atualize o sistema e instale o que você precisa para rodar seu n8n (na maioria dos casos, Docker + Docker Compose). Se você já usa Compose hoje, tente manter a mesma estrutura: isso facilita muito.

Se você usa Postgres em container, garanta persistência com volumes. Se usa Postgres fora do Docker (instalado no sistema), garanta que a versão é compatível com o dump que você fez.

2) Faça backup do banco no servidor antigo

A forma mais comum com Postgres é gerar um dump e copiar para o novo servidor. Se o Postgres estiver em container, você pode executar o comando de dump dentro do container e salvar o arquivo.

O ponto principal aqui não é o comando exato, e sim:

• Dump consistente (sem “meio backup”)
• Arquivo transferido com segurança (SCP/rsync)

3) Restaure o banco no servidor novo

Crie o banco/usuário (se necessário) e restaure o dump. Depois, confira se as tabelas e registros estão lá.

4) Leve junto o que o n8n precisa para “reconhecer” o banco

Aqui é onde muita migração quebra:

• Mesmas variáveis de ambiente (host do banco, porta, nome do banco, usuário, senha)
• Mesma N8N_ENCRYPTION_KEY (para descriptografar credenciais)
• Mesmo N8N_HOST, N8N_PROTOCOL e WEBHOOK_URL (essenciais para webhooks)

Se o seu objetivo é não quebrar integrações, defina o WEBHOOK_URL com o domínio final (o oficial), mesmo que, durante testes, você acesse por IP. Isso evita que o n8n “grave” URLs erradas.

5) Suba o n8n e valide internamente antes do DNS

Antes de apontar o domínio, valide que:

• O container sobe sem erros
• O n8n abre localmente (ou via IP)
• Você consegue logar
• Workflows aparecem

Uma prática segura é não ativar todos os workflows imediatamente. Suba o n8n, valide, e só então você liga o que depende de webhooks após o DNS/SSL estar ok.

6) Migração com downtime mínimo

Se você precisa reduzir ao máximo o tempo fora do ar:

• Congele alterações no n8n antigo (evite criar/editar workflows durante o corte)
• Faça um backup final (dump “de corte”)
• Restaure esse dump final no servidor novo
• Troque DNS

Assim, você evita inconsistência entre os dois ambientes.

No fim das contas, migrar dados é simples quando você enxerga o n8n como: banco + chave de criptografia + configuração de URL. O resto é “só infraestrutura”.

Vídeo recomendado para complementar (n8n na VPS)

Se você quer reforçar a parte de “ambiente correto em VPS” (que é a base de uma migração tranquila), este vídeo ajuda bastante a entender o setup e o que normalmente precisa estar alinhado antes de mexer em DNS e SSL.

Assista aqui:

Quando terminar, volte e revise principalmente as variáveis de ambiente (N8N_HOST, N8N_PROTOCOL, WEBHOOK_URL e N8N_ENCRYPTION_KEY) — elas são as que mais “pegam” em pós-migração.

Configurando DNS para o novo n8n após a migração

A etapa de DNS é a ponte entre “o n8n está rodando no novo servidor” e “as pessoas e integrações conseguem acessar”. E é também onde muita gente acha que fez tudo certo, mas ainda vê o site antigo por horas — isso quase sempre é cache/TTL.

Entendendo o que você vai mudar

Na prática, você vai ajustar o registro do seu domínio (geralmente um A record) para apontar para o novo IP da VPS.

• Se você usa n8n.seudominio.com, então normalmente existe um registro A para n8n.
• Se você usa o domínio raiz (ex.: seudominio.com), aí o registro é na raiz.

Se existir um proxy/CDN no caminho (como Cloudflare), a troca funciona, mas muda um pouco o comportamento de cache e SSL. Para iniciantes, funciona bem, mas vale saber se você está usando “nuvem laranja” (proxy) ou “DNS only”.

Passo a passo seguro para trocar o DNS

A forma mais tranquila de fazer o corte é:

1) Baixe o TTL algumas horas antes

Se hoje seu TTL é 1h ou mais, mude para 60–300 segundos. Isso acelera o corte.

2) Garanta que o novo servidor já responde

Antes de apontar DNS, confirme que o Nginx/Traefik do novo servidor está pronto para receber requisições no domínio (mesmo que ainda não chegue tráfego).

3) Troque o registro A (ou CNAME) para o novo IP

Salve e aguarde alguns minutos. Mesmo com TTL baixo, alguns resolvers podem demorar mais.

4) Valide com ferramentas locais

Você pode validar a resolução do domínio com comandos de DNS (ex.: dig/nslookup) e, principalmente, testando a resposta HTTP/HTTPS.

Evite os erros mais comuns

• Apontar para o IP errado (muito comum quando a VPS tem IPv4 e IPv6 e você cria registros misturados sem querer).
• Esquecer do registro AAAA (IPv6). Se você tem AAAA apontando para o servidor antigo, alguns usuários vão cair nele. Se não usa IPv6, remova ou atualize.
• Manter TTL alto no dia da migração: isso prolonga o “período híbrido” em que parte do mundo cai no antigo e parte no novo.

Sobre webhooks durante a propagação

Durante a janela de propagação, alguns serviços externos podem enviar webhooks para o IP antigo. Por isso, em migrações críticas, você pode:

• Manter o servidor antigo ativo por algumas horas/dias, só para “absorver” requisições antigas
• Ou configurar um redirect/proxy temporário no antigo apontando para o novo (depende do seu setup)

O ideal é: novo n8n pronto + DNS trocado + SSL emitido + validação. A partir daí, você desliga o antigo com segurança.

Como instalar SSL Let’s Encrypt e configurar HTTPS no n8n

Depois do DNS, o próximo passo é garantir que seu n8n esteja acessível por HTTPS com um certificado válido. Isso é fundamental não só por segurança: várias integrações (principalmente webhooks e OAuth) exigem HTTPS.

Aqui, a forma mais comum e simples é usar Let’s Encrypt no proxy reverso (Nginx ou Traefik). A ideia é:

• O n8n roda “por trás” (normalmente em HTTP interno, ex.: porta 5678)
• O Nginx/Traefik expõe o domínio na porta 443 com certificado SSL

Pré-requisitos que precisam estar certos

Antes de emitir o certificado, confira:

• O domínio (n8n.seudominio.com) já aponta para o IP novo
• A porta 80 está liberada (muitas validações do Let’s Encrypt usam HTTP)
• A porta 443 está liberada para HTTPS

Sem isso, a emissão falha e você entra em um ciclo de “tentei e não vai”.

Ajustes de configuração do n8n que evitam problemas

Mesmo com SSL funcionando, alguns comportamentos do n8n dependem das variáveis corretas:

• N8N_PROTOCOL=https
• N8N_HOST=n8n.seudominio.com
• WEBHOOK_URL=https://n8n.seudominio.com/

Esses valores garantem que links internos, endpoints de webhook e callbacks usem HTTPS com o domínio certo.

Emissão do certificado (visão geral)

• Nginx + Certbot: você instala o Certbot, aponta o servidor para responder em /.well-known/acme-challenge/ e emite/renova.
• Traefik: normalmente você configura o ACME no próprio Traefik, e ele emite/renova automaticamente.

Para iniciantes, Traefik costuma ser bem “mão na massa” com Docker, e Nginx é ótimo quando você quer controle fino. Os dois funcionam.

Como saber se o SSL está correto

Depois de emitir:

• Abra o domínio no navegador e veja se aparece cadeado e certificado válido
• Verifique se está redirecionando de http:// para https://

Se o n8n carrega, mas webhooks não, o problema geralmente é:

• WEBHOOK_URL errado
• Proxy não encaminhando headers (ex.: X-Forwarded-Proto)

Um sinal clássico: o editor abre, mas um serviço externo acusa “webhook URL inválida” ou “TLS handshake failed”.

Renovação automática

Let’s Encrypt expira, então a renovação automática é parte do “feito direito”. Certbot normalmente agenda renovação; Traefik renova sozinho. De qualquer forma, vale testar a renovação antes de esquecer.

No final, “instalar SSL Let’s Encrypt no n8n” não é só emitir certificado: é deixar DNS + portas + proxy + variáveis do n8n alinhados para não ter surpresa com webhooks e integrações.

💻 VPS para n8n: por que eu consideraria a Hostinger na próxima migração

Se a sua motivação para como migrar n8n de VPS para outro provedor é ganhar estabilidade, performance ou simplificar o setup, vale considerar a VPS da Hostinger. O que eu acho prático nela para n8n é que você consegue escalar recursos (CPU/RAM/NVMe) conforme o volume de execuções cresce e ainda tem uma estrutura bem amigável para quem está começando.

Além disso, os planos de VPS têm opções bem equilibradas (e com 30 dias de garantia), e a Hostinger destaca instalação facilitada e gerenciamento por painel — o que ajuda quando a ideia é “subir o ambiente e validar rápido”, que é exatamente o espírito de uma migração.

Se quiser ver os planos por lá, use este link de indicação: https://www.hostinger.com.br/horadecodar

E para ajudar no preço, dá para usar o cupom HORADECODAR.

No contexto de migração, a dica prática é: suba o novo n8n na VPS, teste com um subdomínio temporário, e só depois faça o corte do DNS. Assim você aproveita o melhor do servidor novo sem pressa.

Checklist pós-migração: validação e testes essenciais

Com o servidor novo no ar, DNS apontado e HTTPS funcionando, vem a etapa que separa “parece que está ok” de “está realmente ok”: o checklist pós-migração do n8n.

A ideia é validar em camadas: acesso, dados, execuções, webhooks e integrações.

1) Valide o acesso e o ambiente

Confira se:

• Você consegue abrir o n8n pelo domínio final em HTTPS
• Login funciona e os usuários aparecem
• Workflows e credenciais estão lá (credenciais sem erro de descriptografia)

Se credenciais estiverem com erro, suspeite imediatamente de N8N_ENCRYPTION_KEY diferente.

2) Valide execução manual e execução agendada

Teste um workflow simples manualmente (um HTTP Request, por exemplo) e veja se executa e registra logs.

Depois, valide gatilhos:

• Cron (se você usa)
• Interval/Timer

Às vezes o workflow roda manualmente, mas o Cron não dispara por timezone/variável de ambiente. Confira fuso horário do servidor e configurações do container.

3) Valide webhooks (a parte mais crítica)

Webhooks costumam ser o primeiro ponto a quebrar em migrações. Teste:

• Um webhook do próprio n8n (gatilho Webhook)
• Pelo menos uma integração real (Stripe, Telegram, etc.)

Se o serviço externo estiver batendo no endpoint certo e mesmo assim falhar, verifique:

• SSL válido
• WEBHOOK_URL
• Regras do proxy (path, headers e forwarding)

4) Valide e-mail, OAuth e integrações “sensíveis”

OAuth (Google/Microsoft) depende muito de URLs e HTTPS. Se você manteve o mesmo domínio, costuma ser tranquilo. Se mudou domínio, você precisará ajustar URLs de callback no console do provedor.

E-mail (SMTP) também pode falhar se o novo IP estiver “mal visto” ou se o provedor bloquear portas. Faça um envio de teste se você utiliza nodes de e-mail.

5) Performance e estabilidade

A migração também é um bom momento para observar:

• Uso de CPU/RAM
• Execuções simultâneas
• Tamanho do banco

Se você notou lentidão no provedor antigo, talvez seja a hora de subir recursos.

6) Encerramento seguro do servidor antigo

Não desligue o antigo imediatamente se você tem tráfego de webhooks. Uma abordagem prudente é manter o antigo por 24–72 horas (ou o tempo do seu TTL antigo), monitorando logs e erros. Quando tudo estiver estável, você desliga.

Essa validação final dá a tranquilidade de que a migração não só “subiu”, mas está pronta para produção — com webhooks, HTTPS e integrações funcionando do jeito que você espera.

Como migrar o n8n de uma VPS para outro provedor sem perder dados ou fluxos?

Para migrar o n8n de uma VPS para outro provedor, primeiro faça backup do banco de dados e da pasta /home/n8n/. Em seguida, configure a nova VPS, instale o n8n e restaure os arquivos e o banco de dados. Depois, faça apontamento do DNS para o novo IP e ajuste variáveis de ambiente, como secret keys e URLs.

O que devo considerar em relação ao SSL durante a migração do n8n?

Se você usava SSL na VPS antiga, é importante instalar e configurar novamente o certificado no novo ambiente, seja via Let’s Encrypt ou por um certificado próprio. Certifique-se de que portas 80 e 443 estejam liberadas e que o domínio já aponte para o novo servidor antes de emitir ou instalar o SSL.

Como garantir que a migração do n8n foi bem-sucedida após concluir todos os passos?

Após finalizar a migração, faça uma validação completa: teste fluxos automáticos, conexões com integrações externas, verifique logs e monitore a estabilidade por alguns dias. Verifique se todas as funcionalidades estão operando como esperado antes de encerrar a VPS antiga.

Conclusão

Migrar automações pode dar medo, mas quando você trata como um processo — e não como um “copiar e colar” — fica bem mais controlável. Neste artigo, você viu como migrar n8n de VPS para outro provedor com foco no que realmente evita prejuízo: preparar backups e variáveis críticas, restaurar o ambiente no novo servidor, fazer a troca de DNS com cuidado e finalizar com HTTPS via Let’s Encrypt.

O ponto central é lembrar que o n8n não é só “o container rodando”: ele depende do banco de dados, da chave de criptografia e de URLs bem configuradas para webhooks. Com isso alinhado, configurar DNS no n8n, instalar SSL Let’s Encrypt no n8n e executar um checklist pós-migração do n8n vira uma sequência lógica.

Se você fizer a validação por camadas (acesso → dados → execuções → webhooks → integrações), a chance de surpresa cai muito — e você consegue desligar o servidor antigo com tranquilidade.