Conteúdo

Tutorial de backup e atualização do n8n: como proteger, restaurar e atualizar sua instalação

O que você precisa salvar no backup

ItemLocalImportância
Banco de dados (workflows, credenciais e registros de execução)PostgreSQL ou arquivo SQLite em n8n_dataNecessário
Chave de criptografiaN8N_ENCRYPTION_KEY ou arquivo config em n8n_dataNecessária; sem ela, não é possível descriptografar as credenciais
Diretório de dados n8n_dataDocker VolumeRecomendado
compose.yaml, .envPasta de implantação no hostRecomendado

Método 1: exportar workflows pela CLI

O n8n inclui comandos de exportação que salvam workflows em arquivos JSON, adequados para controle de versão no Git:

docker compose exec n8n n8n export:workflow --all --separate --output=/home/node/.n8n/backup/workflows/
docker compose exec n8n n8n export:credentials --all --separate --output=/home/node/.n8n/backup/credentials/
  • --separate: um arquivo para cada workflow
  • As credenciais exportadas continuam criptografadas por padrão; para usá-las, você precisa da mesma chave de criptografia

Copie os arquivos para fora do contêiner:

docker compose cp n8n:/home/node/.n8n/backup ./n8n-backup-$(date +%F)

Para restaurar:

docker compose exec n8n n8n import:workflow --separate --input=/home/node/.n8n/backup/workflows/
docker compose exec n8n n8n import:credentials --separate --input=/home/node/.n8n/backup/credentials/

Método 2: fazer backup do banco de dados

PostgreSQL

docker compose exec -T postgres pg_dump -U n8n n8n | gzip > n8n-db-$(date +%F).sql.gz

Para restaurar em um banco de dados vazio:

gunzip -c n8n-db-2026-10-12.sql.gz | docker compose exec -T postgres psql -U n8n -d n8n

SQLite

O banco de dados SQLite fica no Volume n8n_data (database.sqlite). Antes de fazer o backup, pare o n8n para evitar copiar um arquivo enquanto ele está sendo gravado:

docker compose stop n8n
docker run --rm -v n8n_n8n_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/n8n-data-$(date +%F).tar.gz -C /data .
docker compose start n8n

(O nome do Volume segue o formato “nome_do_projeto_n8n_data”; você pode confirmá-lo com docker volume ls.)

Automatizar backups

Use o cron para fazer backups diários e sincronize os arquivos com outro local (outro host ou armazenamento em nuvem):

# /etc/cron.daily/n8n-backup
#!/bin/sh
cd /opt/n8n
docker compose exec -T postgres pg_dump -U n8n n8n | gzip > /backup/n8n-$(date +%F).sql.gz
find /backup -name 'n8n-*.sql.gz' -mtime +30 -delete

Teste a restauração dos backups regularmente para confirmar que eles realmente funcionam.

Migrar para um novo host

  1. No host antigo, faça backup do banco de dados e do .env (incluindo N8N_ENCRYPTION_KEY).
  2. No novo host, inicie o PostgreSQL usando o mesmo compose.yaml e .env.
  3. Restaure o banco de dados.
  4. Inicie o n8n e confirme que os workflows e as credenciais estão funcionando.
  5. Atualize o DNS para apontar para o novo host.

Atualizar o n8n

O n8n lança uma nova versão aproximadamente toda semana. Este é o processo recomendado:

  1. Leia as notas da versão (Release notes), especialmente para verificar se há mudanças incompatíveis (breaking changes).

  2. Faça um backup.

  3. Altere a versão da imagem em compose.yaml, por exemplo, de n8nio/n8n:2.42.7 para a nova versão.

  4. Atualize:

    docker compose pull n8n
    docker compose up -d n8n
    docker compose logs -f n8n
  5. Confirme que os workflows importantes estão funcionando.

Ao iniciar, o n8n executa automaticamente as migrações do banco de dados. O progresso aparece nos logs.

Tags de versão

Tags das imagens do n8n 2.x:

TagDescrição
stableVersão estável atual (substitui a antiga latest)
betaVersão de teste, que pode ser instável (substitui a antiga next)
2.42.7 etc.Versão fixa; recomendada para produção

Atualizar do n8n 1.x para o 2.x

A versão 2.0 inclui várias mudanças incompatíveis. Antes de atualizar, leia a documentação oficial sobre as breaking changes da versão 2.0. Os principais pontos incluem:

  • O botão Activate foi substituído por Publish / Unpublish: salvar não aplica as mudanças imediatamente; é preciso publicar.
  • Os executores de tarefas (task runners) ficam ativados por padrão; o nó Code é executado em um processo separado.
  • Por padrão, o nó Code não pode ler variáveis de ambiente; ajuste os trechos dos workflows antigos que usam $env.
  • O nó Python Code agora usa Python nativo, exige um executor de tarefas externo e tem sintaxe diferente da versão anterior.
  • A execução de comandos do sistema (Execute Command) e os gatilhos de arquivos locais ficam desativados por padrão.
  • Por padrão, os nós de leitura e gravação de arquivos só podem acessar pastas específicas.
  • O MySQL / MariaDB deixou de ser compatível como banco de dados do n8n; migre primeiro para PostgreSQL ou SQLite.
  • Os dados retornados por um subworkflow ao workflow principal agora correspondem à saída do último nó do subworkflow.
  • O nó Start foi removido; use Manual Trigger.

Recomendamos testar a versão 2.x em um ambiente de teste com dados de backup e atualizar o ambiente de produção somente depois de confirmar que todos os workflows importantes funcionam.

Atualizado 12 de outubro de 2026