n8n em queue mode: Redis, workers e dimensionamento

Resposta rápida

No queue mode, o n8n separa o recebimento de execuções do processamento. Redis coordena a fila e workers executam os workflows; PostgreSQL mantém os dados da aplicação. A arquitetura melhora isolamento, mas não cria capacidade infinita: concorrência, memória, limites de APIs e nós pesados continuam sendo gargalos.

Veja a infraestrutura: VPS para Redis no Brasil para colocar este projeto no ar.

Quando o modo fila faz sentido

Ele é útil quando execuções precisam ser distribuídas ou quando o processo principal não deve fazer todo o trabalho. Antes de migrar, meça duração, volume, picos e falhas. Uma instância pequena pode ser mais simples e previsível do que adicionar Redis sem necessidade.

Componentes e responsabilidades

• Main recebe webhooks, agenda e administra.
• Redis mantém o estado transitório da fila.
• Workers retiram jobs e executam workflows.
• PostgreSQL guarda configurações e histórico conforme a política do n8n.

Mantenha os componentes na rede privada. Credenciais, encryption key e variáveis de ambiente devem ser consistentes entre main e workers. Um worker com chave diferente pode não conseguir interpretar dados protegidos.

Exemplo conceitual de Compose

services:
  redis:
    image: redis:7-alpine
  worker:
    image: n8nio/n8n:latest
    command: worker
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis

Fixe versões compatíveis, complete as variáveis exigidas pela versão do n8n e não copie esse trecho para produção sem revisar banco, secrets, volumes e proxy reverso.

Dimensione pelo comportamento

Comece com um worker e concorrência conservadora. Observe tamanho da fila, tempo em espera, duração, uso de CPU/RAM, reinícios e rate limits externos. Se a fila cresce enquanto CPU está baixa, investigue dependência externa ou concorrência configurada. Se memória cresce com workers, reduzir concorrência pode ser mais seguro do que adicionar processos.

Faça um teste controlado com workflow idempotente e dados fictícios. Pare um worker e confirme se o job é retomado conforme a política. Não use um fluxo que envia mensagens reais como teste de recuperação.

Operação e CTA

Faça backup do banco e do Redis conforme o papel dos dados, monitore volumes e proteja o editor. Veja a landing de VPS para n8n para comparar planos; a escolha deve seguir o tamanho das execuções e a necessidade de serviços auxiliares.

Checklist

• [ ] Main, workers e Redis usam a mesma configuração crítica.
• [ ] Redis e banco não estão públicos.
• [ ] Concorrência inicial é conservadora.
• [ ] Fila, memória, erros e reinícios são monitorados.
• [ ] Workflow de recuperação foi testado.

FAQ

Mais workers sempre deixam o n8n mais rápido?

Não. Dependências externas, memória, CPU e limites de API podem ser o gargalo.

Redis substitui PostgreSQL no n8n?

Não. Eles têm papéis diferentes na arquitetura.

Sinais para aumentar capacidade

Aumente workers somente quando houver fila persistente, memória disponível e dependências externas capazes de acompanhar. Depois de cada mudança, compare idade do job, taxa de erro, tempo de execução, consumo por processo e limite das APIs chamadas. Se o gargalo está em uma etapa serial ou em uma API externa, multiplicar workers apenas aumenta retries. Versione a configuração e faça o rollback para a concorrência anterior quando os sinais piorarem.