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
| Item | Local | Importância |
|---|---|---|
| Banco de dados (workflows, credenciais e registros de execução) | PostgreSQL ou arquivo SQLite em n8n_data | Necessário |
| Chave de criptografia | N8N_ENCRYPTION_KEY ou arquivo config em n8n_data | Necessária; sem ela, não é possível descriptografar as credenciais |
Diretório de dados n8n_data | Docker Volume | Recomendado |
| compose.yaml, .env | Pasta de implantação no host | Recomendado |
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
- No host antigo, faça backup do banco de dados e do
.env(incluindoN8N_ENCRYPTION_KEY). - No novo host, inicie o PostgreSQL usando o mesmo compose.yaml e
.env. - Restaure o banco de dados.
- Inicie o n8n e confirme que os workflows e as credenciais estão funcionando.
- 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:
-
Leia as notas da versão (Release notes), especialmente para verificar se há mudanças incompatíveis (breaking changes).
-
Faça um backup.
-
Altere a versão da imagem em compose.yaml, por exemplo, de
n8nio/n8n:2.42.7para a nova versão. -
Atualize:
docker compose pull n8n docker compose up -d n8n docker compose logs -f n8n -
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:
| Tag | Descrição |
|---|---|
stable | Versão estável atual (substitui a antiga latest) |
beta | Versã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