N8N com 1 milhão de execuções por dia: o que eu aprendi escalando
Numa campanha de marketing com WhatsApp, SMS e e-mail pra milhares de clientes, eu bati 1 milhão de execuções num dia no n8n community, gratuito, sem comprar licença. Não é tutorial. É o que deu certo e o que deu errado em um ano de n8n em produção na minha empresa: as camadas que você vai subindo quando precisa escalar.
🎧 PREFERE OUVIR? · 17 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 16 minutos e meio no canal @josimarjmv em 20 de maio de 2026. Eu avisei logo no começo que não ia fazer tutorial, e acabei falando demais. Assista e leia junto: aqui embaixo eu conto a mesma coisa por escrito e ponho o que eu fui conferir depois na documentação do n8n e do Redis.
o n8n gratuito escala, mas não numa VM só. Numa VM na nuvem eu bati num teto diário que eu não passava. Com o modo queue distribuído eu cheguei a 1 milhão de execuções num dia, sem licença paga. Antes do modo queue, aumente os workers e estoure a VM. Pra escalar de verdade: no mínimo três VMs, storage e Redis compartilhados, workers separados do main e do webhook, um proxy com load balance e health check, Postgres e Redis em NVMe com backup, webhook no lugar de subworkflow, imagem própria com versão travada e arquivo no S3, nunca no disco local.
De onde eu falo
Isto aqui é teste real, oficial, dentro do nosso sistema, da nossa empresa. A gente tem instalação do n8n community, a free, gratuita. Eu sou open source first. E a minha empresa é bootstrap: não recebi dinheiro externo. Cada licença que eu deixo de comprar é conta que eu não pago no fim do mês.
E eu sou do hardware. Sou escovador de bit. Os meus storages têm HD mecânico, SSD e NVMe; só não mexo com fita ainda, que é o glacial que as nuvens usam pra backup. Por isso, quando eu falo de escalar n8n, eu vou descer até o disco. Muita gente para na tela do workflow.
Do Make ao n8n: a fatura que dispara
Antes do n8n eu conheci o Make, já faz uns três anos. Fiquei doido quando conheci aquela ferramenta. Automatizava tudo. Só que é igual token de IA: você começa a usar devagarinho, beleza. A hora que bota pra produção, o pau quebra e a fatura dispara. Eu cheguei a gastar 200 dólares num mês com o Make. Falei: chega, tem alguma coisa errada.
Aí descobri o n8n e subi o Docker basicão. Comecei a usar, e chegou num ponto em que eu precisava executar 20, 30, 40, 50 mil requisições no dia.
O teto de uma VM só
Uma VM com n8n tem limite. Pra rodar coisa pra você, funciona. Dá até pra criar uns workflows, deixar pronto e duplicar a VM pra outro usuário: é uma forma de escalar e vender. Mas escalar dentro do mesmo n8n é outro processo.
Eu bati num limite diário que eu não passava. Não lembro o número exato; se eu não me engano, foram 27 mil por dia, e isso em ambiente de nuvem, não na minha máquina local. Pra comparar: num vídeo passado eu perguntei pro Yuri, que roda n8n pro e-commerce dele, e ele faz uns 3 mil por dia. Pra ele, uma VM resolve com folga.
Pra mim não resolveu. Na campanha de marketing, com mensagem de WhatsApp, SMS e e-mail pra milhares de clientes, a gente bateu 1 milhão de execuções num dia. Execução, não workflow: é a quantidade de vezes que ele roda. No dia em que eu gravei, sem campanha ativa, estava em uns 150 mil nos últimos 7 dias. Quando você faz coisa ativa, proativa, dispara. E tudo isso escalado de forma gratuita, sem comprar licença do n8n.
Contêiner rodando não é n8n funcionando
A primeira coisa que eu aprendi: n8n em casa é uma coisa, n8n na nuvem é outra. E se o que você roda é sensível, você precisa de monitoramento. Da VM, e do health check do n8n: se ele está vivo.
Presta atenção nas camadas, porque é exatamente isso que vai subindo quando você escala:
- O contêiner rodando é uma coisa.
- O contêiner rodando e o n8n funcionando é outra.
- Rodando, funcionando e conectado ao Redis é outra.
- Rodando, funcionando, conectado ao Redis e com o storage funcionando é outra.
Se o seu monitoramento só olha a primeira linha, ele vai te dizer que está tudo verde enquanto as execuções morrem. Sobre o que eu mando registrar pra não ficar no escuro, eu escrevi em sem log você está no escuro.
Uma VM só? Não ligue o modo queue
"Ah, mas eu vou usar o modo queue." Pra que você vai colocar modo queue, que é o modo distribuído, se você só tem uma VM? Aumenta a quantidade de workers. Tem a variável de ambiente no próprio n8n: põe 10, 12 workers e estoura a sua VM antes de pensar em modo queue.
Porque quando você vai pro distribuído, começa o problema. Escalar na horizontal é difícil pra quem não entende de infraestrutura e arquitetura. Pra quem entende, não é lá grande dificuldade. Mas olha o que entra na conta:
- No mínimo umas três VMs, pra escalar de fato.
- Storage compartilhado entre elas, com os arquivos do n8n.
- O mesmo Redis pra todas, porque todas têm que consultar os mesmos jobs.
- Workers separados do main, o principal (pode ter mais de um main), e do webhook. Se você chegou no nível de escalar, você usa webhook pra alguma coisa.
- Um proxy na frente, tunado pra fazer load balance e health check: não mandar requisição pra quem não está saudável e não jogar tudo num lugar só.
Esse é o desenho que eu também conto em n8n em modo queue: por que eu uso S3, que nasceu de uma pergunta sobre esta gravação. E antes de escalar qualquer coisa, eu olho a aplicação: autoscale não salva aplicação mal feita.
Fui conferir na documentação do modo queue do n8n em 20 de outubro de 2026, e ela bate com o que eu vivo: a concorrência de cada worker vem do parâmetro concurrency, que por padrão é 10 (o n8n recomenda 5 ou mais); com vários processos de webhook você precisa de um load balancer; e o n8n não recomenda pôr o main no pool do balanceador, porque a interface de edição fica lenta.
Postgres: backup, limpeza e NVMe de verdade
Eu sempre usei Postgres no n8n. E aí você tem que lembrar de três coisas:
- O Postgres pode cair. Tenha backup dele. Em nome de Deus: backup, backup.
- Configure a limpeza dos logs de execução antigos, senão depois de muito tempo você não aguenta nem apagar o banco. Conferi em 20/10/2026: a documentação de dados de execução diz que a limpeza vem ligada por padrão e apaga execuções com mais de 336 horas (14 dias), ajustável por variável de ambiente. Com 1 milhão por dia, faça a conta do que cabe em 14 dias.
- Banco em disco rápido, NVMe. Não dá pra instalar banco de dados num SSDzinho e moer tudo lá dentro.
E aí começa outro problema. Você conferiu se o hardware em que a sua VM foi montada é NVMe mesmo? Conferiu se quem está te vendendo cloud está te vendendo NVMe ou um SSD M.2? A galera otimiza com força. Executa o comandinho e confere. Sabe aquela VM que você sobe e fala "não tem performance nenhuma, está estourando"? Pode ser isso.
Tem mais uma camada. Você não tem acesso ao kernel da VM alugada pra tunar, então já começa perdendo. E Docker não é bare metal: o provedor sobe uma VM, num hypervisor (Proxmox, VMware, o que for), e instala o Docker dentro. Uma camada no meio que joga fora uns 8, 9, 10% de performance. Por isso eu gosto de saber onde a minha máquina roda; contei a minha conta em pare de pagar VM na nuvem.
Redis: se ele cair, o n8n para
No Redis você pode pôr um Sentinel ou pode pôr um só. Se puser um só, precisa de monitoramento muito rígido, porque se o Redis cair, trava tudo: o n8n para de funcionar. Aí você tem que personalizar a imagem pra programar uns retries automáticos.
Sentinel, o n8n não tinha nativo quando eu gravei. Duas semanas antes eu tinha olhado: tinha pull request pedindo pra integrar no oficial, e não integraram. Deve ser feature enterprise. Pagar a conta, né? Mas tem maneira extraoficial: dá pra fazer um Sentinel no proxy, uma gambiarrazinha que funciona bem.
Nota de cronologia. Gravei isso em maio. Em 20 de outubro de 2026 eu conferi de novo a página de variáveis do modo queue: ela tem a opção pra Redis Cluster (QUEUE_BULL_REDIS_CLUSTER_NODES) e nenhuma pra Sentinel. E diz que, se o Redis ficar indisponível, o n8n espera 10 segundos por padrão antes de encerrar. Ou seja: o meu conselho de monitorar o Redis como se fosse o coração continua de pé.
E faça backup do Redis. Eu configuro o Redis em append, salvando em arquivo. Como ele é um banco em memória, é muito rápido, mas o arquivo tem que ir pra NVMe também, gravado de forma assíncrona, não bloqueante, senão dá problema. A documentação de persistência do Redis chama isso de AOF; o padrão de gravação em disco dele é uma vez por segundo (appendfsync everysec).
Réplica não é worker, e você precisa enxergar o consumo
Dá pra pôr mais de um worker na mesma VM sem problema. Agora, a quantidade de réplicas (contêiner do Docker ou Pod do Kubernetes, tanto faz) é diferente da quantidade de workers. Você tem uma réplica e, dentro dela, a quantidade de workers: quantos jobs ela roda ao mesmo tempo.
Pra acertar esse número você precisa de observabilidade: conforme roda, quanto consome de CPU, memória e disco, que são os três principais. E GPU, se você tem algum job que usa. Sem medir, você está chutando.
E segurança: tem firewall aí, ou a empresa que você está contratando já tem um? Os seus webhooks têm token pra não dar problema?
A dica de ouro: webhook, não subworkflow
Pra escalar o n8n você obrigatoriamente tem que usar webhook. Não dá pra ficar usando subworkflow, meu filho: é bloqueante. Quando o subworkflow demora, ele trava o que você precisa fazer, e você não escala na horizontal.
Subworkflow é pra workflow finito e rápido. Demorou? Cria outro job pra outra coisa, mantém o estado e vincula o estado do primeiro workflow com o segundo, pra colher o status final lá na frente.
Trave a versão da imagem e crie a sua
Quando for escalar o n8n, trave a versão da imagem, senão você está no pau da goiaba. Não coloca latest toda vez que for buildar, porque o pesadelo do n8n em modo queue chama update.
Toda vez que eu atualizo, eu tenho problema: ID de workflow, pedido de permissão. E olha que a gente já fez de todas as formas que eles mandam. Nas duas últimas vezes, quebrou. Na última, eu já fui preparado: subi o backup do banco de dados, e ninguém nem viu que eu tinha atualizado. Pra mim, restaurar o backup é mais rápido do que brigar com a migração.
E crie a sua própria imagem. Pra escalar você vai instalar umas ferramentas adicionais nela de qualquer jeito. A imagem é o seu lote, é a sua escritura. Amanhã a imagem pública pode sumir, e o seu pod que sobe puxando direto do registro público não sobe mais. Aí você fica na gambiarra de comitar imagem local no desespero. Já evita a fadiga: faz o seu build, a sua imagem, e acabou. Tem recurso novo? Vai ser útil pra você? Então atualiza. Não vai? Atualizar pra quê?
Na gravação eu não lembrei o nome do repositório. Conferi na documentação de instalação com Docker: a imagem oficial é n8nio/n8n, e a própria documentação mostra como puxar uma versão específica, com a tag do número da versão. A mesma documentação do modo queue pede que main e workers rodem a mesma versão no setup com vários mains, o que é mais um motivo pra não deixar cada máquina puxar o latest que quiser. Eu faço o mesmo com o GitLab da casa, como contei em GitLab próprio com 300 microsserviços.
Storage distribuído e S3: nada no disco local
Por último, o problema que a gente mais teve: storage. Quando você escala, os arquivos centrais do n8n precisam estar distribuídos. Pode ser o storage da sua nuvem montado em todas as máquinas, um cluster (o povo usa muito no Proxmox), um Ceph, um compartilhamento NFS. Sobre Ceph eu contei a minha conta em Ceph com S3 gratuito.
Agora, o arquivo que o fluxo movimenta (pegou o anexo do e-mail pra analisar, por exemplo) você para de baixar pro disco local. Usa o modo HTTP e sobe pro S3. Na hora de processar, processa em memória, em qualquer contêiner que pegar a tarefa, gera o resultado e faz upload de novo. Stateless. Você não vai ter problema com arquivo se usar um endpoint S3. Tem gente que chama S3 de nutelinha; nesse caso não é: é essencial pra escalar qualquer negócio.
Por que eu continuo usando n8n
Com tudo isso, o n8n é uma ferramenta fantástica e me ajuda muito. Eu tenho n8n no marketing, no monitoramento de alguns serviços específicos e na criação de uns planos muito específicos.
Muitas vezes é mais rápido eu duplicar o workflow do que codar. Quando eu vou fazer uma aplicação, na mão ou com Claude Code, tem que codar na máquina, subir pro staging, validar proxy, SSL, firewall, subir pra produção, fazer o merge e funcionar. No n8n eu pulo boa parte disso. O preço é o que eu contei aqui: na hora de escalar, a infraestrutura é sua. Se você quer aprender a montar essa base de rede, disco e servidor, é o que a gente vê na Imersão de Infraestrutura.
| Camada | O erro que eu vejo | O que eu faço |
|---|---|---|
| Uma VM só | Ligar modo queue sem ter outra máquina | Aumento os workers até estourar a VM |
| Monitoramento | Olhar só se o contêiner está de pé | Health check em camadas: processo, Redis, storage |
| Postgres | Banco em SSD comum, sem backup, sem limpeza | NVMe conferido, backup e limpeza de execuções |
| Redis | Um Redis só, sem vigia | Sentinel no proxy ou monitoramento rígido, AOF em NVMe e backup |
| Fluxos | Subworkflow demorado | Webhook, com estado vinculado entre os workflows |
| Imagem | latest a cada build | Imagem própria, versão travada, backup antes de atualizar |
| Arquivos | Download pro disco local | Storage distribuído e S3 por HTTP |
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
Quantas execuções por dia o n8n gratuito aguenta?
Depende de como você monta. Numa VM só na nuvem eu cheguei num teto diário que eu não passava, se eu não me engano por volta de 27 mil por dia. Com o n8n community escalado em modo queue, sem comprar licença, eu bati 1 milhão de execuções num dia, numa campanha de marketing com WhatsApp, SMS e e-mail pra milhares de clientes. Hoje, sem campanha ativa, fica na casa de 150 mil em 7 dias.
Vale a pena ligar o modo queue numa VM só?
Não. Se você tem uma VM só, aumenta a quantidade de workers pela variável de ambiente do próprio n8n e estoura a VM antes de pensar em modo queue. Modo distribuído é pra quando você vai ter, no mínimo, umas três VMs, com storage e Redis compartilhados e um proxy na frente.
O que eu preciso pra escalar o n8n na horizontal?
No mínimo umas três VMs, storage compartilhado entre elas, o mesmo Redis pra todas consultarem os mesmos jobs, Postgres, workers separados do main e do webhook, e um proxy na frente tunado pra load balance e health check, que não mande requisição pra quem não está saudável.
Por que o Postgres e o Redis do n8n têm que ficar em NVMe?
Porque banco de dados num SSDzinho mói tudo. O Postgres tem que estar num disco rápido, com backup e com a limpeza das execuções antigas configurada. O Redis grava o arquivo de persistência em disco de forma assíncrona e também precisa de NVMe pra não virar gargalo. E confira se o que te venderam como NVMe é NVMe mesmo.
O n8n suporta Redis Sentinel?
Quando eu gravei, em maio de 2026, não tinha nativo; tinha pull request pedindo e não entrou. Conferi de novo em 20 de outubro de 2026: a página de variáveis do modo queue lista a opção pra Redis Cluster e nenhuma pra Sentinel. Se você roda um Redis só, precisa de monitoramento rígido, porque se o Redis cair o n8n para. Dá pra fazer um Sentinel no proxy, ou personalizar a imagem pra ter retry automático.
Subworkflow ou webhook pra escalar o n8n?
Webhook. Subworkflow é bloqueante: quando ele demora, segura o fluxo que chamou e você não escala na horizontal. Subworkflow é pra coisa finita e rápida. Demorou, cria outro job, mantém o estado e vincula o primeiro workflow ao segundo pra colher o status final.
Por que travar a versão da imagem do n8n?
Porque o pesadelo do n8n em modo queue chama update. Toda vez que eu atualizo eu tenho problema de ID de workflow e de permissão, e nas duas últimas vezes quebrou. Então eu crio a minha própria imagem, com a versão travada e as ferramentas que eu preciso, e só atualizo quando o recurso novo vai ser útil pra mim. Nada de latest a cada build.
Como guardar arquivo no n8n escalado?
Num storage distribuído, nunca no disco local. Os arquivos centrais do n8n ficam num storage compartilhado (Ceph, NFS, o que a sua nuvem tiver), e o arquivo que o fluxo movimenta, tipo anexo de e-mail, vai e volta de um S3 por HTTP. Processa em memória, gera o resultado e sobe de novo. Stateless.
Baseado na gravação do canal @josimarjmv publicada em 20/05/2026 (16min31s), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: um ano de n8n community em produção na empresa, bootstrap e open source first; o Make, conhecido uns três anos antes, e os 200 dólares num mês; a necessidade de 20 a 50 mil requisições por dia; o teto diário numa VM em nuvem, que eu situo em 27 mil por dia sem ter certeza; os cerca de 3 mil por dia do Yuri; o 1 milhão de execuções num dia na campanha de WhatsApp, SMS e e-mail e os 150 mil em 7 dias no dia da gravação; as camadas do health check; não usar modo queue com uma VM só; o desenho com três VMs, storage e Redis compartilhados, workers separados do main e do webhook e proxy com load balance e health check; Postgres com backup, limpeza de logs e NVMe; conferir se o NVMe vendido é NVMe; a perda de 8 a 10% de performance na camada de virtualização; Redis com Sentinel ou monitoramento rígido, a falta de Sentinel nativo e o Sentinel no proxy; Redis em append, com backup e arquivo em NVMe; réplicas versus workers e observabilidade; firewall e token nos webhooks; webhook no lugar de subworkflow; imagem própria com versão travada e os problemas de update; storage distribuído e S3 por HTTP; onde eu uso o n8n hoje.
Apuração minha (20/10/2026): o parâmetro concurrency dos workers com padrão 10 e recomendação de 5 ou mais, a necessidade de load balancer com vários processos de webhook, a recomendação de não pôr o main no pool e a exigência de mesma versão em main e workers no setup com vários mains estão em Enable queue mode, documentação do n8n. A variável de Redis Cluster, a ausência de variável de Sentinel e o tempo de espera de 10 segundos com o Redis indisponível estão em Queue mode environment variables. A limpeza de execuções ligada por padrão, com 336 horas, está em Manage execution data. O nome da imagem oficial (n8nio/n8n) e o pull de versão específica estão em Install with Docker. O AOF e o appendfsync everysec estão em Redis persistence.