n8n em produção: queue mode com Redis, PostgreSQL persistente, Traefik e backup externo

Persistência não é backup.

Essa diferença ficou muito clara em uma stack n8n real em produção: a arquitetura já tinha PostgreSQL persistente, Redis persistente, worker separado e Traefik, mas a primeira coleta registrou explicitamente que não havia backup externo do banco identificado.

Na etapa seguinte, foi configurado um serviço de backup do PostgreSQL para armazenamento S3 e o primeiro dump manual foi enviado com sucesso.

A história é útil justamente porque não começa com uma arquitetura “perfeita”. Ela mostra um ambiente funcionando, um gap encontrado e uma camada de recuperação adicionada com evidência.

A topologia observada #

A coleta de produção mostrou uma stack Docker Compose com esta separação de responsabilidades:

1
2
3
4
5
6
7
8
9
Internet
   ↓
Traefik
   ↓
n8n principal
   ↓
Redis ── fila ── n8n worker
   ↓
PostgreSQL

Os componentes estavam organizados em containers dedicados:

Traefik para publicação HTTP/HTTPS;
PostgreSQL 16 como banco principal;
Redis 7 como backend de fila;
processo principal do n8n;
worker dedicado para execução em queue mode.

Os dados de n8n, PostgreSQL e Redis usavam volumes persistentes.

Por que separar o worker #

Em queue mode, o processo principal não precisa executar sozinho todos os workflows.

Conceitualmente:

1
2
3
4
5
6
7
8
9
n8n principal
→ recebe/orquestra trabalho
→ envia execução para a fila

Redis
→ mantém a fila

n8n worker
→ consome e executa jobs

Essa divisão facilita separar a camada que atende UI/API/webhooks da capacidade de execução de workflows.

Ela também cria novas dependências operacionais: Redis e PostgreSQL deixam de ser detalhes internos e passam a fazer parte direta da disponibilidade da plataforma.

Redis persistente não elimina a necessidade de entender a fila #

O Redis observado tinha volume próprio e persistência configurada.

Isso reduz o risco de perder estado simplesmente porque o container foi recriado, mas não transforma Redis em banco de backup do n8n.

É importante distinguir:

1
2
3
volume persistente
!=
backup externo

O mesmo vale para PostgreSQL.

A primeira auditoria encontrou o gap #

A coleta inicial registrou a arquitetura como saudável, mas marcou o backup PostgreSQL/S3 como pendente.

Isso é um finding operacional simples e importante:

1
2
3
4
5
6
7
PostgreSQL em volume local
+
serviço em produção
+
nenhum backup externo identificado
=
recuperação ainda dependente demais do host

A decisão correta não é chamar o ambiente inteiro de inseguro. É identificar exatamente qual camada de recuperação estava ausente.

O backup externo foi adicionado #

Na documentação imediatamente posterior, o ambiente já tinha um container dedicado baseado em uma imagem de backup PostgreSQL para S3.

O banco protegido era o PostgreSQL usado pelo n8n.

A primeira execução manual registrou a sequência esperada:

1
2
3
4
criar dump
→ enviar para armazenamento S3
→ concluir upload
→ executar rotina de limpeza

O arquivo do primeiro dump apareceu no destino externo, portanto há evidência concreta de que o primeiro backup saiu do host e chegou ao storage.

O que isso ainda não prova #

Um primeiro dump bem-sucedido não fecha o assunto.

A própria documentação deixa pendente validar:

a próxima execução agendada;
a retenção recorrente configurada;
um teste de restore.

Portanto o estado correto é:

1
2
3
4
5
6
7
8
FACT
→ backup externo configurado
→ primeiro dump manual enviado com sucesso

TODO
→ provar recorrência ao longo do tempo
→ provar retenção funcionando como esperado
→ testar restore

Isso evita uma das frases mais perigosas de infraestrutura:

“tem backup”.

Sem saber se executa de novo e se restaura, a afirmação ainda é incompleta.

Backup do PostgreSQL não é disaster recovery completo #

A evidência recuperada comprova backup externo do PostgreSQL.

Ela não deve ser ampliada para afirmar que toda a plataforma está protegida contra qualquer desastre.

Uma estratégia completa também deveria decidir explicitamente como tratar, conforme o ambiente:

1
2
3
4
5
6
7
8
configuração do n8n
chave de criptografia
arquivos de compose
variáveis e secrets
volumes necessários
configuração do proxy e certificados
Redis, quando seu estado precisar ser preservado
procedimento de restauração

Nem tudo precisa necessariamente usar o mesmo mecanismo de backup, mas tudo que for necessário para reconstrução deve ter uma resposta documentada.

Healthcheck e ordem de inicialização importam #

Uma arquitetura n8n em queue mode depende de serviços que precisam estar disponíveis na ordem certa.

O desenho versionado relacionado à plataforma também evidencia healthchecks de PostgreSQL e Redis e dependências condicionadas ao estado dos serviços.

O princípio é simples:

1
2
3
container criado
!=
serviço pronto

Esperar PostgreSQL responder e Redis aceitar conexão reduz falhas de inicialização que parecem aleatórias, mas na prática são corrida de dependências.

Traefik fecha a camada de publicação #

Na coleta de produção, o Traefik era responsável pelas portas HTTP/HTTPS e pelo roteamento do n8n.

O Docker socket estava montado em modo read-only no desenho observado, reduzindo a superfície de escrita a partir do proxy.

A configuração real também levantou um ponto de atenção sobre exposição do dashboard do Traefik. Isso reforça uma regra útil:

painel administrativo e plano de dados não deveriam ganhar a mesma exposição só porque pertencem ao mesmo componente.

Um checklist mínimo para n8n self-hosted em produção #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
[ ] PostgreSQL persistente
[ ] Redis persistente quando usado em queue mode
[ ] worker separado quando a arquitetura exigir
[ ] healthchecks de banco e fila
[ ] dependências de inicialização explícitas
[ ] TLS e proxy reverso
[ ] Docker socket somente leitura quando possível
[ ] volumes mapeados e documentados
[ ] backup fora do host
[ ] evidência de execução recorrente
[ ] política de retenção validada
[ ] restore testado
[ ] chave de criptografia protegida e recuperável
[ ] procedimento de reconstrução documentado

O principal aprendizado #

A arquitetura já estava funcionando antes do backup externo existir.

Foi justamente uma coleta objetiva que permitiu separar:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
O QUE JÁ ESTAVA BOM
queue mode
worker separado
PostgreSQL persistente
Redis persistente
Traefik
healthchecks

O QUE FALTAVA
backup externo comprovado

Depois, o primeiro dump externo fechou parte do gap — mas não autorizou marcar restore e recorrência como resolvidos sem teste.

Esse é o padrão que eu prefiro em produção: inventariar o estado real, corrigir a lacuna específica e só marcar como concluído aquilo que a evidência permite.

Leitura relacionada #

A visão mais ampla dessa plataforma está no projeto n8n self-hosted com PostgreSQL, Redis, Traefik e observabilidade.