Resumo
Estou enfrentando crashes OOM reproduzíveis no n8n Cloud Starter com payloads muito pequenos (~1-2 MB binários). O ponto de crash flutua entre o nó Code e AI Agent em execuções com a mesma entrada, o que sugere fortemente flutuação de recursos de worker compartilhado, em vez de um bug no código do usuário.
O mesmo workflow JSON funciona perfeitamente em self-hosted (Docker, host com 8 GB) — mais de 30 execuções sem nenhum crash.
Ambiente
- Plano: Cloud Starter
- Instância:
verma-digital.app.n8n.cloud - Versão n8n: 2.20.7 (Cloud)
- Nó:
@n8n/n8n-nodes-langchain.agentv1.8 - Modelo:
gpt-4.1-mini
Teste reproduzível — workflow minimal com 8 nós
Manual Trigger
→ Code "Prepare Test Data"
(buscar cada URL via helpers.httpRequest({encoding:'arraybuffer'})
+ helpers.prepareBinaryData, emite 1 item por arquivo com binário)
→ Switch by MIME (PDF / Image / Fallback)
→ Extract from PDF (somente branch PDF) → Merge (append, 3 entradas)
→ Code "Aggregate"
(coletar items em uma única saída: json.text + binary.data_0,
data_1, ... para AI Agent)
→ AI Agent (passthroughBinaryImages: true)
→ OpenAI Chat Model
Sem memória Postgres, sem tools, sem save subworkflows. Tão minimal quanto possível enquanto ainda reproduz o problema.
Fico feliz em compartilhar o workflow JSON completo.
Resultados dos testes
| Entrada | Binary total | Resultado |
|---|---|---|
| 2 ícones pequenos (webp) | ~40 KB |  Sempre tem sucesso |
| 2 PDFs pequenos (176 + 63 KB) | ~240 KB | Sempre tem sucesso |
| 1 PDF (2,6 MB, 5 páginas) | ~2,6 MB |  Crashes |
| 2 imagens (1,56 MB + 810 KB webp) | ~2,4 MB | Crashes |
O limite está em algum lugar entre ~240 KB e ~2,4 MB de binário total em uma única execução. O crash acontece mesmo com um único binário de 2,6 MB (apenas uma chamada helpers.httpRequest), então isso não é um vazamento multi-fetch cumulativo.
A parte interessante — ponto de crash não determinístico
Mesma entrada exata, mesmo workflow, mesmo caminho de execução:
- Execução 1: crash no nó Code
Prepare Test Data(durantehelpers.httpRequest/prepareBinaryData) - Execução 2: crash no nó AI Agent (durante processamento base64 de
passthroughBinaryImages) - Execução 3: crash no nó Code novamente
- (etc.)
Ambos os modos de crash produzem o mesmo erro na UI:
Execution stopped at this node
n8n may have run out of memory while running this execution.
“Other info” expandido mostra apenas versão n8n + timestamp. Nenhum stack trace visível.
Se fosse um bug no código do usuário, o crash seria determinístico no mesmo nó em cada execução. O fato de o ponto de crash flutuar com entrada idêntica sugere fortemente pressão de recursos de worker compartilhado.
Teste de controle — self-hosted funciona bem
Importei o mesmo workflow JSON para n8n self-hosted (Docker, n8n 2.20.7, host com 8 GB), com os mesmos serviços externos (Supabase, OpenAI).
Resultado: mais de 30 execuções em todos os cenários que falhavam acima — zero crashes. Incluindo um PDF de 4,7 MB + 2 imagens grandes simultaneamente.
Isso isolava a causa à infraestrutura Cloud, não ao workflow ou ao meu código.
Perguntas
-
Alguém mais enfrentou isso no Cloud Starter? Especificamente OOM intermitente com payloads de sub-MB a low-MB em workflows usando binary fetch + AI Agent passthroughBinaryImages?
-
Existe um orçamento de memória por execução não documentado no Starter que seja menor que a memória de worker de 1 GB anunciada? Crash observado em ~2 MB binários está três ordens de magnitude abaixo disso.
-
O
helpers.httpRequest({encoding:'arraybuffer'})ouprepareBinaryDatatem overhead de memória conhecido além do tamanho do buffer? -
Há um problema conhecido com LangChain Agent v1.8
passthroughBinaryImagesaumentando memória para entradas > 1 MB? -
Fazer upgrade para Pro mudaria significativamente a situação, ou a mesma infraestrutura compartilhada afetaria Pro também?
Eu realmente preferiria ficar no Cloud (queremos evitar o overhead de manutenção de self-hosting), mas agora Starter não é estável para nosso caso de uso.
Fico feliz em fornecer:
- Workflow JSON completo
- IDs de execução com falha (para o time n8n extrair logs do lado do servidor)
- Pontos de dados de teste adicionais (payloads menores, bisection, etc.)
Obrigado por qualquer insight!