How Much RAM Does n8n Need for Multiple AI Agents?

Running n8n with multiple AI agents needs a lot more memory than a standard automation setup, and the honest baseline is 4 GB of RAM for two or three light agents, 8 GB once you're running several agents in parallel with tool calls and memory nodes, and 16 GB if you're chaining agents, handling document ingestion, or serving multiple users at once. The n8n docs list 2 GB as a workable minimum for a self-hosted instance with light usage, but that figure predates the AI Agent node and assumes simple trigger-and-action workflows. AI agents change the arithmetic because every agent run holds conversation history, tool schemas, intermediate JSON, and often an entire document payload in Node.js heap memory at the same time, and n8n's default heap ceiling of roughly 1.7 GB will throw an out-of-memory crash long before your server's physical RAM is exhausted.

If you're sizing a VPS today and you plan to run more than one agent, start at 8 GB and treat 4 GB as the floor for testing only.

Why AI Agents Eat So Much More RAM Than Regular n8n Workflows

A normal n8n workflow moves small JSON items between nodes and then discards them. An AI agent holds far more in memory at once, and it holds it for longer.

Here's what actually sits in RAM during a single agent execution:

The conversation history, whether that's a Window Buffer Memory node, Postgres chat memory, or Redis. Buffer memory in particular keeps the last N exchanges live in the Node.js process.

The intermediate output of every reasoning step. An agent that loops five times before answering has five rounds of model output, tool responses, and re-serialised context sitting in the execution data.

Full binary or text payloads if the agent touches files. A 30-page PDF pulled through an Extract from File node before it reaches the agent can balloon to several times its disk size once it's a JSON string in memory.

Then there's the part most people miss. n8n stores execution data for the entire run, not just the current node. In a workflow with a loop and 200 items, each item's agent output gets retained until the execution finishes. That's why a workflow that runs fine on 10 test records dies on 500.

Note: n8n runs on Node.js, and Node's V8 engine caps heap memory independently of how much RAM your machine has. The default old-space limit sits around 1.7 GB. Giving your VPS 16 GB does nothing for agent workflows unless you also raise NODE_OPTIONS=--max-old-space-size to match.

This is the single most common reason people report crashes on "plenty of RAM."

How Much RAM You Actually Need For Multiple AI Agents in n8n

The number depends on three things: how many agents run at the same time, whether they process files, and whether you're also self-hosting the model.

Two To Three Light Agents: 4 GB

Fine for a chatbot agent plus a classifier agent plus a small routing agent, all calling an external API like OpenAI or Anthropic. Text-only, short conversations, no document parsing. Expect n8n itself to idle around 300 to 500 MB and spike to 1 GB or so during concurrent runs.

The remaining headroom covers the OS, Postgres if you're running it locally, and reverse proxy.

At 4 GB you're already tight if you also want Redis for queue mode. It works, but you're one badly-sized payload away from a restart.

Four To Eight Agents With Tools And Memory: 8 GB

This is the sweet spot for most people building real multi-agent systems. Think a supervisor agent delegating to specialists, each with two or three tools, using Postgres chat memory, handling maybe 20 to 50 executions an hour.

8 GB gives you room to run n8n in queue mode with two workers, a local Postgres, Redis, and still have 2 GB spare for the OS and traffic spikes. Set --max-old-space-size=3072 per worker process and you'll rarely see a heap crash on text workloads.

Heavy Multi-Agent Work, RAG, Or Document Pipelines: 16 GB

Once you add a vector store, document loaders, embedding generation, or agents that read spreadsheets and PDFs, memory use climbs fast and unpredictably. Chunking a 200-page document, generating embeddings, and holding both the raw text and the vectors in an execution puts real pressure on the heap.

16 GB also becomes necessary if you run three or more n8n workers, or if several team members trigger agent workflows simultaneously through chat triggers.

Self-Hosting The Model Too: 32 GB And A GPU Conversation

If you're running Ollama alongside n8n on the same box, the model weights dominate everything else. A 7B parameter model at 4-bit quantisation wants roughly 5 to 6 GB of RAM on its own, before n8n gets a look in. A 13B model roughly doubles that.

Running Llama 3.1 8B plus a multi-agent n8n stack on 16 GB is possible but sluggish, since you'll be fighting for memory bandwidth and CPU on inference.

My honest take: keep inference on a separate machine or use an API. Co-hosting the model and the orchestrator on one small VPS is the fastest route to a frustrating debugging session.

The Node.js Heap Limit Is Usually The Real Problem, Not Your Server

I want to spend a moment here because it explains most of the confusion around n8n memory requirements.

When n8n crashes with JavaScript heap out of memory or the container restarts silently mid-execution, people upgrade their VPS. Then it crashes again. The reason is that V8 enforces its own limit on the JavaScript heap, and on 64-bit systems that default sits near 1.7 GB regardless of physical RAM.

To raise it, set the environment variable before n8n starts:

NODE_OPTIONS=--max-old-space-size=4096

That's in megabytes, so 4096 gives Node 4 GB of heap. A rough rule I use: set it to about 60 to 70 percent of the RAM you've allocated to that container or machine, leaving the rest for the OS, Postgres, and non-heap Node memory (buffers, native modules).

In Docker, add it to your environment block:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - NODE_OPTIONS=--max-old-space-size=4096
    deploy:
      resources:
        limits:
          memory: 6G

Note: raising the heap limit past your available RAM makes things worse, not better. Node will happily try to allocate memory the machine doesn't have, and the Linux OOM killer terminates the process with no useful error message. Keep the heap ceiling comfortably below the container limit.

If you're weighing up whether your current plan can take this at all, the signals that point toward a dedicated server rather than a shared box are worth reading before you commit budget.

Configuration Changes That Cut n8n Memory Use Immediately

Before you buy more RAM, these settings often reclaim more than an upgrade would. I've listed them roughly in order of impact.

1. Prune execution data aggressively. Set EXECUTIONS_DATA_PRUNE=true, EXECUTIONS_DATA_MAX_AGE=168 (hours, so one week), and EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000. Agent executions produce large payloads, and an unpruned database bloats both disk and the memory used when loading execution lists in the UI.

2. Stop saving successful production execution data. EXECUTIONS_DATA_SAVE_ON_SUCCESS=none keeps error data while dropping the successful runs you'll never look at. For agent workflows this is a big win because each saved run includes full model outputs.

3. Turn off manual execution saving during testing. EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false while you're iterating on agent prompts.

4. Switch to queue mode. Set EXECUTIONS_MODE=queue with Redis, then run separate worker containers. Each worker gets its own heap, so one runaway agent execution kills a worker instead of your whole instance. This is the single best structural change for multi-agent reliability.

5. Limit worker concurrency. Use --concurrency=5 or lower on each worker. Default concurrency lets too many agent runs share one heap. Fewer, slower, alive beats faster and crashing.

6. Set a payload size limit. N8N_PAYLOAD_SIZE_MAX defaults to 16 MB. Lowering it forces failures early on oversized document inputs instead of letting them consume the heap.

7. Disable unused nodes. NODES_EXCLUDE trims what n8n loads at startup. Modest gain, but free.

Check n8n's own self-hosting configuration reference for the current variable names, since some have been renamed across major versions and the defaults shift between releases.

Workflow Design Choices That Matter More Than Hardware

Two teams can run identical hardware and get completely different results. The difference is usually workflow structure.

Split Big Agent Workflows Into Sub-Workflows

Call an Execute Sub-workflow node instead of building one giant agent workflow. Each sub-workflow execution gets its own data scope, and once it returns only the output travels back to the parent. A 15-node agent chain in one workflow holds everything at once.

Split into three sub-workflows, and memory releases between stages.

Batch Loops, Don't Bulk-Process

Use the Loop Over Items node with a batch size of 1 to 5 for agent calls. Feeding 500 items straight into an AI Agent node means 500 model responses accumulating in one execution. Batching keeps peak memory flat regardless of input size.

Trim Data Before It Reaches The Agent

Put a Set or Code node before every agent and pass only the fields the agent needs. I've seen workflows pipe a full 40-field API response into an agent that used two fields. That's 38 fields of context stored in every reasoning loop, and it inflates token cost as well as memory.

Prefer Postgres Or Redis Chat Memory Over Buffer Memory

Window Buffer Memory keeps history inside the Node process. Postgres Chat Memory and Redis Chat Memory push it out to a database and pull back only what's needed. For any agent with more than a handful of turns, external memory is the better default.

It also survives restarts, which buffer memory does not.

Cap Agent Iterations

Set Max Iterations on your agent nodes, usually 5 to 10. An agent stuck in a reasoning loop with a misbehaving tool will keep appending to its context until something breaks. A hard cap turns an outage into a failed execution.

One Agent With Many Tools, Or Many Agents?

For memory, one agent with several tools is usually lighter than several agents each with its own memory node and its own context. Multi-agent setups earn their keep when the tasks genuinely differ, when you need different models per task, or when you want isolated failure. Don't split into five agents for the sake of the architecture diagram.

Common Mix-Ups About n8n AI Agent Memory Requirements

Mix-up: n8n Cloud plans have RAM limits you need to size the same way as a VPS.

Reality: n8n Cloud is priced on executions and active workflows, not RAM, and the underlying resources are managed for you. What you hit on Cloud instead is execution timeouts and payload limits. Self-hosting is where RAM sizing becomes yours to solve.

Mix-up: More RAM automatically fixes out-of-memory errors.

Reality: The V8 heap ceiling is separate from physical RAM. Without raising --max-old-space-size, extra RAM sits unused while Node crashes at the same 1.7 GB point. Adjust both together.

Mix-up: The AI model's memory needs and n8n's memory needs are the same thing.

Reality: If you're calling OpenAI, Anthropic, Google, or any hosted API, the model runs on their infrastructure and costs you nothing in local RAM. Only self-hosted inference through Ollama, LM Studio, or similar puts model weights on your machine.

Mix-up: Vector databases need to live on the same server.

Reality: Pinecone, Qdrant Cloud, and Supabase vector stores are external. Only self-hosted Qdrant, Chroma, or pgvector consume your RAM, and pgvector in particular wants generous shared buffers.

Fixing The Memory Errors You'll Actually Run Into

Problem: FATAL ERROR: Reached heap limit Allocation failed, JavaScript heap out of memory

Fix: Raise NODE_OPTIONS=--max-old-space-size to about two-thirds of available RAM and restart. If it recurs at the higher limit, the workflow is the problem, not the ceiling. Add batching.

Problem: The container restarts mid-execution with no error in the n8n logs.

Fix: The host OOM killer terminated the process. Check dmesg | grep -i oom or your Docker memory limit. Your heap ceiling is probably set above what the container is allowed to use.

Problem: Memory climbs steadily over days and never drops, even when idle.

Fix: Almost always unpruned execution data plus a growing database. Turn on pruning, set the max age, and restart. Also check whether a chat trigger workflow is holding sessions open.

Problem: Agent workflows are slow rather than crashing, and CPU sits near 100 percent.

Fix: This isn't RAM. Self-hosted inference, embedding generation, or heavy Code nodes are CPU-bound. Add vCPUs or move inference off the box.

Similar symptoms show up on oversubscribed shared hosting, which is often behind unexplained slowdowns on managed WordPress plans too.

Which Hosting Setup Fits Multi-Agent n8n

You need a VPS or dedicated resources, not shared hosting. Shared plans don't give you Docker, root access, or the ability to set Node environment variables, all of which multi-agent n8n depends on.

For a realistic starting point: a 2 vCPU, 8 GB VPS with 100 GB of SSD handles a serious multi-agent setup with queue mode and a local Postgres. That's the configuration I'd recommend to anyone moving past the experimentation stage. Hostinger's KVM 4 plan sits in that bracket and includes a one-click n8n template, which saves an hour of Docker Compose work if you'd rather not hand-roll it.

The technical guidance on Hostinger's own limits is worth a look if your agents will handle uploads.

Storage matters less than people expect, though agent execution data grows faster than normal workflow data. Budget 50 GB minimum and enable pruning. If you want a safety net, check how far back daily restore points reach on your chosen plan before you rely on them.

One thing to sort out early: put n8n behind a proper domain with a valid certificate, because webhooks and chat triggers need HTTPS to work with most external services. Most hosts include certificates now, and it's worth confirming whether certificates come bundled rather than assuming. Running agents on a subdomain like automation.yourdomain.com keeps things tidy, and setting up subdomains on the same host takes a couple of minutes.

What This Means For Your Setup

If you're just starting with two or three text-only agents, 4 GB gets you going and you can always resize a VPS later. Set the heap limit, turn on execution pruning, and get comfortable with the memory profile of your own workflows before you spend more.

If you already know you're building a supervisor-and-specialists system, or anything with document processing, go straight to 8 GB and enable queue mode from day one. Retrofitting queue mode onto a running instance is more work than starting with it, and the isolation it gives you between workers is what keeps a multi-agent setup stable under load.

Watch your actual numbers rather than guessing. docker stats during a heavy agent run tells you more in thirty seconds than any sizing table, including this one. If peak usage sits above 70 percent of your allocation regularly, size up. Note that hosting promotional pricing usually applies to the first billing term, so check the renewal rate before you commit to a long plan.

If an 8 GB VPS is where you're landing, you can grab a Hostinger VPS at up to 85% off with code hHostCouponHub and get the n8n template running the same afternoon.

Frequently Asked Questions

Can n8n run multiple AI agents on 2 GB of RAM?

One light agent will run on 2 GB, but multiple agents won't hold up reliably. You'll hit heap crashes as soon as two agent executions overlap or a single agent processes anything larger than a short text input. Treat 2 GB as a demo environment.

How much RAM does each n8n AI agent use per execution?

There's no fixed figure, because it scales with context size, tool count, and payload. A short text-only agent run typically uses 50 to 200 MB of heap, while an agent processing a multi-page document can spike past 1 GB in a single execution. Measure your own workflows with docker stats rather than relying on averages.

Does n8n queue mode reduce RAM requirements?

It doesn't reduce total RAM use, but it changes how that memory is distributed and makes the system far more resilient. Each worker runs in its own process with its own heap, so one oversized agent execution kills a single worker rather than the whole instance. You'll want Redis running alongside, which adds a few hundred megabytes.

Do I need a GPU to run multiple AI agents in n8n?

Not if your agents call hosted models from OpenAI, Anthropic, Google, or similar, since inference happens on their servers. You only need a GPU if you're self-hosting models through Ollama and want acceptable response times. CPU-only inference works but is slow enough that most agent chains become impractical.

Get your heap limit set, pruning enabled, and queue mode running, and an 8 GB box will carry a genuine multi-agent n8n system without drama. If you're provisioning fresh hardware for it, Hostinger's VPS plans with code hHostCouponHub are the cheapest sensible route into that spec right now, and the n8n one-click template means you're deploying rather than configuring.

This page contains affiliate links. If you purchase through the links on this page, we may earn a commission, at no extra cost to you.