n8n's own hosting docs put its minimum server requirement at 2 CPU cores, 2GB RAM, and 20GB SSD storage. No GPU line item anywhere in that spec. Yet most n8n AI agent GPU deployment guides skip straight to renting an H100 for the whole stack, because the workflow tool and the model backend get sized as one thing when they're actually two.
That's the gap this post fixes. n8n is the orchestrator: it triggers workflows, calls nodes, and manages state. The GPU belongs to whatever LLM backend n8n's AI Agent node is calling, Ollama or a self-hosted vLLM endpoint, and that backend is the only part of the stack that needs to sit on rented GPU hardware. Get that split right and you stop paying GPU rates for a workflow engine that's happy on a $0.20/hr CPU node.
n8n AI Agent GPU Deployment: Why Teams Self-Host Instead of Using n8n Cloud
n8n ships as source-available software under a Sustainable Use ("fair-code") License it adopted in 2022, restricting commercial resale while keeping the platform fully self-hostable. That licensing choice is deliberate. As n8n founder and CEO Jan Oberhauser has put it, the design goal was that a user should be able to own their data, self-host, and avoid lock-in, no matter what happens in the outside world. Self-hosting isn't a workaround the community found, it's the design intent.
The Compliance and Data Residency Driver
Oberhauser has also been direct about the risk self-hosting is meant to hedge against: single-vendor AI dependency. He's pointed to boards now asking what happens if a model provider raises prices, gets acquired, or loses access in a given geography, the kind of dependency he says could "literally kill your company." For teams under GDPR, HIPAA, or sector-specific rules, that risk compounds: a workflow that routes customer data through a third-party API is a data residency question, not just a vendor question. Running n8n's AI Agent node against a local model closes that door entirely, since the conversation never leaves your infrastructure.
This is the same instinct behind n8n's growing enterprise base. n8n reports more than 3,000 enterprise customers, including Vodafone and Delivery Hero, at an implied average contract value near $13,300 a year. Self-hosted deployments are the entry point for the customers a cloud-only competitor structurally can't win: governments, banks, and defense-adjacent organizations where "call an external API" isn't an option regardless of price.
If your team is choosing between a no-code tool and a developer-first agent framework for this same self-hosted, compliance-driven use case, see our comparison of Temporal, Inngest, and Restate for durable agent workflows: those frameworks solve the same durability problem n8n solves, but for teams writing code rather than building visual workflows. n8n's audience is the no-code and citizen-developer side of that same self-hosting decision.
n8n's Growth Numbers Behind the Self-Hosting Trend
n8n's funding history tracks the same trajectory: a $1.5M Sequoia-led seed in 2020, a $12M Series A led by Felicis Ventures in April 2021, a €55M Series B in March 2025, and a $180M Series C in October 2025 led by Accel, with Nvidia's venture arm NVentures participating, at a $2.5B valuation. Total funding across all rounds sits at roughly $253.5M. The company reported $40M in annual recurring revenue as of July 2025.
The Nvidia venture participation is worth calling out on its own: an infrastructure investor is backing a workflow tool specifically because that tool routes real compute to GPU-backed model calls. That's the same self-hosting story playing out at the funding level that shows up in every individual deployment decision below.
n8n's AI Agent Node and Local LLM Support
n8n's AI capability runs through LangChain-based nodes, and the node you pick determines whether a local model can actually act as a tool-calling agent or just answer single-turn prompts.
Tools Agent vs Basic LLM Chain: Which Node Actually Talks to Ollama
n8n exposes two separate Ollama-related nodes, and mixing them up is the most common setup mistake. Ollama Model is the basic completion node. n8n's own documentation for it is explicit: "This node lacks tools support, so it won't work with the AI Agent node," and recommends pairing it with the Basic LLM Chain node instead. Ollama Chat Model is the one built to plug into the AI Agent node, where tool-calling and multi-step reasoning happen.
There's a second wrinkle worth knowing before you commit an architecture to it. n8n's Tools Agent documentation lists OpenAI, Groq, Mistral Cloud, Anthropic, and Azure OpenAI as its explicitly supported chat models. Ollama isn't on that list. That doesn't mean Ollama Chat Model won't work with the AI Agent node, plenty of teams run it in production, but it means tool-calling reliability with a given local model is something you test yourself rather than something n8n has certified. Smaller open models are more prone to malformed tool call syntax under load than the frontier APIs n8n explicitly documents. Our structured output and function calling guide covers how to benchmark tool-call reliability on self-hosted models before you ship a workflow that depends on it.
The Official Self-Hosted AI Starter Kit (n8n + Ollama + Qdrant + Postgres)
n8n publishes an open-source docker-compose template, the Self-Hosted AI Starter Kit, that bundles n8n, Ollama, Qdrant, and PostgreSQL into one stack. It ships three compose profiles: cpu for machines without a discrete GPU, gpu-nvidia, which reserves an NVIDIA device through Docker's standard deploy.resources.reservations block, and gpu-amd, which swaps in the ROCm-based Ollama image and mounts /dev/kfd and /dev/dri.
That compose file is worth reading closely because it's a working diagram of the split this whole post is about: four services in one stack, and only one of them, Ollama, needs the GPU device reservation. Postgres and Qdrant run as plain CPU containers next to it. If you're on Apple Silicon, note that n8n's own kit flags a real limitation here: Docker on Mac can't pass a GPU through to a container, so the guidance is either run Ollama on CPU inside Docker or install Ollama natively on macOS and point the containerized n8n at it over host.docker.internal:11434.
That same host-networking detail matters on Linux too, and it trips up more self-hosters than the GPU passthrough question does. Ollama's own n8n integration docs give the credential Base URL as http://localhost:11434 for a native install or http://host.docker.internal:11434 when n8n runs in Docker, but they flag that Linux Docker hosts don't resolve host.docker.internal automatically the way Docker Desktop does on Mac and Windows. You need --add-host=host.docker.internal:host-gateway on the container run command, or the equivalent extra_hosts entry in your compose file, or the credential test will fail with a connection error that has nothing to do with your model or your GPU.
Ollama vs a Self-Hosted vLLM Endpoint Behind the OpenAI Chat Model Node
The starter kit ships with Ollama, and Ollama is the right default for getting a workflow running. It's a one-command install, it serves an OpenAI-compatible API on port 11434, and n8n has a dedicated node for it. But Ollama's sequential request queue becomes a real constraint the moment an n8n workflow has any concurrency: a webhook trigger firing multiple executions at once, or a batch node fanning out several agent calls in a loop, all queue behind Ollama's single active request.
vLLM's continuous batching handles that concurrency natively, and because it also exposes an OpenAI-compatible endpoint, you don't need an Ollama-specific node at all. Point n8n's built-in OpenAI Chat Model node at your vLLM instance's base URL instead of api.openai.com, and the AI Agent node's tool-calling path works exactly as it would against the real OpenAI API, just against your own GPU. We cover this pattern, along with routing between local and hosted models from one gateway, in the LiteLLM and AI gateway setup guide, which is worth reading if you want n8n workflows that can fail over from your self-hosted endpoint to a cloud model under load. For the deeper throughput comparison between the two backends, see Ollama vs vLLM.
Sizing the GPU: Running Ollama/vLLM Alongside n8n + Postgres + Qdrant
The short answer: none of n8n, Postgres, or Qdrant's query path need GPU memory. Size the GPU for the LLM backend alone, using the same weights-plus-KV-cache-plus-overhead formula that applies to any self-hosted model, and run everything else on a CPU instance.
What Actually Needs the GPU (n8n, Postgres, and Qdrant Don't)
| Component | Role in the stack | Needs a GPU? |
|---|---|---|
| n8n | Workflow orchestration, AI Agent node, triggers | No, CPU only |
| PostgreSQL | Workflow execution history, credentials, n8n's own state | No, CPU only |
| Qdrant | Vector index and search for RAG-backed agent tools | No, CPU only for search; GPU is an optional index-build accelerator |
| Ollama / vLLM | Serves the LLM the AI Agent node calls | Yes, GPU-resident |
| Embedding model (if used for RAG) | Encodes documents/queries for Qdrant | Yes, but far smaller than the LLM |
This is the same five-layer split that applies to any self-hosted agent stack, and if you want the general VRAM formula worked through in full, our AI agent infrastructure sizing guide covers it component by component. This post stays narrow: what changes when the orchestrator specifically is n8n, and the vector store specifically is Qdrant sitting in the starter kit's own compose file. For Qdrant's own production tuning, HNSW parameters and sharding at scale beyond what the starter kit's default config gives you, see self-hosting vector databases on GPU cloud.
VRAM Budget for the Local LLM Backend
Budget the LLM's weights and KV cache first, since together they're 70-90% of total VRAM, then add an embedding model if you're running RAG against Qdrant, plus 10-15% runtime overhead:
Total VRAM = LLM weights + (KV cache per session × concurrent workflow runs) + embedding model + overheadFor a 7B model in FP16, weights run about 14GB. A 13B model is closer to 26GB. KV cache scales with context length and concurrency: a GQA-based 7B model at 4K context uses roughly 0.5GB per session, growing to around 4GB per session at 32K context. n8n workflows tend to run shorter, more transactional prompts than open-ended chat, so most agent-in-a-workflow deployments land at the low end of that range unless you're feeding large document context into the prompt for RAG.
A realistic starter-kit deployment, a 7B-13B model with moderate concurrency (5-10 simultaneous workflow executions) and a small embedding model for Qdrant, lands around 25-40GB total. That rules out a 24GB consumer card once you add RAG on top, but fits comfortably on a single 48GB card, and an A100 80GB on Spheron currently runs from about $1.82/hr on-demand, enough for the LLM backend plus the embedding model with real headroom, while n8n, Postgres, and Qdrant sit on a separate CPU instance from about $0.20/hr.
Pricing fluctuates based on GPU availability. The prices above are based on 20 Aug 2026 and may have changed. Check current GPU pricing → for live rates.
When to Graduate From Ollama to vLLM
Watch for two signals in your n8n workflow logs. First, execution time on nodes calling the LLM starts climbing during periods when multiple workflows fire close together, that's Ollama's sequential queue showing up as latency, not a model problem. Second, if you're running a webhook-triggered agent that customers or internal users hit directly rather than a scheduled batch job, sustained concurrency above a handful of simultaneous calls is exactly the scenario Ollama wasn't built for. Our full Ollama vs vLLM comparison has the throughput numbers: on the same H100, vLLM sustains roughly 4x the total throughput Ollama does at 32 concurrent requests, because continuous batching processes them in the same forward pass instead of queuing them one at a time.
n8n AI Agent GPU Deployment: Production Topology and Cost on Rented GPUs
Reference Architecture: CPU Node for n8n, GPU Node for Inference
Run n8n, Postgres, and Qdrant together on one CPU instance, and the LLM backend on a separate GPU instance, talking to each other over the private network rather than colocated on the same box. This is a direct extension of the starter kit's own gpu-nvidia compose profile, just split across two rented instances instead of one Docker host: the compose file already only reserves the GPU device for the Ollama container, so pulling that container onto its own GPU instance and pointing n8n's Ollama Chat Model or OpenAI Chat Model node at its network address is a small config change, not a re-architecture.
Keep the GPU instance on-demand rather than spot if any workflow is user-facing or webhook-triggered: a spot reclaim mid-execution means a failed workflow run, not a graceful retry. Background workflows, scheduled batch jobs, nightly document re-indexing for Qdrant, are a better fit for spot pricing, since a reclaimed instance just means the job restarts on the next scheduled run.
Cost Math: Self-Hosted GPU vs Per-Token API Calls Inside n8n Workflows
The n8n OpenAI Chat Model node works identically whether it's pointed at OpenAI's API or your own vLLM endpoint, which makes the cost comparison a straight swap: a flat hourly GPU rate against per-token API billing. The break-even depends entirely on call volume and how much of the day your GPU sits idle, not on infrastructure cost alone. That matters because falling API prices have genuinely narrowed the gap since the model-cost peak of 2023-2024, so don't assume self-hosting wins by default; run the comparison on your actual workflow volume before committing hardware.
Where self-hosting clearly wins is sustained, high-frequency workflows: an AI Agent node firing on every support ticket, every inbound lead, every document upload, hundreds or thousands of times a day. At that volume a $1.82/hr A100 running continuously is a fixed, predictable line item, while the same volume against a metered API scales linearly with every additional ticket. Where it doesn't win is a workflow that fires a handful of times an hour; a mostly-idle GPU is a worse deal than per-call pricing, full stop.
There's a second reason teams make this call that isn't pure unit economics. n8n's own positioning, and Oberhauser's public comments on model dependency, both frame self-hosting as a hedge against a single AI vendor's pricing or availability decisions, not just a cost play. If your n8n workflows are core to a customer-facing process, having the model backend on infrastructure you control is worth something the per-token math alone won't capture. Once you're weighing that tradeoff more formally, the AI agent cost calculator turns your own calls-per-day and tokens-per-call into an estimated GPU bill you can compare directly against your current API spend.
Check the Spheron docs for GPU instance provisioning steps once you've sized the LLM backend.
n8n's own docs put its minimum spec at 2 CPU cores and 2GB RAM, no GPU required, so the only rental decision that matters is sizing the Ollama or vLLM instance behind it. Spheron's A100 and H100 GPUs on-demand cover that backend, from prototyping through production concurrency.
Frequently Asked Questions
No. n8n's documented minimum is 2 CPU cores, 2GB RAM, and 20GB SSD storage, with no GPU requirement at any tier. n8n is the orchestrator: it calls your LLM backend over HTTP and handles the workflow logic. The GPU sits behind the Ollama or vLLM node it calls, not inside n8n itself.
Ollama Chat Model connects to the AI Agent node and supports tools. The plain Ollama Model node lacks tools support entirely and n8n's own docs say it won't work with the AI Agent node, pairing it with the Basic LLM Chain node instead. If you're building a tool-calling agent, Ollama Chat Model is the node you want.
Start with Ollama for prototyping since it's a one-command install. Move to vLLM once you need continuous batching for concurrent workflow runs, since n8n triggers agent calls per execution and a busy instance can mean several LLM calls in flight at once. Both expose an OpenAI-compatible API, so the node config barely changes.
Size the LLM backend alone: n8n, Postgres, and Qdrant's query path all run on CPU. For a 7B-13B model at moderate concurrency, budget 25-40GB of VRAM for weights, KV cache, and runtime overhead, which fits a single 48GB or 80GB GPU with room to spare.
