Is 4GB RAM Enough for n8n with AI Agent Nodes? Real Limits

Yes, 4GB of RAM is enough to run self-hosted n8n with AI Agent nodes, as long as the language model itself lives on someone else’s servers. If your Chat Model sub-node points at OpenAI, Anthropic, Google Gemini, Groq or OpenRouter, the agent on your machine is doing little more than shuffling JSON around and making HTTPS calls, and a Docker install of n8n plus a small Postgres database usually sits well under 1.5GB even while workflows are firing. Where 4GB falls apart is the moment you try to run the model locally through Ollama, load a big dataset into the In-Memory Vector Store node, or push large PDFs and images through an agent’s tools.

So the honest answer is a conditional yes: fine for API-driven agents on a modest workload, not fine for a self-contained local AI stack.

Yes, 4GB works when the model runs on an API, and here’s why the number is that low

The thing that trips people up is assuming an “AI Agent” node runs AI. It doesn’t. n8n’s Advanced AI nodes are a wrapper around LangChain, and the agent node orchestrates: it builds a prompt, sends it to whatever Chat Model sub-node you attached, reads the response, decides whether to call a tool, calls it, then loops until it has an answer.

All of that reasoning happens on the model provider’s hardware. Your server holds the conversation history, the tool definitions, and the JSON that moves between nodes. That’s kilobytes in most workflows, sometimes a few megabytes if you’re feeding in long documents.

So the RAM question isn’t really about the agent at all. It’s about n8n itself, the database behind it, and whatever else you’ve stacked onto the same box.

What the AI Agent node actually holds in memory

A typical agent workflow keeps three things resident during an execution:

The chat history from your Memory sub-node. If you’re using Simple Memory, that buffer lives inside the n8n process itself, which means it disappears on restart and it grows with every turn of a long conversation. Postgres Chat Memory or Redis Chat Memory push that data out to a database instead, which is the better move on a small server.

The tool schemas and their outputs. An agent with eight tools attached holds eight sets of definitions plus whatever each tool returns. An HTTP Request tool that pulls back a 5MB API response is a 5MB memory spike, and the agent may call it several times in one run.

The intermediate node data. n8n keeps the output of every node in an execution in memory until the run finishes, so a workflow with twenty nodes is holding twenty result sets at once.

Note: Simple Memory is stored in the instance’s own memory. If you ever move to queue mode with multiple workers, conversations can land on different workers and the history won’t line up. Switch to Postgres or Redis memory before you scale out, not after.

Where the memory really goes on a self-hosted n8n box

RAM problems on small n8n servers almost never come from the agent logic. They come from four other places.

Binary data. By default n8n keeps binary data (files from Google Drive, email attachments, generated images, PDFs you’re chunking for a vector store) in memory. A workflow that loops through 50 PDFs at 10MB each will try to hold a lot of that at once. Setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem moves it to disk and is the single biggest win on a 4GB box.

The database. SQLite is the default and it’s light, but it gets slow and bloated once your execution history grows into the tens of thousands of rows. Postgres is the better long-term choice and adds roughly 150 to 300MB of resident memory on a small instance.

Execution history. Every saved execution stores the full data of every node. Turn on pruning or your disk fills, your database swells, and the editor UI crawls.

Everything else on the server. Ubuntu plus Docker sits somewhere around 400 to 700MB before n8n starts. Add a reverse proxy like Traefik or Nginx Proxy Manager and you’re at maybe 500 to 800MB of baseline usage. That’s a fifth of a 4GB box gone before a single workflow runs.

The pattern here is the same one you see with any sluggish self-managed install: the application itself is rarely the villain, it’s the stack piled around it.

4GB is not enough if you want the language model on the same server

This is where most “is 4GB RAM enough for n8n with AI Agent nodes” questions actually come from. People see the Ollama Chat Model node in n8n’s node list, assume it’s a drop-in alternative to OpenAI, and buy the cheapest VPS they can find.

Local models are the most memory-hungry thing you can put on a server. A quantized model has to be loaded into RAM (or VRAM) in full before it can generate a single token, and it stays there while it’s warm.

Can you run n8n and Ollama together on 4GB of RAM?

Barely, and only with very small models. Ollama’s project documentation states you should have at least 8GB of RAM available to run 7B models, 16GB for 13B models and 32GB for 33B models. Those numbers are for the model alone, before you subtract the OS, Docker, n8n and Postgres.

On a 4GB server you’d have maybe 2.5GB of headroom after n8n and the system take their share. That limits you to models in the 1B to 3B range at 4-bit quantization: things like Llama 3.2 1B, Llama 3.2 3B, Qwen2.5 1.5B or Phi-3 Mini, which typically land between roughly 1GB and 2.5GB of memory each.

The catch is that small models are poor at agent work. Tool calling and structured output are exactly the tasks where 1B and 3B models fall over, and n8n’s AI Agent node depends on the model reliably returning a correctly formatted tool call. You’ll get parsing errors, hallucinated tool names, and loops that never terminate.

It’s technically possible and practically frustrating.

Also worth saying plainly: CPU-only inference is slow. Without a GPU, a 3B model on a shared vCPU might produce a handful of tokens per second. An agent that makes four tool calls in one run can take minutes to finish, and n8n’s webhook timeouts don’t care how patient you are.

Note: if you genuinely want local AI, budget 16GB RAM minimum and preferably a GPU instance. Running the models locally to save money on API credits rarely works out cheaper once you price the hardware. A few hundred thousand tokens per month through a small API model like GPT-4o mini or Gemini Flash costs less than the price difference between a 4GB and a 16GB VPS.

Self-hosted vector stores want their own memory budget

Retrieval-augmented workflows add a second memory consumer. n8n’s In-Memory Vector Store node does exactly what the name says: the embeddings sit inside the n8n process. Fine for a few hundred chunks in a demo, dangerous for a knowledge base of thousands of documents.

Qdrant running as a container on the same host will happily use 500MB to 1GB+ depending on collection size and whether you keep vectors in RAM or on disk. Postgres with the pgvector extension is gentler because it uses the database’s existing memory settings, which is why it’s the sensible pick on small servers.

The lightest option is a managed vector database. Pinecone, Supabase and Qdrant Cloud all have free or cheap tiers, and they move that entire memory load off your machine. On 4GB, that’s the choice I’d make every time.

n8n’s published requirements are lower than most people assume

n8n is a Node.js application, and Node applications are not especially heavy at rest. A fresh n8n container with no active executions generally sits in the low-to-mid hundreds of megabytes. Under load it climbs with the size of the data flowing through the workflow, then settles again after garbage collection.

The official self-hosting pages at n8n’s documentation site cover Docker, npm and Kubernetes installs along with the environment variables that control memory behaviour. Check there for current minimums, because the project ships updates weekly and the numbers move.

Here’s a realistic planning budget for a 4GB VPS running an API-based AI agent setup. These are approximate working figures for sizing decisions, not guarantees:

That leaves genuine headroom on 4GB. Add Ollama with any usable model and the total blows past 4GB immediately.

One more sizing note that people forget: n8n has a default maximum payload size of 16MB for incoming requests, controlled by N8N_PAYLOAD_SIZE_MAX. If you raise that to accept larger webhook payloads, you’re also raising the amount of data a single request can drop into memory. Think about it the same way you’d think about upload limits on a hosting plan: the ceiling exists for a reason.

Here’s how to make 4GB actually hold up under real AI workflows

These are ordered by impact. If you only do the first three, you’ve solved most of the problem.

1. Move binary data to disk. Set N8N_DEFAULT_BINARY_DATA_MODE=filesystem in your environment file and restart the container. Files then get written to n8n’s storage directory instead of being held in the Node heap. This alone stops most out-of-memory crashes on small servers.

2. Turn on execution pruning. Set EXECUTIONS_DATA_PRUNE=true and give it limits with EXECUTIONS_DATA_MAX_AGE (in hours) and EXECUTIONS_DATA_PRUNE_MAX_COUNT. Without this, your database grows forever and every UI action gets slower. Two weeks of history is plenty for most people.

3. Stop saving successful executions in full. EXECUTIONS_DATA_SAVE_ON_SUCCESS=none keeps error data (which you need) and discards success data (which you rarely read). Debugging gets harder, so flip it back temporarily when you’re building something new.

4. Cap concurrency. N8N_CONCURRENCY_PRODUCTION_LIMIT restricts how many production executions run at once. Set it to 3 or 5 on a 4GB box. Ten AI workflows triggering simultaneously is how a healthy server becomes a dead one.

5. Set the Node heap ceiling deliberately. NODE_OPTIONS=--max-old-space-size=2048 tells Node to cap its old-space heap at 2GB, which leaves room for the OS and database instead of letting Node grab everything and get killed by the kernel. n8n’s docs mention this setting specifically in the context of memory errors.

6. Add swap. Two gigabytes of swap on a 4GB VPS won’t make anything fast, but it turns a hard crash into a slow moment. Most VPS images ship without swap enabled, so you’ll need to create it yourself.

7. Skip queue mode. Queue mode means Redis plus one or more worker containers, each a separate Node process with its own memory. On 4GB, running everything in the default main process is the right call. Queue mode is a 8GB-and-up decision.

8. Batch your loops. Use the Loop Over Items node with a sensible batch size rather than passing 5,000 items into a single node. Smaller batches mean smaller peaks.

While you’re configuring the server, sort out HTTPS properly too. n8n webhooks and OAuth credentials for tools like Gmail or Slack need a valid certificate on a real domain, so getting a certificate sorted belongs on the setup checklist alongside the memory settings. Plenty of people point a spare subdomain at their n8n instance rather than buying a separate domain for it.

The warning signs that your 4GB server has run out

Memory problems in n8n look like bugs at first, which is why people chase the wrong fix for days.

Exit code 137. If docker ps -a or your logs show a container that stopped with 137, the Linux kernel’s out-of-memory killer terminated it. That’s not an n8n bug. That’s your server running out of RAM.

Executions that vanish. A workflow shows as running, then the whole container restarts and the execution is gone with no error message. Classic OOM kill mid-run.

“JavaScript heap out of memory.” This one appears in the logs and means Node hit its heap ceiling. Either the workflow is handling too much data at once, or --max-old-space-size is set too low for what you’re asking it to do.

Editor UI getting slower over weeks. Usually a bloated execution table rather than RAM. Pruning fixes it.

The whole VPS becoming unreachable. When swap thrashing starts, SSH gets slow before it stops answering. Reboot from your provider’s control panel, then fix the concurrency limit.

Before you assume it’s memory, run docker stats while a heavy workflow executes and watch the numbers move. If n8n peaks at 900MB on a box with 2GB free, memory isn’t your problem and you should look at the workflow logic instead.

Keep restore points handy while you’re experimenting with any of this. Snapshot before big config changes, the same way you’d want daily restore points on hand for any production site.

4GB vs 8GB vs 16GB: what each size actually gets you

If your workflows are API-based agents doing things like reading emails, summarising them, calling a CRM and posting to Slack, 4GB is genuinely fine and you’d be paying for headroom you don’t use at 8GB. If you’re processing hundreds of documents a day or running anything locally, start at 8GB and expect to move up.

The decision looks a lot like the one people face when moving off a shared plan: the right time to size up is when you can point at a specific limit you keep hitting, not when someone on a forum says you should.

Common mix-ups about n8n memory and AI nodes

Mix-up: The AI Agent node needs a powerful server because AI is compute-heavy.

Reality: With an API-based Chat Model, the heavy compute happens at OpenAI or Anthropic. Your server handles orchestration and HTTP requests, which is light work. The agent node is one of the cheaper things in a typical n8n workflow, memory-wise.

Mix-up: More RAM makes n8n workflows run faster.

Reality: RAM stops crashes, it doesn’t add speed. AI workflow latency is dominated by how long the model provider takes to respond and how many tool-calling rounds the agent makes. Adding RAM to a server that isn’t running out of it changes nothing.

Mix-up: n8n Cloud and self-hosted n8n use the same resources, so cloud plan limits tell you what you need.

Reality: n8n Cloud plans are priced on executions and active workflows, not gigabytes. Their limits tell you nothing useful about how much RAM your own VPS needs. Size your server on data volume and concurrency instead.

Mix-up: Docker’s memory limits protect the host, so a 4GB box is safe.

Reality: Setting mem_limit on the n8n container means Docker kills n8n when it exceeds the limit rather than the kernel killing something random. Your workflows still fail. It’s containment, not a solution.

What this means for your setup

If you’re building agents on top of OpenAI, Claude, Gemini or Groq, buy the 4GB VPS, apply the eight settings above, and move on with your life. That configuration handles the overwhelming majority of the AI automations people actually build: lead qualification, email triage, content pipelines, customer support routing, scheduled research jobs. You’ll have room to spare.

If local AI is the point of the project, don’t try to squeeze it. A 4GB box running Ollama will give you a bad experience with a weak model and you’ll conclude that n8n agents don’t work, when the real issue was the hardware. Either budget 16GB with a GPU or use a cheap API model and put the savings into a bigger n8n instance.

And if you’re somewhere in the middle, start at 4GB. VPS plans scale up in a few minutes without a rebuild on most providers, so you can watch docker stats for a fortnight and make the call on evidence. Buying 16GB “in case” is the most common way people overspend on this.

Hostinger’s KVM VPS range is a reasonable place to run this. The plans include a one-click n8n template so you’re not hand-writing docker-compose files on day one, and full root access means you can set every environment variable mentioned above. Check the current KVM VPS pricing here and use the code hHostCouponHub at checkout, which currently takes up to 85% off the first term (renewal rates are higher, as always).

Frequently asked questions

How much RAM does n8n need at minimum?

n8n itself will start and run workflows on 1GB, and light non-AI automations work on 2GB with SQLite. For anything involving AI Agent nodes, Postgres and daily production use, 4GB is the sensible floor. Below that you’ll spend more time fixing crashes than building workflows.

Can I run n8n with AI agents on a 2GB VPS?

You can, with API-based models, filesystem binary mode, aggressive pruning and a concurrency limit of 1 or 2. It works for a handful of low-volume workflows. Add a second heavy workflow or a large file and you’ll meet exit code 137 quickly, so treat 2GB as a testing environment rather than production.

Does the n8n AI Agent node use my server’s CPU for inference?

No, unless you’ve attached a local Chat Model sub-node like Ollama or LM Studio. With OpenAI, Anthropic, Google, Mistral or OpenRouter credentials, all inference happens on their infrastructure and your CPU handles request formatting, JSON parsing and tool execution.

What’s the smallest model that works reliably with n8n’s AI Agent node?

Tool calling is the constraint. Models in the 7B to 8B class with proper function-calling support (Llama 3.1 8B, Qwen2.5 7B, Mistral 7B variants) are roughly the entry point for agent behaviour that doesn’t break constantly, and those need 8GB+ of RAM per Ollama’s guidance. Anything smaller is fine for plain text generation and unreliable for agents.

Should I use queue mode on a small n8n server?

No. Queue mode adds Redis and separate worker processes, each with its own memory footprint, which is the wrong trade on 4GB. Stay in the default main process, cap concurrency, and revisit queue mode when you’re on 8GB or more and genuinely hitting parallel execution limits.

Start with 4GB, wire your agents to an API model, set the binary data mode and pruning variables before you build anything serious, and watch docker stats for a couple of weeks before you decide whether you need more. If you’re ready to spin one up, grab the VPS deal with code hHostCouponHub and get your instance running today.

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.