AI Agent + Code node OOM crash with ~1-2MB binary on Cloud Starter — non-deterministic crash point, zero crashes on self-hosted

Questions
,
1

Summary

I’m hitting reproducible OOM crashes on n8n Cloud Starter at very small payloads (~1-2 MB binary). The crash point fluctuates between Code node and AI Agent across runs with the same input, which strongly suggests shared-worker resource fluctuation rather than a user-code bug.

Same workflow JSON runs perfectly on self-hosted (Docker, 8 GB host) — 30+ executions with zero crashes.

Environment

  • Plan: Cloud Starter
  • Instance: verma-digital.app.n8n.cloud
  • n8n version: 2.20.7 (Cloud)
  • Node: @n8n/n8n-nodes-langchain.agent v1.8
  • Model: gpt-4.1-mini

Reproducible test — minimal 8-node workflow

Manual Trigger
  → Code "Prepare Test Data"
      (fetch each URL via helpers.httpRequest({encoding:'arraybuffer'})
       + helpers.prepareBinaryData, emits 1 item per file with binary)
  → Switch by MIME (PDF / Image / Fallback)
  → Extract from PDF (PDF branch only)  → Merge (append, 3 inputs)
  → Code "Aggregate"
      (collect items into single output: json.text + binary.data_0,
       data_1, ... for AI Agent)
  → AI Agent (passthroughBinaryImages: true)
  → OpenAI Chat Model

No Postgres memory, no tools, no save subworkflows. As minimal as it gets while still reproducing the issue.

I’m happy to share the full workflow JSON.

Test results

Input Total binary Result
2 small icons (webp) ~40 KB :white_check_mark: Always succeeds
2 small PDFs (176 + 63 KB) ~240 KB :white_check_mark: Always succeeds
1 PDF (2.6 MB, 5 pages) ~2.6 MB :cross_mark: Crashes
2 images (1.56 MB + 810 KB webp) ~2.4 MB :cross_mark: Crashes

The threshold is somewhere between ~240 KB and ~2.4 MB total binary in a single execution. The crash happens even with a single 2.6 MB binary (only one helpers.httpRequest call), so this is not a cumulative multi-fetch leak.

The interesting part — non-deterministic crash point

Same exact input, same workflow, same execution path:

  • Run 1: crashes at Code node Prepare Test Data (during helpers.httpRequest / prepareBinaryData)
  • Run 2: crashes at AI Agent node (during passthroughBinaryImages base64 processing)
  • Run 3: crashes at Code node again
  • (etc.)

Both crash modes produce the same UI error:

Execution stopped at this node
n8n may have run out of memory while running this execution.

“Other info” expanded only shows n8n version + timestamp. No stack trace visible.

If this were a user-code bug, the crash would be deterministic at the same node every run. The fact that the crash point fluctuates with identical input strongly suggests shared worker resource pressure.

Control test — self-hosted is fine

I imported the same workflow JSON into self-hosted n8n (Docker, n8n 2.20.7, 8 GB host), with the same external services (Supabase, OpenAI).

Result: 30+ executions across all the failing scenarios above — zero crashes. Including a 4.7 MB PDF + 2 large images simultaneously.

This isolates the cause to Cloud infrastructure, not the workflow or my code.

Questions

  1. Has anyone else hit this on Cloud Starter? Specifically intermittent OOM with sub-MB to low-MB payloads in workflows using binary fetch + AI Agent passthroughBinaryImages?

  2. Is there an undocumented per-execution memory budget on Starter that’s lower than the 1 GB advertised worker memory? Observed crash at ~2 MB binary is three orders of magnitude below that.

  3. Does helpers.httpRequest({encoding:'arraybuffer'}) or prepareBinaryData have known memory overhead beyond the buffer size?

  4. Is there a known issue with LangChain Agent v1.8 passthroughBinaryImages spiking memory for inputs > 1 MB?

  5. Would upgrading to Pro meaningfully change the situation, or is the same shared infrastructure going to affect Pro as well?

I’d really prefer to stay on Cloud (we want to avoid the maintenance overhead of self-hosting), but right now Starter is not stable for our use case.

Happy to provide:

  • Full workflow JSON
  • Failed execution IDs (for n8n team to pull server-side logs)
  • Additional test data points (smaller payloads, bisection, etc.)

Thanks for any insight!

3

@sawsew467 ur diagnosis is right — Starter has a tight per-execution memory cap and ur stacking binary + base64-encoded images (passthroughBinaryImages inflates ~33%) + Code node aggregation, all live in memory at the same time. self-hosted with 8GB just has way more headroom. quickest workaround without upgrading plans: drop passthroughBinaryImages and pass image URLs to the agent instead — the model fetches them, ur execution memory stays flat. how many images per execution typically? changes whether url-pass works or u need a different shape entirely.

4

Hi @sawsew467

The crashes are happening because the n8n Cloud Starter plan has a much smaller memory limit than you expected—only 320 MB of RAM, not 1 GB. When you process files (like PDFs or images), n8n doesn’t just use the file’s actual size; it creates multiple copies in the background and converts them into a text-based format (Base64) for the AI to read, which balloons the memory usage. Because you are operating right at the edge of this limit, the system crashes randomly at whichever node happens to push the memory over the limit during that specific run.

Since your workflow runs perfectly on your self-hosted server with more RAM, your code is not the problem—the cloud “container” is simply too small for this task. To fix this, the most effective solution is to upgrade to a Pro plan, which provides significantly more memory (up to 1.2 GB). Alternatively, you could avoid uploading the files directly to the AI Agent and instead provide the AI with a web link to the file, which bypasses the memory-heavy conversion process entirely.