Jan 12, 2026
Bruno S.
9min de leitura
À medida que seus workflows de automação no n8n ficam mais complexos, executá-los de forma eficiente pode se tornar um desafio. Rodar tudo em um único processo pode causar lentidão, sobrecarregar o sistema ou até fazer com que as automações falhem.
A solução para esse problema é o n8n queue mode (modo de fila). Ele adiciona uma fila de tarefas que distribui as execuções entre vários processos de trabalho (workers), em vez de concentrar tudo em um único ponto. Com isso, os workflows passam a rodar de forma independente, melhorando tanto o desempenho quanto a escalabilidade das automações.
Neste guia, você vai aprender passo a passo como configurar o n8n queue mode em um VPS da Hostinger. Ao final, seu ambiente de automação com n8n estará mais estável, confiável e pronto para crescer conforme a demanda aumenta.
Por padrão, o n8n opera dentro de um processo principal de thread única, onde Por padrão, o n8n funciona em um único processo principal, no qual todas as tarefas são executadas de forma sequencial. Esse modelo atende bem automações com baixo volume, mas começa a gerar gargalos quando a carga de trabalho aumenta.
O n8n queue mode resolve esse problema ao dividir o back-end do n8n em três partes bem definidas:
Visualmente, a arquitetura do n8n queue mode funciona da seguinte forma:

| Serviço | Papel |
| Instância principal no n8n | Gerencia a interface visual, as configurações dos workflows e seus gatilhos |
| Redis | Atua como intermediário da fila de tarefas |
| Banco de dados do n8n | Armazena dados de execução, como logs e resultados |
| Instâncias worker do n8n | Pegam tarefas pendentes no Redis e executam os passos da automação |
Assim se apresenta o fluxo geral do processo no modo de fila:

Para facilitar o entendimento, dá para comparar esse modelo com outras soluções conhecidas:
No fim das contas, o n8n queue mode é uma forma simples e eficiente de escalar automações. Para rodar mais execuções ao mesmo tempo, basta adicionar mais processos de automação. A fila atua como um balanceador, distribuindo os workflows entre os workers disponíveis.
Para hospedar o n8n queue mode com Redis, o seu VPS precisa atender aos seguintes requisitos mínimos:
Você também precisará de:
Embora seja possível rodar o n8n queue mode usando o banco SQLite que vem por padrão, a recomendação é instalar o PostgreSQL, como veremos mais adiante neste guia. Ele oferece mais estabilidade e desempenho para cenários com maior volume de execuções.
Tanto o n8n quanto o Redis não exigem muito processamento. Por isso, a memória RAM costuma ser o fator mais importante. Um VPS Hostinger KVM 2 com Ubuntu é uma escolha equilibrada para uma configuração básica de n8n queue mode, comportando tranquilamente:
Esse setup é mais do que suficiente para workflows de pequeno a médio porte e ainda deixa uma boa margem para escalar conforme suas automações crescem.

Neste tutorial, vamos configurar o queue mode em uma única instância VPS KVM 2 rodando Ubuntu 24.04, com o n8n instalado manualmente via Docker. Esse é o método recomendado, pois é o mais simples de implementar e também facilita a escalabilidade conforme suas automações crescem.
O queue mode do n8n depende do Redis como intermediário da fila de tarefas, o que faz dele um componente essencial dessa configuração. Para preparar um container Redis na sua instância do n8n, siga os passos abaixo.


mkdir -p ~/redis-data
mkdir ~/n8n-queue-mode cd ~/n8n-queue-mode
sudo nano docker-compose.yml
version: "3.7"
services:
redis:
image: redis:6
container_name: redis
restart: always
volumes:
- ~/redis-data:/dataCom o Redis preparado e pronto para uso, você pode adicionar configurações extras, como definir uma senha. Para isso, siga os passos descritos em um guia de instalação do Redis.
Como estamos usando um container, será necessário criar um arquivo redis.conf personalizado, salvar as configurações nele e montá-lo como volume junto com um comando customizado.
Por exemplo, se você adicionou o arquivo redis.conf no diretório ~/redis-conf, você precisaria adicionar as seguintes linhas ao seu arquivo docker-compose.yml,:
volumes: - ~/redis-conf/redis.conf:/usr/local/etc/redis/redis.conf command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
Agora que o Redis está pronto, é hora de configurar as variáveis necessárias para ativar o queue mode. Neste cenário, consideramos que você já tem uma instância do n8n configurada com NGINX e que agora vai migrá-la para um ambiente baseado em containers.
Estas são as variáveis principais que você precisa definir:
| Variável | Finalidade |
|---|---|
| EXECUTIONS_MODE=queue | Define o método de execução como queue mode |
| QUEUE_BULL_REDIS_HOST=redis | Host do Redis. Como estamos usando Redis em container, o valor será redis |
| QUEUE_BULL_REDIS_PORT=6379 | Porta em que o Redis está escutando (6379 por padrão) |
| N8N_RUNNERS_ENABLED=true | Ativa os task runners |
| OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true | Garante que execuções manuais também sejam enviadas aos workers |
Outras variáveis importantes incluem:
| Variável | Finalidade |
|---|---|
| QUEUE_HEALTH_CHECK_ACTIVE=true | Adiciona um health check interno para monitorar a conexão com o Redis |
| QUEUE_BULL_REDIS_PASSWORD | Necessária se você configurou uma senha no Redis |
Agora que você já sabe quais são as configurações necessárias, vamos configurá-las.
cd ~/n8n-queue-mode
sudo nano .env
Insira os seguintes valores no arquivo:
N8N_LOG_LEVEL=debug N8N_LOG_OUTPUT=console N8N_BASIC_AUTH_ACTIVE=true N8N_BASIC_AUTH_USER=<your_username> N8N_BASIC_AUTH_PASSWORD=<your_password> N8N_HOST=srv721674.hstgr.cloud N8N_PORT=5678 N8N_PROTOCOL=https WEBHOOK_URL=https://srv721674.hstgr.cloud/ GENERIC_TIMEZONE=UTC N8N_EXPRESS_TRUST_PROXY=true N8N_SECURE_COOKIE=true EXECUTIONS_MODE=queue QUEUE_BULL_REDIS_HOST=redis QUEUE_BULL_REDIS_PORT=6379 N8N_RUNNERS_ENABLED=true OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true
Se você já tiver um arquivo de ambiente configurado, basta adicionar apenas as linhas relacionadas ao queue mode.
As configurações de log não são obrigatórias, mas ajudam bastante a acompanhar o status dos containers e a identificar problemas durante a configuração ou operação do queue mode.
Até aqui, você já definiu as variáveis de ambiente necessárias para o queue mode funcionar. Agora, vamos criar o container do n8n responsável pelo processo principal.
sudo nano docker-compose.yml
n8n:
image: n8nio/n8n
container_name: n8n
restart: always
env_file:
- .env
ports:
- "5678:5678"
volumes:
- ~/.n8n:/home/node/.n8n
depends_on:
- redisSeu arquivo docker-compose.yml deve ficar mais ou menos assim:

Neste ponto, você pode executar seu processo n8n executando o seguinte comando:
docker compose up -d
Depois disso, você já deve conseguir acessar sua instância normalmente e ver a interface como de costume. Para testar, rode um workflow simples que faça uma requisição web para o Google.

Mesmo com o queue mode ativado e o processo principal configurado para orquestrar uma fila, esse teste deve funcionar. Isso acontece por um motivo: o n8n tem um mecanismo de segurança. Se não houver workers disponíveis para executar as tarefas, a instância principal assume a execução em vez de enviar tudo para o Redis.
Ou seja: neste ponto, você ainda não está usando o queue mode de fato. Para isso, o próximo passo é criar e subir os workers.
Com o processo principal já configurado, o próximo passo é definir o banco PostgreSQL. Ele é opcional, mas recomendado para uso em produção, já que o SQLite não foi feito para lidar bem com volumes maiores de execução. A boa notícia é que subir um Postgres via Docker é bem rápido.
sudo nano docker-compose.yml
postgres:
image: postgres:15
container_name: n8n-postgres
restart: always
environment:
POSTGRES_USER: n8n
POSTGRES_PASSWORD: <sua_senha>
POSTGRES_DB: n8ndb
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:sudo nano.env
DB_TYPE=postgresdb DB_POSTGRESDB_HOST=postgres DB_POSTGRESDB_PORT=5432 DB_POSTGRESDB_DATABASE=n8ndb DB_POSTGRESDB_USER=n8n DB_POSTGRESDB_PASSWORD=<sua_senha>
Em seguida, suba os containers novamente:
docker compose up -d
Para conferir se o banco PostgreSQL está funcionando, rode:
docker exec -it n8n-postgres psql -U n8n -d n8ndb \dt
Opcionalmente, você pode agora excluir o SQLite:
rm ~/.n8n/database.sqlite rm ~/.n8n/*.sqlite*
Importante! Se a variável da chave de criptografia não estiver definida na sua instância principal, o n8n pode gerar uma chave nova ao recriar arquivos de configuração. Para evitar isso (e não correr o risco de perder o acesso a credenciais já salvas), defina N8N_ENCRYPTION_KEY no(s) arquivo(s) de ambiente usados pelos containers, garantindo consistência e estabilidade.
Quando o n8n entra no queue mode, ele depende de processos worker dedicados para buscar tarefas no Redis e executá-las. Vamos configurar o primeiro worker.
cat ~/.n8n/config
Copie o valor de encryptionKey – você vai usá-lo nas variáveis de ambiente dos workers.
sudo nano.env.worker
N8N_LOG_LEVEL=debug N8N_LOG_OUTPUT=console EXECUTIONS_MODE=queue N8N_RUNNERS_ENABLED=true OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true N8N_ENCRYPTION_KEY=<your_encryption_key> QUEUE_BULL_REDIS_HOST=redis QUEUE_BULL_REDIS_PORT=6379 DB_TYPE=postgresdb DB_POSTGRESDB_HOST=postgres DB_POSTGRESDB_PORT=5432 DB_POSTGRESDB_DATABASE=n8ndb DB_POSTGRESDB_USER=n8n DB_POSTGRESDB_PASSWORD=<your_password>
sudo nano docker-compose.yml
n8n-worker:
image: n8nio/n8n
restart: always
command: worker
env_file:
- .env.worker
depends_on:
- redis
- postgresdocker compose up -d n8n-worker
Importante! Se o valor de N8N_ENCRYPTION_KEY não estiver definido para a instância principal, o n8n pode gerar uma chave nova ao recriar arquivos de configuração. Para evitar inconsistências (e possíveis problemas com credenciais salvas), defina N8N_ENCRYPTION_KEY tanto no arquivo .env quanto no .env.worker.
Para rodar mais workers, use o parâmetro scale:
docker compose up -d --scale n8n-worker=3

Para testar se o modo de fila n8n está funcionando, execute alguns workflows de teste ou ative um workflow com agendamento. Neste exemplo, usamos um workflow simples configurado para rodar a cada 10 segundos.

Depois de alguns minutos, volte ao terminal e verifique os logs dos workers:
docker logs <nome-do-worker> -f
Você deverá ver algo parecido com isto:

Os principais pontos a serem observados são registros como “Worker started execution <number>”, que indicam que o n8n está obtendo tarefas do broker de mensagens com sucesso.
E pronto! Você configurou com sucesso o modo de fila n8n e ele agora está pronto para lidar com suas cargas de trabalho.
Manter o queue mode bem ajustado é essencial para garantir desempenho e estabilidade ao longo do tempo. Alguns pontos importantes para acompanhar no dia a dia:
Se você notar que algum container está no limite ou apresentando lentidão, é hora de escalar. Você pode fazer isso executando o comando `docker compose up -d –scale service=numero`.
Considerando a capacidade de hardware oferecida pelo VPS da Hostinger para n8n, rodar de 2 a 3 workers costuma ser um ponto de partida seguro. Dependendo do volume e da complexidade das automações, também é possível operar com 5 ou mais workers sem problemas.
Caso você comece a enfrentar limitações de infraestrutura, algumas alternativas a considerar são:
Rodar o n8n em queue mode libera um novo nível de escalabilidade, estabilidade e controle sobre a execução dos workflows. Ao separar o agendamento das tarefas da execução em si e delegar o processamento para workers dedicados, você reduz bastante o risco de gargalos de desempenho.
Com este guia, você configurou o queue mode, subiu os workers e aprendeu como monitorar e escalar o sistema em um VPS da Hostinger. À medida que suas automações crescerem, será possível escalar horizontalmente adicionando mais workers ou até separar Redis e PostgreSQL em servidores dedicados.
Quer levar suas automações ainda mais longe? Invista em um sistema de monitoramento mais robusto, implemente soluções de orquestração mais avançadas e explore todo o potencial do n8n.
O queue mode é uma configuração do n8n que separa o disparo dos workflows da execução propriamente dita usando uma fila de tarefas, normalmente baseada em Redis. Nesse modelo, a instância principal apenas envia as execuções para a fila, enquanto processos worker dedicados buscam e executam os jobs de forma assíncrona. Essa separação aumenta a escalabilidade e a estabilidade em ambientes distribuídos ou com alta carga.
Para ativar o queue mode, defina a variável de ambiente EXECUTIONS_MODE como queue nos arquivos de configuração da instância principal e dos workers. Também é necessário configurar o Redis para a fila e, opcionalmente, ativar variáveis como OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS e QUEUE_HEALTH_CHECK_ACTIVE.
O queue mode oferece melhor escalabilidade e uso mais eficiente dos recursos. Ao transferir a execução dos workflows para workers dedicados, o processo principal deixa de ser um ponto único de gargalo. Isso melhora o tratamento de erros, permite processamento assíncrono e resulta em um sistema mais rápido e estável, especialmente em cenários com alta demanda.
Semua konten tutorial di website ini telah melalui peninjauan menyeluruh sesuai padrões editoriais e valores da Hostinger.