N8N em modo queue: por que eu uso S3 pra guardar os arquivos
Me perguntaram no canal: por que storage S3 no n8n? Porque quando eu escalo o n8n em três VMs, cada uma tem o seu disco, e o worker não acha o arquivo que o outro baixou. Aqui eu conto como eu centralizo tudo num S3 pelo nó HTTP, por que eu parei de usar Google Drive nos fluxos e o que eu aprendi quando levaram a nossa conta do Google.
🎧 PREFERE OUVIR? · 13 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 12 minutos e meio no canal @josimarjmv em 8 de junho de 2026. Assista e leia junto. Aqui embaixo eu conto a mesma coisa por escrito e ponho o que eu fui conferir depois: a documentação do n8n sobre modo queue e dados binários, a do Amazon S3 e o artigo 52 da LGPD.
eu uso S3 no n8n escalado porque o fluxo transaciona arquivo. Num ambiente único está tudo no mesmo disco e funciona. No modo queue espalhado em três VMs, o worker que pega a próxima tarefa vai consultar o disco dele e o arquivo não está lá. Então eu não gravo mais nada no volume local: o fluxo sobe o arquivo pro S3, o outro workflow baixa do S3, manipula e salva o resultado no S3, tudo pelo nó HTTP com autenticação. S3 aqui é o protocolo, não só a nuvem da Amazon. E tem que ser um S3 que você controla e do qual você tem backup.
De onde eu falo
Vou dar minha carteirada antes. Eu sou arquiteto de sistema, de software e de hardware. Trabalho com infraestrutura pesada e cuido de data center no Brasil e nos Estados Unidos. Sou CEO raiz: boto a mão na massa e testo as coisas antes da minha equipe, ou junto com ela.
A gente vai azeitando tudo junto nesse mundo novo de inteligência artificial, que tem os dois extremos: o negacionista, que não acredita em nada, e o que acredita em tudo e quer demitir todo mundo pra botar IA no lugar. Está todo mundo aprendendo.
O que a gente não precisa aprender do zero é que o n8n é uma ferramenta fantástica. A pergunta que virou esta conversa chegou no canal depois que eu falei de 1 milhão de requisições por dia no n8n: "por que S3? Por que usar storage S3 nisso?". Eu expliquei por alto na hora e resolvi responder direito.
Pra quem é esta conversa, e pra quem não é
Se você roda o n8n naquele contêiner que sobe tudo de uma vez, no mesmo compose, com o Redis, o banco de dados e talvez o worker no mesmo lugar, isto não é pra você. Está tudo num local só, o arquivo está no disco e todo mundo enxerga.
É pra quem começou a escalar. Chega uma hora em que você fala: agora eu preciso rodar 200, 300 mil execuções. Aí entra o modo queue, que é o modo escalado do n8n, de forma horizontal. A documentação do n8n descreve as peças: o processo main, os workers, que são as instâncias que fazem o trabalho de verdade, os processadores de webhook e o Redis no meio como fila.
E é pra quem está começando nesse modo. O pessoal mais sênior não comete esse erro bobo. Mas eu recebi a pergunta várias vezes, então vale a pena deixar escrito.
Subir modo queue numa VM só não é escalar
Antes do S3, uma coisa que eu vejo muito. O sujeito sobe o n8n em modo queue numa VM só: três workers, um webhook, o main, tudo separadinho. E acha que escalou.
Você não escalou. Está tudo na mesma máquina. Nesse caso é melhor tunar o próprio n8n: mais workers, as variáveis de ambiente corretas, e usar o extremo até a VM bater 100% de uso. Não precisa de mais nada.
Escalar na horizontal é outra coisa. São três VMs, um proxy controlando tudo na frente e, em cada VM, três workers, o main e o webhook de forma redundante. É desse desenho que eu estou falando. Antes de escalar qualquer coisa eu olho a aplicação, e contei isso em autoscale não salva aplicação mal feita.
O boleto que o outro worker não acha
Vamos pegar uma automação de pagamento de conta. Ela tem que pegar o boleto e checar se está certo: o valor, a data de vencimento, se o fornecedor não mandou coisa errada. É a conciliação contábil com o fornecedor.
Pra conciliar, o fluxo baixa o boleto e transforma em texto, com as ferramentas nativas do n8n. Aí você faz um parser, padroniza tudo num JSON e compara com o JSON que você espera daquele fornecedor. Eu montei um fluxo assim pra mim, e ele está em automatizei o meu contas a pagar.
Se for tudo no mesmo workflow, beleza. Ele faz o download, o arquivo fica em memória ou no disco local, e ele lê os dados ali.
O problema aparece no passo seguinte. Agora eu preciso mandar o boleto pro financeiro agendar o pagamento. Quem faz isso é outro flow: um subworkflow, um webhook, um agente que você tenha feito. E esse outro precisa do mesmo boleto.
Quem está acostumado com o modo comum do n8n vai cometer o erro aqui: o segundo fluxo consulta o disco e falha. Com três VMs, quem pegou a tarefa pode ser um worker de outra máquina, com outro disco. E o pior é que não falha sempre. Às vezes funciona, às vezes não funciona. Arquivo está, arquivo não está.
Parêntese: fluxo de dinheiro não é lugar pra LLM
Na hora de comparar o boleto com o valor esperado, você pode fazer o parser ou pode jogar num LLM. Eu não sei se vale a pena. Se o seu fluxo é previsível, por que você vai usar LLM?
É a mesma conversa da galera vibe coder sobre usar um agente ou usar uma skill. Eu uso agente quando eu não tenho fluxo previsível. Uma busca em algum lugar da internet: o agente se vira, faz a busca e entrega. Um web scraping, que quebra toda hora, porque puseram captcha, porque o site mudou. Aí é agente.
No n8n é igual. Tem a hora do agente inteligente e tem a hora do fluxo estático. Quando a gente fala de dinheiro, nota fiscal e contabilidade, tem que ser fluxo previsível. LLM não é previsível assim. Por mais que você conecte o output parser obrigatório, ela erra. Eu tenho coisa em produção há muito tempo, e ela erra. Só com um modo thinking gigante a chance de erro fica bem baixinha, e isso é assunto pra outra conversa.
Por que eu parei de usar Google Drive no n8n
Pra resolver o arquivo que está e não está, muita gente já usa o Google Drive. Sobe pro Drive, baixa do Drive. Funciona.
Eu parei de usar Google Drive no n8n há um tempo, porque é um saco. Direto e reto o login expirava e eu tinha que ir lá conectar de novo. Pode ser que o Google não goste da minha aplicação, que não ache a nossa empresa confiável o suficiente. É questão de segurança do Google, chave, token. Só que você está contando com aquela automação, e a automação parou.
Aproveito pra dizer: automação não é dar o play e sumir. Uma vez por semana, pelo menos, a gente tem que tirar um tempinho pra olhar os fluxos e ver se está tudo certinho.
S3 é protocolo, não é só a Amazon
Tem um jeito que eu acho mais seguro e mais fácil. Talvez pra mim seja mais fácil porque eu tenho o meu próprio S3.
Quando eu falo S3, eu falo do protocolo S3. Eu não estou falando só do storage da Amazon. S3 é um protocolo de armazenamento de objeto. O protocolo é da Amazon, mas várias empresas e tecnologias fornecem. Se você quiser subir um S3 local só pra testar, dá. Pergunta pra sua IA como faz.
A lógica é a mesma do Google Drive. Peguei o arquivo, li o arquivo, subi pro S3. Acabou, o arquivo está seguro. Quando o fluxo passar a tarefa pra outro subworkflow, ele simplesmente consulta lá.
Como eu faço: tudo por HTTP, nada no disco local
A regra que eu sigo é uma só: tudo que for transação de arquivo não desce mais pro disco local. Sabe aquele volume que você monta no n8n, o de files? Eu não uso.
- Chegou o arquivo (o boleto, a nota, o que for): o fluxo faz o upload pro S3 pelo nó HTTP, com autenticação.
- O próximo workflow, subworkflow ou webhook não procura no disco. Faz o download do S3.
- Manipulou o arquivo: salva o resultado de volta no S3.
Pronto, é bem simples. É assim que eu resolvo o problema de leitura de arquivo quando o n8n escala na horizontal.
Por que o nó HTTP, e não um nó pronto? Porque tem provedor com homologação no n8n e tem provedor sem. Pelo HTTP eu uso qualquer S3, em qualquer lugar. Você pega o endpoint, o token, o bucket e a região e gera a URL pré-assinada. Depois faz o upload, em uma parte só ou em multiparte. Não é obrigatório usar o módulo nativo da AWS, da Azure ou do Google Cloud.
| Onde o arquivo fica | O que acontece com três VMs | O que eu faço |
|---|---|---|
| Disco local, o volume do n8n | Cada VM tem o seu. O worker da outra máquina consulta o disco e falha. Às vezes funciona, às vezes não. | Só em ambiente único. |
| Google Drive | Todo mundo enxerga o arquivo, mas o login expira e a automação para até alguém reconectar. | Parei de usar nos fluxos. |
| S3, de qualquer fornecedor que fale o protocolo | Um lugar só. Todo worker sobe e baixa por HTTP, com autenticação. | É o que eu uso, no meu próprio S3. |
O que a documentação do n8n diz, e eu fui conferir
Isto aqui é apuração minha, feita em 9 de outubro de 2026, depois da gravação. São três pontos que batem com o que eu vivo em produção.
- Na página de dados binários, o n8n diz que por padrão guarda o arquivo em memória, que o modo filesystem grava em disco e que o modo filesystem não é suportado com o modo queue. Quem usa queue tem que trocar pra outro modo.
- Na página de armazenamento externo, o n8n guarda os dados binários em S3 por conta própria, mas esse recurso está no self-hosted Business e Enterprise. Serviços compatíveis com S3 funcionam, sem suporte oficial.
- Nos nós, existe o nó S3 pra soluções que não são da AWS e um nó separado pra AWS S3.
Então são duas coisas diferentes. Uma é onde o n8n guarda, por dentro, o binário de cada execução. A outra é o que eu descrevo aqui: o seu fluxo subir e baixar o arquivo de propósito, num S3 que é seu. Essa segunda funciona em qualquer edição, com qualquer fornecedor, e o arquivo fica num lugar que você sabe onde é e de que você faz backup.
A conta do Google que me levaram
Eu falo de controle e de backup porque já apanhei. Vou te dar o exemplo catastrófico.
Em janeiro ou fevereiro de 2025, se eu não me engano, a conta do Google da nossa empresa foi invadida. Com todas as proteções de segurança ativadas. Não foi engenharia social. Foi login errado em máquina errada: pelo que eu me lembro, uma máquina Windows de um colaborador estava com vírus, algum trojan. Eu não lembro certinho dos detalhes.
E adivinha o que foi junto. A conta do Google Ads, a conta do YouTube, a conta do Google Drive.
Eu consegui recuperar. Sabe de que jeito? Judicial. Eu tive que entrar com processo contra o Google, explicando que o serviço é pago e que eu queria o meu backup de volta. Porque quando eu perdi todo o acesso e ligava pra pedir suporte, não tinha suporte.
Alguém vai dizer: mas eu tenho Google Workspace na minha empresa. Aí é diferente, o Workspace e os serviços empresariais têm um suporte à parte. Eu não uso Workspace. Eu estou falando de conta normal do Google, com vários serviços pagos atrelados. E a maioria das pessoas que estão subindo automação usa conta assim.
Por isso eu bato tanto em ter o dado na sua mão. Sobre backup de verdade, o que tem restore testado, eu escrevi em caso Abacate Pay: eu testo restore.
Vai vender automação? Backup e LGPD
Enquanto você sobe uma coisa pra testar, pra brincar com automação sua, o prejuízo é só seu. Quando você vai pro mercado vender, muda tudo.
Pega o exemplo do boleto. Cliente de contabilidade. A gente está falando de dados de brasileiros, a gente está falando de LGPD. Às vezes o vibe coder topa tudo por dinheiro. Ele tem que tomar alguns cuidados pra não comprometer a vida dele e o CNPJ dele.
"Ah, ninguém está multando ninguém com LGPD." Cara, uma vez só que você cai numa dessa, pode quebrar a empresa. Eu falo na gravação em 2% do faturamento bruto anual. O texto exato está no artigo 52, inciso II, da Lei nº 13.709/2018: multa simples de até 2% do faturamento da pessoa jurídica no Brasil no seu último exercício, excluídos os tributos, limitada a R$ 50 milhões por infração. E o artigo 46 da mesma lei manda adotar medidas de segurança pra proteger o dado pessoal de acesso não autorizado e de perda.
Então usa um S3 que você controla e de que você tem backup. Pode fazer o backup do S3 no Drive, ou do Drive no S3. Mas tenha sempre o backup desses arquivos.
É assim que você escala de forma segura e vende a automação que você criou sem dor de cabeça: nó HTTP, baixa o arquivo do S3, manipula no workflow, sobe de novo pro S3.
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
Por que usar S3 no n8n em modo queue?
Porque você vai transacionar arquivo dentro do fluxo. Num ambiente único, isolado, está tudo no mesmo disco e funciona. Quando eu escalo na horizontal, com três VMs, cada VM tem o seu disco, e o worker que pega a próxima tarefa precisa saber onde está o arquivo que o outro baixou. Às vezes o webhook e o main também. Então eu centralizo os arquivos num S3: sobe pra lá, lê de lá, salva o resultado lá.
Preciso de S3 se o meu n8n roda num contêiner só?
Não. Se você sobe tudo de uma vez no mesmo compose, com Redis, banco e worker no mesmo lugar, o arquivo está no disco e todo mundo enxerga. Essa conversa é pra quem começou a escalar e precisa rodar 200, 300 mil execuções com o modo queue espalhado em mais de uma máquina.
Subir o modo queue numa VM só já é escalar?
Não é. Se eu ponho três workers, um webhook e o main separados dentro da mesma VM, eu não escalei nada. Nesse caso é melhor tunar o próprio n8n, com mais workers e as variáveis de ambiente corretas, até a VM bater 100% de uso. Escalar na horizontal é ter três VMs, um proxy controlando tudo na frente e, em cada VM, workers, main e webhook de forma redundante.
S3 é só o da Amazon?
Não. Quando eu falo S3, eu falo do protocolo S3, que é um protocolo de armazenamento de objeto. O protocolo é da Amazon, mas várias empresas e tecnologias fornecem. Eu tenho o meu próprio S3. E dá pra subir um S3 local só pra testar.
Por que usar o nó HTTP em vez do nó nativo de S3?
Porque com HTTP eu uso qualquer S3, em qualquer lugar. Tem provedor que tem homologação no n8n e tem provedor que não tem. Pelo HTTP eu pego o endpoint, o token, o bucket e a região, gero a URL pré-assinada e faço o upload, seja em uma parte só ou multiparte. Não é obrigatório usar o módulo nativo da AWS, da Azure ou do Google Cloud.
Posso usar Google Drive no lugar do S3?
Pode, a lógica é a mesma: sobe o arquivo e o outro fluxo baixa de lá. Muita gente faz assim. Eu parei de usar Google Drive no n8n há um tempo porque direto e reto o login expirava e eu tinha que ir lá conectar de novo. Você está contando com a automação e ela parou. Pode ser que o Google não ache a minha aplicação confiável o suficiente. Pra mim, com S3 próprio, ficou mais seguro e mais fácil.
O n8n não guarda os arquivos em S3 sozinho?
Guarda, mas depende da licença. Fui conferir na documentação do n8n em 9 de outubro de 2026: o armazenamento dos dados binários em S3 está disponível no self-hosted nos planos Business e Enterprise, e outros serviços compatíveis com S3 funcionam, mas não têm suporte oficial. A mesma documentação diz que o modo filesystem não é suportado com o modo queue. O que eu conto aqui é outro caminho, que funciona em qualquer edição: o próprio fluxo sobe e baixa o arquivo no S3 pelo nó HTTP.
O que a LGPD tem a ver com automação no n8n?
Tudo, a partir do momento em que você vende a automação. Boleto de cliente de contabilidade é dado de brasileiro. Brincar com coisa sua é uma coisa, o prejuízo é só seu. Quando você vai pro mercado, você tem que ter backup e tem que respeitar a LGPD. A multa simples do artigo 52 vai até 2% do faturamento da empresa no último exercício, limitada a R$ 50 milhões por infração. Uma vez só que você cai numa dessa, pode quebrar a empresa.
Baseado na gravação do canal @josimarjmv publicada em 08/06/2026 (12min34s), 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: a pergunta recebida no canal depois de eu falar de 1 milhão de requisições por dia no n8n; pra quem a conversa é e não é; o modo queue numa VM só, que não é escalar; o desenho com três VMs, proxy na frente e workers, main e webhook redundantes; o exemplo do boleto na automação de pagamento de conta; a diferença entre fluxo previsível e agente, e a LLM que erra mesmo com output parser; o Google Drive com o login que expira; o meu próprio S3 e S3 como protocolo; a regra de não usar o volume local e fazer tudo pelo nó HTTP, com endpoint, token, bucket, região, URL pré-assinada e upload em uma parte ou multiparte; a invasão da conta do Google da empresa, que eu situo em janeiro ou fevereiro do ano anterior ao da gravação, sem lembrar de todos os detalhes, e a recuperação pela via judicial; o cuidado com backup e LGPD pra quem vende automação.
Apuração minha (09/10/2026): as peças do modo queue (main, workers, processadores de webhook e Redis) estão em Enable queue mode, documentação do n8n. A frase de que o modo filesystem não é suportado com o modo queue está em Handle binary data. A disponibilidade do armazenamento de dados binários em S3 no self-hosted Business e Enterprise, e a falta de suporte oficial a outros serviços compatíveis, estão em Use external storage. O nó S3 pra soluções que não são da AWS está em S3 node. URL pré-assinada e upload multiparte estão na documentação do Amazon S3: presigned URLs e multipart upload. A multa de até 2% do faturamento, limitada a R$ 50 milhões por infração, é o artigo 52, II, e as medidas de segurança são o artigo 46 da Lei nº 13.709/2018 (LGPD).