How to fix workflow crashes on large responses from Gemini in n8n?

A practical fix is to stop letting n8n hold the entire large Gemini response in memory. Instead, you stream, chunk, or immediately off‑load the response (for example, save to a file/object storage/database) so that the n8n execution doesn’t try to pass a multi‑MB JSON blob from node to node. n8n crashes on large model outputs not because of Gemini, but because the workflow engine tries to serialize huge data into its execution DB or RAM. The stable pattern is: reduce the payload early, chunk it, or store it outside n8n and only pass references.

 

Why the workflow crashes

 

When Gemini returns a very large text or JSON, n8n tries to do several things that blow up RAM or the execution database:

• Store the full node output in its internal execution store (Postgres/SQLite or n8n cloud storage).
• Pass the whole JSON object to the next node (n8n copies data between nodes).
• Sometimes the Editor UI tries to render the result, which can also freeze/crash.

Even a few megabytes can be enough to make n8n unstable. The fix is not “increase limits”; the fix is “don’t pass huge objects through n8n.”

 

Production‑grade ways to fix it

 

Here are the patterns that actually work in production without crashing n8n:

• Ask Gemini to return a small structured response instead of long text. Use system instructions like “Respond only with a short JSON object containing X, Y, Z.”
• Stream or chunk the output using Gemini’s streaming API (through HTTP Request node), then accumulate or store chunks one by one instead of a single huge result object.
• Write large text to storage immediately (S3, GCS, Supabase, local filesystem via Write Binary File) and replace the node output with only a file URL or small metadata object.
• Use a Function node to trim the payload by removing unnecessary fields.
• Disable saving large data by transforming the result before the next node. n8n must never hold multi‑MB strings in its execution context.

 

Concrete example: trimming in a Function node

 

If Gemini returns a huge text but you only need a summary or a piece of it, filter it immediately:

// Remove large fields and keep only what you need
const full = $json.text;        // large Gemini output
const trimmed = full.slice(0, 5000); // keep only first 5k chars

return [
  {
    trimmedText: trimmed
  }
];

 

This prevents the next node from receiving a massive blob.

 

Concrete example: off‑loading to S3/GCS

 

If you must keep the full text, do not keep it inside n8n. Store it externally:

// Example for preparing binary data to upload
const largeText = $json.text;
return [
  {
    json: {},
    binary: {
      data: {
        data: Buffer.from(largeText, "utf8").toString("base64"),
        mimeType: "text/plain",
        fileName: "gemini-output.txt"
      }
    }
  }
];

Then connect this to an S3/GCS Upload node and only return a URL like:

return [
  {
    fileUrl: $json.url // returned by S3/GCS node
  }
];

 

Concrete example: using Gemini streaming

 

If you call Gemini via HTTP Request instead of the built‑in node, use streaming (if supported in your SDK/API version) so n8n receives smaller chunks:

// Pseudocode for HTTP Request in n8n (body is real)
{
  "model": "gemini-pro",
  "stream": true,
  "messages": [
    { "role": "user", "content": "Write 30k words." }
  ]
}

You then process each streamed chunk individually, storing or trimming before passing to the next node.

 

Tips that avoid crashes

 

• Do not open large node outputs in the Editor UI. Even if the backend survives, the UI may freeze.
• Use split‑in‑batches if you’re generating multiple large messages to avoid stacking large objects.
• Ensure execution mode is “regular” not “manual” when handling big data. Manual mode holds everything in memory.
• Set workflow to “don’t save data” or “save minimal data” (in workflow settings) if large data cannot be avoided.

 

A clean, safe pattern that never crashes

 

This is the approach I use in real production for large LLM responses:

• Call Gemini.
• Immediately store the full raw output in object storage.
• Return only a small JSON object with { fileUrl, tokens, summary }.

This keeps n8n light and stable while still letting you work with arbitrarily large responses.

 

In short: n8n crashes because it tries to hold huge Gemini output in memory. The fix is to trim, chunk, or off‑load the response immediately so n8n only passes small JSON between nodes. This is the only stable production pattern.