Como Configurar o n8n em Queue Mode para Alta Performance na VPS

Aprenda a configurar o n8n em queue mode para alta performance na VPS usando Redis e Postgres. Veja como preparar seu ambiente, configurar via Docker Compose, fazer tuning e escolher VPS adequada para escalabilidade.

Configurar o n8n em queue mode é essencial para quem busca alta performance e escalabilidade em suas automações, especialmente quando hospedado em uma VPS. Este artigo vai te mostrar passo a passo como preparar seu ambiente usando Redis e Postgres, configurar o n8n via Docker Compose, além de dicas importantes de tuning e recomendações para escolher a VPS ideal para rodar o n8n de forma eficiente. Vamos começar entendendo a diferença entre o modo regular e queue mode.

Entendendo a diferença entre o n8n queue mode e o modo regular

O n8n é uma poderosa ferramenta de automação que pode funcionar de diferentes maneiras, principalmente em dois modos: o modo regular e o queue mode. Entender as diferenças entre esses modos é fundamental para escolher a melhor configuração para seu projeto.

No modo regular, o n8n executa os workflows diretamente, de forma síncrona. Isso significa que cada fluxo é processado imediatamente após ser disparado, o que é simples e eficiente para cargas menores. No entanto, com volumes maiores, este modo pode ficar sobrecarregado, limitando a performance e o tempo de resposta.

Já o queue mode usa um sistema de filas para gerenciar a execução dos workflows. Os jobs são enviados para uma fila no Redis e consumidos pelos workers do n8n, que processam esses jobs de forma assíncrona e paralela. Essa arquitetura permite escalar o número de workers e otimizar o uso de recursos para cargas maiores, elevando muito o desempenho e a resiliência.

Esse modelo é ideal para quem precisa rodar muitas automações simultâneas, garantido que nenhuma tarefa fique travada e que o sistema permita ajustes finos de concorrência e priorização. Com o queue mode, mesmo em VPS com recursos limitados, você consegue ajustar os workers e otimizar o throughput das execuções.

Para resumir:

• Modo regular: execuções síncronas, simples, indicado para cargas baixas e médias.
• Queue mode: execuções assíncronas via fila, escalável, ideal para altas cargas e projetos profissionais.

Saber qual usar ajuda a evitar gargalos e garantir que o n8n rode sempre com alta performance, especialmente na VPS que você escolher.

Indicação de Formação Agentes de IA para dominar o n8n e automações

Se você deseja dominar o n8n e aprender a criar agentes de IA inteligentes e automações profissionais, recomendo fortemente a Formação Agentes de IA do Hora de Codar. É uma formação completa e prática, ideal para iniciantes e quem quer virar profissional no mercado de automações sem precisar programar.

São mais de 20 horas de conteúdo, 11 cursos, 21 projetos reais e acesso vitalício, tudo com uma metodologia passo a passo que te leva do básico à venda de soluções prontas.

Hospedagem recomendada

Hospedagem que aguenta seu projeto crescer

Hospedagem rápida, painel simples, backups automáticos e suporte 24/7 em português.

Ver oferta

Além disso, você terá suporte em grupo exclusivo, atualizações constantes e bônus que facilitam ainda mais seu aprendizado.

Vale muito a pena conferir para quem quer investir no futuro das automações e IA:
https://app.horadecodar.com.br/lp/formacao-agentes-de-ia-n8n?utm_source=blog

É uma dica bem legal, como se eu estivesse recomendando para um amigo que quer aprender mesmo a fundo.

Como preparar o ambiente VPS para alta performance (Redis + Postgres)

Para configurar o n8n em queue mode e garantir alta performance, é fundamental preparar um ambiente robusto na VPS, incluindo bancos Redis e Postgres, que são essenciais para o funcionamento das filas e do armazenamento de dados.

1. Redis: Serve como o sistema de filas onde os jobs do n8n são enfileirados para serem processados pelos workers. Redis é conhecido por sua velocidade e eficiência, portanto é importante escolher uma versão estável e configurá-lo para persistência quando possível.

2. Postgres: Usado para armazenar os dados dos workflows, histórico de execuções e configurações do n8n. Um banco de dados relacional confiável e bem configurado é chave para a estabilidade e performance geral.

Dicas para preparar seu VPS:

• Escolha uma VPS com recursos adequados: CPU multi-core e pelo menos 4GB de RAM para ambientes produtivos.
• Instale Redis e Postgres via pacotes oficiais ou usando contêineres Docker exclusivos para cada serviço.
• Configure ambos para iniciar automaticamente com o sistema e reserve recursos suficientes para eles.
• Para Redis, ajuste os parâmetros de persistência (RDB/AOF) conforme a necessidade para garantir durabilidade sem impactar na performance.
• Para Postgres, configure o maxconnections, workmem e shared_buffers visando o desempenho do seu workload.

Além disso, mantenha seu servidor atualizado, use discos SSD para melhor I/O, e monitore os recursos para evitar gargalos. Uma VPS com bom desempenho IO e rede vai fazer toda a diferença no uso do n8n em queue mode.

Preparar o ambiente corretamente é o primeiro passo para que o n8n rode de forma estável, rápida e possa escalar conforme o crescimento das automações no seu projeto.

Vídeo recomendado para configurar n8n em queue mode

Este vídeo do canal Hora de Codar apresenta um tutorial completo para instalação do n8n na VPS, com dicas valiosas para iniciar seu projeto em queue mode com Docker e bancos Redis e Postgres. Ideal para quem quer começar com o pé direito e garantir alta performance.

Assista ao vídeo, siga os passos e veja como simplificar a configuração de seus agentes de IA com o n8n:

https://youtube.com/watch?v=VCKzXFk_XjM%3Fsi%3DeOBTMrjZNPj3q07Z

Não esqueça de clicar em “Curtir” e se inscrever no canal para mais conteúdos atualizados!

Configurando o n8n em queue mode com Docker Compose: principais variáveis de ambiente

Uma das formas mais práticas e recomendadas para rodar o n8n em queue mode é usando Docker Compose, que permite orquestrar o n8n junto com Redis e Postgres facilmente.

Aqui está um passo a passo básico para configurar:

• Crie um arquivo docker-compose.yml incluindo os serviços do n8n, redis e postgres.
• No serviço do n8n, use a imagem oficial do n8n e defina as variáveis de ambiente essenciais para o queue mode:
• EXECUTIONS_PROCESS: setar para “queue” para ativar o modo fila.
• QUEUEBULLREDISHOST, QUEUEBULLREDISPORT: para indicar endereço do Redis.
• DBTYPE, DBPOSTGRESDBHOST, DBPOSTGRESDBPORT, DBPOSTGRESDBDATABASE, DBPOSTGRESDBUSER, DBPOSTGRESDB_PASSWORD: para configurar o banco Postgres.
• QUEUEBULLCONCURRENCY: define o número de workers que processarão os jobs em paralelo, ajuste conforme sua VPS.

Exemplo resumido das variáveis:

services:
n8n:
image: n8nio/n8n
environment:
– EXECUTIONSPROCESS=queue
– QUEUEBULLREDISHOST=redis
– QUEUEBULLREDISPORT=6379
– DBTYPE=postgresdb
– DBPOSTGRESDBHOST=postgres
– DBPOSTGRESDBPORT=5432
– DBPOSTGRESDBDATABASE=n8n
– DBPOSTGRESDBUSER=n8n
– DBPOSTGRESDBPASSWORD=n8npassword
– QUEUEBULLCONCURRENCY=5
redis:
image: redis
postgres:
image: postgres
environment:
POSTGRESDB: n8n
POSTGRESUSER: n8n
POSTGRES_PASSWORD: n8npassword

Depois, basta rodar o docker-compose up -d e seu n8n estará pronto para rodar em queue mode, com Redis gerenciando as filas e Postgres persistindo dados.

Ajustar as variáveis de ambiente, especialmente o QUEUEBULLCONCURRENCY, é fundamental para tirar o máximo proveito da sua VPS e obter alta performance nas execuções de workflows.

Dicas de tuning, boas práticas e testes de throughput no queue mode

Após configurar o n8n em queue mode, fazer ajustes finos para maximizar a performance é essencial para garantir que o sistema rode com alta eficiência e sem gargalos.

Dicas importantes para tuning e boas práticas:

1. Ajuste o número de workers (QUEUEBULLCONCURRENCY): Comece com um valor que não exija toda a CPU da VPS, por exemplo, 2 ou 3. Vá aumentando gradualmente monitorando o uso de CPU, memória e latência até achar o ponto ideal.

2. Monitore o Redis e Postgres: Use ferramentas como Redis Insight e pgAdmin para observar performance, latência e recursos usados dos bancos. Ajuste parâmetros como max_connections e memória reservada conforme necessário.

3. Utilize logging adequado: Configure o nível de logs do n8n para DEBUG durante os testes e depois para WARNING ou ERROR na produção para evitar overhead.

4. Testes de throughput: Gere cargas de trabalho simulando múltiplas execuções simultâneas dos workflows para medir a capacidade do sistema. Use ferramentas como Apache JMeter ou scripts customizados para disparar execuções.

5. Distribua os workers: Se possível, distribua workers em múltiplos servidores ou contêineres para aumentar resiliência e escalabilidade.

6. Mantenha seu n8n sempre atualizado: Novas versões trazem melhorias de performance e correções importantes.

Por fim, lembre-se que o tuning é um processo contínuo. Revise periodicamente os recursos usados e ajuste as variáveis ambiente conforme o crescimento do volume de automações.

Seguindo essas práticas, seu n8n rodando em queue mode estará otimizado para alta performance, garantindo automações rápidas, estáveis e escaláveis.

Hospede seu n8n na VPS da Hostinger com desconto especial

Para quem quer uma VPS confiável, escalável e fácil de gerenciar para rodar o n8n em queue mode, a Hostinger é uma opção que vale muito a pena.

Eles possuem planos que contemplam desde ambientes básicos até servidores robustos com vários núcleos de CPU e grande memória RAM, ideais para cargas altas.

Além de oferecer 30 dias de garantia, suporte 24/7, instalação simplificada do n8n e painel intuitivo, você ainda pode aproveitar o cupom de desconto HORADECODAR para economizar na contratação.

Uso a Hostinger nos meus projetos e recomendo para quem precisa de estabilidade, velocidade e suporte eficiente:
https://www.hostinger.com.br/horadecodar

Fica a dica para facilitar sua jornada com o n8n e garantir seu ambiente de alta performance.

Requisitos, upgrades e recomendações de VPS para rodar o n8n escalável

Para rodar o n8n de forma escalável especialmente em queue mode, a escolha da VPS certa é tão importante quanto a configuração do próprio n8n.

Requisitos mínimos recomendados para um ambiente com Redis e Postgres:

• CPU: mínimo 2 núcleos, preferencialmente 4 núcleos para cargas médias a elevadas.
• Memória RAM: pelo menos 4GB, mas para alta carga considere 8GB ou mais.
• Armazenamento: SSD com espaço suficiente para logs, banco de dados e arquivos temporários (mínimo 50GB recomendado).
• Rede: boa largura de banda e baixa latência para conexões rápidas entre n8n, Redis e Postgres.

Para upgrades, o ideal é aumentar CPU e RAM de forma flexível conforme o volume de automações cresce, para manter performance estável.

Uma recomendação que queremos compartilhar é a VPS da Hostinger, que oferece planos otimizados para projetos de automação com n8n. A Hostinger traz:

• Planos com múltiplas opções de CPU e RAM, escaláveis conforme necessidade.
• Fácil instalação do n8n com setup automático e gerenciamento pelo painel.
• Garantia de uptime de 99,9%, importante para manter fluxos sempre ativos.
• Atendimento 24/7 para suporte rápido em caso de dúvida ou problema.

Se você está começando ou planejando escalar seu projeto, a Hostinger pode ser uma excelente escolha para hospedar seu n8n em queue mode. Ah, e uma dica: use o cupom de desconto HORADECODAR para garantir um preço especial.

Assim, você terá um ambiente robusto, poderoso e pronto para crescer conforme a demanda das suas automações for aumentando.

O que é o Queue Mode no n8n e por que utilizá-lo para alta performance?

O Queue Mode no n8n permite distribuir a execução dos workflows entre múltiplos processos utilizando uma fila, geralmente gerenciada pelo Redis, enquanto as informações persistentes ficam no Postgres. Essa configuração ajuda a melhorar a performance e escalabilidade do n8n, tornando-o capaz de processar muitos jobs simultaneamente, ideal para ambientes de alta demanda em VPS.

Quais configurações de tuning são recomendadas ao usar n8n em Queue Mode com Redis e Postgres em uma VPS?

Recomenda-se ajustar as variáveis de ambiente do n8n, como N8NWORKERTIMEOUT, aumentar a quantidade de workers, otimizar as configurações do Redis (por exemplo, memória, persistência e número de conexões) e realizar tuning no Postgres (maxconnections, sharedbuffers). Além disso, monitorar o uso de CPU e RAM na VPS e alocar recursos conforme necessário para garantir máxima performance.

É recomendado utilizar a Hostinger para hospedar o n8n em Queue Mode na minha VPS?

Sim, a Hostinger é recomendada devido ao seu bom custo-benefício, estabilidade, facilidade de escalar recursos e suporte eficiente, tornando-a uma escolha adequada para hospedar instâncias do n8n em Queue Mode quando alta performance é uma prioridade.

Conclusão

Configurar o n8n em queue mode em uma VPS é a melhor estratégia para quem busca alta performance, escalabilidade e estabilidade em automações profissionais. Com Redis gerenciando filas e Postgres para persistência, você consegue rodar múltiplos workflows simultaneamente com eficiência.

Preparar o ambiente corretamente, configurar via Docker Compose com as variáveis de ambiente adequadas e realizar tuning fina são passos fundamentais para extrair o melhor desempenho do seu n8n.

Além disso, escolher uma VPS robusta, como as oferecidas pela Hostinger, garante recursos suficientes para crescer conforme suas necessidades, e ainda simplifica o gerenciamento do servidor.

Se quiser ir além e realmente se destacar no mercado de automações, recomendo conhecer a Formação Agentes de IA do Hora de Codar, que ensina tudo para você criar, automatizar e vender soluções com n8n e IA, mesmo sem experiência técnica.

Com essas dicas, sua automação com n8n em queue mode na VPS será potente, confiável e pronta para escalar junto com seu negócio.

Quando o queue mode NÃO vale a pena?

Vou ser honesto contigo antes de você sair mudando tudo: nem todo projeto precisa de fila

Se a tua instância roda poucos fluxos por dia, leves, sem pico de disparo, o modo regular entrega o mesmo resultado com MUITO menos peça pra dar problema

Queue mode traz Redis no meio do caminho, processo separado, mais consumo de memória e mais superfície pra quebrar

É complexidade que só se paga quando existe carga de verdade do outro lado

O sinal certo pra migrar não é "quero performance":

É gargalo observado, tipo execução esperando a anterior terminar, pico que derruba o tempo de resposta do webhook, ou um fluxo pesado segurando todo o resto atrás dele

Se nada disso acontece no teu servidor, tu ganha um ambiente mais difícil de manter e zero de velocidade

Então mede primeiro, migra depois, beleza? 🙂

Rodar Redis e Postgres na mesma VPS do n8n vale a pena?

Na maioria dos projetos, sim, e é assim que quase todo mundo começa

Uma máquina só, uma rede interna, um backup pra cuidar: simples de subir e simples de entender

Porém tem um preço escondido nisso: os três disputam a mesma CPU e o mesmo disco

Quando o Postgres resolve escrever histórico numa hora de pico, quem sente é a execução do fluxo, e você jura que o problema é o n8n

Como decidir sem chutar:

Enquanto o servidor tem folga e você consegue olhar o consumo de cada contêiner, deixa junto

Quando o banco começar a aparecer como o vilão recorrente do consumo, aí separar o Postgres em outra máquina resolve mais que qualquer tuning de variável

A regra prática é essa: separa o que já provou ser gargalo, não o que você acha que vai ser

Antes de copiar qualquer docker-compose, confira a versão que você vai rodar

Se liga nisso, porque é aqui que todo tutorial de self-host envelhece

O n8n anda rápido, e configuração é justamente a parte que ganha nome novo, fica depreciada ou muda de comportamento entre versões

Um compose que funcionou perfeitamente meses atrás pode subir hoje sem erro nenhum e simplesmente ignorar o que você pediu

O hábito que evita a dor de cabeça:

Antes de apontar produção, sobe o ambiente uma vez e LÊ o log do contêiner nos primeiros segundos

É ali que aparece config que não foi entendida, conexão que não fechou e permissão faltando, bem antes de você descobrir pelo fluxo quebrado às três da manhã

E confere os nomes das variáveis na documentação da versão exata que você vai subir, não na do vídeo aleatório do ano passado

Já me ferrei uma vez por causa disso, aí aprendi 😀

Outra: quando um fluxo para de funcionar logo depois de um update, o primeiro suspeito é configuração antiga, não a VPS

O que quebra se o Redis cair (e o que o backup realmente salva)

Vale separar bem os papéis, porque muita gente descobre isso do jeito ruim

O Redis segura a fila viva, ou seja, o que está esperando pra ser processado agora

O Postgres segura o que é seu de verdade: os workflows, o histórico e as configurações

Se o Redis cair, o que estava enfileirado naquele momento é o que você arrisca perder, e as execuções param de andar até ele voltar

Se o Postgres cair sem backup, você perde o projeto inteiro

Traduzindo pra rotina:

Backup periódico e testado é do Postgres, e testado significa restaurar em outro lugar pra ver se volta mesmo

Redis você quer é de pé, monitorado e com memória sobrando

E tem um detalhe que quase ninguém pensa:

Worker pode reiniciar no meio de uma execução

Então desenha os fluxos que mexem em dinheiro, envio de mensagem ou criação de registro pra aguentar rodar duas vezes sem duplicar nada

Isso não é frescura de arquiteto, é o que separa automação profissional de cliente ligando puto porque recebeu a mesma cobrança duas vezes

Fila andando devagar: onde olhar primeiro

Antes de sair aumentando plano da VPS, segue essa ordem, que resolve a maioria dos casos

1. O worker está mesmo de pé?

Fila cheia e nada saindo geralmente é isso: tem quem enfileire e não tem quem consuma

2. Todo mundo está falando com o MESMO Redis?

Processo principal apontando pra um lugar e worker pra outro é um clássico, e não dá erro barulhento, só silêncio

3. O Postgres está aguentando a conexão de todo mundo junto?

Cada processo abre suas conexões, e quando o limite estoura o sintoma parece lentidão, não erro de banco

4. CPU e memória estão no talo?

Se estiverem, aumentar concorrência só piora, porque você coloca mais gente disputando o mesmo prato

5. É o sistema que está lento ou o fluxo?

Essa é a pegadinha favorita: nó que fica esperando resposta de API externa vai demorar igual em qualquer servidor

Fila não acelera chamada de terceiro, ela só organiza a espera

Se o gargalo for esse, o ganho vem de rodar essas esperas em paralelo, não de trocar de VPS