The Best VPS for a Full AI Agent Stack (2026)
Published minimums do not add up the way people assume. OpenClaw says 4GB. n8n says 4GB. Ollama says 8GB. Add them and you get 16GB, so a 16GB plan should be comfortable — and then the third install triggers the out-of-memory killer and something dies at 3am.
The arithmetic fails for three reasons, and understanding them is most of the job:
- Published minimums are floors, not operating figures. Each is the number below which the software won’t start, not the number at which it works well under load.
- Peaks don’t queue politely. An n8n build, an OpenClaw browser session and an Ollama request can all spike at once. You need headroom for the worst simultaneous case, not the average.
- The model is resident forever. Ollama holding a 7–8B model doesn’t release that memory between requests. It’s a permanent deduction from everything else.
Realistically, OpenClaw + n8n + Ollama with a 7–8B model wants 24–32GB on one box. Which is why, for most people, the answer isn’t a bigger server.
Quick comparison
| Provider | Max practical RAM | RAM value | Best for |
|---|---|---|---|
| Hostinger | 32GB | Good | Best overall, templates for each tool |
| DigitalOcean | Very high | Poor | Split setups with private networking |
| Vultr | Very high | Fair | GPU path for the Ollama half |
| Hetzner | 192GB | Excellent | Best value for a big single box |
| Linode (Akamai) | Very high | Fair | High-memory plan range |
| IONOS | High | Good | Cheapest control node |
| Contabo | Very high | Best | Most RAM per pound |
What each component actually costs you
Operating figures, not floors:
| Component | Resident | Peak | Notes |
|---|---|---|---|
| OpenClaw, headless | ~1.5–2GB | 3GB | Text-only agent |
| OpenClaw + browser | ~4GB | 6GB | Chromium adds ~2GB |
| n8n, regular mode | ~1–2GB | 3GB | Spikes during workflow runs |
| n8n, queue mode | ~3–4GB | 6GB | Main process plus workers plus Redis |
| Ollama, 7–8B quantised | ~8GB | 10GB | Model stays resident permanently |
| Ollama, 13B quantised | ~16GB | 18GB | |
| PostgreSQL (shared) | ~0.5–1GB | 2GB | One instance can serve several tools |
| Redis (shared) | ~0.1–0.3GB | 0.5GB | |
| OS + Docker | ~0.5GB | 1GB |
The two rows worth staring at are the Ollama ones. A local model is not one component among several — it’s larger than everything else combined, and it never gives the memory back.
What actually fits
| Box | Comfortably runs | Don’t attempt |
|---|---|---|
| 8GB | OpenClaw (headless) + n8n regular + shared Postgres/Redis | Any local model; browser automation alongside n8n |
| 16GB | OpenClaw + browser + n8n queue mode + Postgres + Redis + a vector DB | Ollama at 7B on top of all that |
| 32GB | The above plus Ollama with a 7–8B model | Ollama at 13B+ with everything else |
| 64GB+ | Larger models co-located, or several agents with browsers |
The pattern: everything except local inference fits comfortably in 16GB. Add a local model and you need to roughly double. That single decision dominates the entire sizing exercise, which is why it’s worth settling first.
Share your infrastructure
One easy saving before buying anything: you do not need a Postgres instance per tool.
n8n wants Postgres. Supabase brings its own. Dify ships one. Left to their defaults, three tools mean three databases, each with its own memory overhead, doing very little work. Point them at one shared Postgres with separate databases inside it and you reclaim a gigabyte or more for nothing. The same goes for Redis — one instance, separate logical databases.
The exception is anything where you’d want independent failure or independent upgrades. For a personal stack that’s rarely worth a gigabyte.
Stop one service starving the others
The failure mode people hit isn’t “the server ran out of memory”. It’s “Ollama loaded a model and Linux killed n8n”. By default containers can consume whatever’s available, so the greediest service wins and the kernel picks a victim.
Docker’s memory limits fix this. Set a limit per service, sized from the table above with a little headroom, and a service that misbehaves gets constrained rather than taking down its neighbours. In Compose that’s a mem_limit (or a deploy.resources.limits.memory in newer syntax) on each service.
Two practical notes. Set limits on everything, not just the greedy one — an unlimited container will simply expand into whatever the limited ones gave up. And leave 10–15% of total RAM unallocated for the operating system and Docker itself; committing every byte to containers is how you get a system that can’t even run the commands you need to diagnose it.
Add swap as well. It won’t make anything fast, but it converts a hard kill into a slowdown, which is a much better failure to have at 3am.
The two-server split
Once local inference is in the picture, one big box is usually the wrong purchase.
Compare, roughly:
| Approach | Configuration | Indicative monthly |
|---|---|---|
| One big box | 32GB, everything co-located | ~€25–50 |
| Split | 8GB agent node + inference elsewhere | ~€9 + inference |
The split wins for three reasons beyond price. Inference is bursty — a GPU or larger box rented by the hour costs far less than one idling 24/7. Isolation — a runaway model load can’t kill your automation. And independent scaling — you upgrade whichever half actually needs it.
Concretely: a small always-on node runs OpenClaw, n8n, Postgres and Redis in about 8GB. Inference goes either to a hosted API (cheapest for most personal use) or to a GPU instance rented by the hour when needed. Most people find the API route removes the problem entirely — at which point 8GB runs the whole stack and this article’s sizing tables stop mattering.
The 7 best VPS providers for an agent stack
1. Hostinger — best overall
Hostinger is the strongest single-box option because the plan ladder reaches 32GB — the tier a full co-located stack with local inference actually needs — and its Docker template library covers the individual pieces, so assembly is faster than a from-scratch Compose file.
For the far more common case of a stack without local inference, the 8GB tier runs OpenClaw, n8n, Postgres and Redis with room to spare, and stepping up is a plan change rather than a migration. That upgrade path matters here more than on single-tool deployments, because stacks grow by accretion — you add one more tool, then another.
NVMe helps across the board: every component in this stack does small frequent I/O.
Pros: ladder reaches 32GB; templates for the individual tools; NVMe; KVM with dedicated resources; free weekly backups; easy vertical scaling.
Cons: no GPU, so local inference is CPU-only and slow; promotional pricing needs a long prepay term.
Who it’s for: most stacks, whether you’re starting at 8GB or going straight to a co-located 32GB box.
Check Hostinger’s current VPS pricing →
2. DigitalOcean — best for split architectures
If you take the two-server advice above, DigitalOcean makes it clean. Private networking between Droplets means the agent node talks to the inference node without crossing the public internet, GPU Droplets cover the inference half, and the whole arrangement is describable in code.
Its managed databases are also relevant: pointing your shared Postgres at a managed instance removes the component with the worst failure modes from your own server, and takes its memory footprint with it.
It’s the poorest RAM value here, which for a memory-bound stack is a real cost. You’re buying the architecture, not the gigabytes.
Pros: private networking for split setups; GPU Droplets on the same platform; managed Postgres; excellent documentation and API; 99.99% SLA.
Cons: worst RAM value for a memory-bound stack; backups add ~20%; no money-back guarantee.
Who it’s for: anyone running the split architecture, especially with managed components.
Check DigitalOcean’s current pricing →
3. Vultr — best when inference stays in-house
Vultr covers both halves: cheap CPU instances for the agent node and GPU instances for inference, on one platform with a wide region list. If you’re committed to running the model yourself rather than calling an API, that combination avoids splitting across providers.
High Frequency instances also make CPU inference marginally less painful if you’re determined to co-locate a small model.
No templates, no money-back guarantee, and the console assumes you know what you want.
Pros: CPU and GPU instances on one platform; wide regions; High Frequency option; good scaling range.
Cons: no templates; no money-back guarantee; utilitarian tooling.
Who it’s for: self-hosted inference where both halves should live with one provider.
4. Hetzner — best value for a big single box
If you’ve decided on one large co-located server, Hetzner is usually where that’s cheapest — though by a narrower margin than it used to be, after its June 2026 repricing and with the cheap CX tier currently showing as unavailable. Its range goes far beyond what this stack needs, and the mid-range plans that suit a 32GB co-located deployment cost a fraction of the equivalent elsewhere.
It’s equally good for the split, because two Hetzner instances with private networking between them still undercut one mid-tier box at most providers. Attachable volumes handle the storage growth that vector databases and model files bring.
No GPU plans at all, so local inference is CPU-only. No templates, backups extra, no published SLA.
Pros: by far the best RAM per pound at the tiers this stack needs; cheap enough for two nodes; private networking; volumes; spend cap.
Cons: no GPU; no templates; backups extra; no published SLA; signup verification friction.
Who it’s for: cost-focused deployments, whether one big box or two smaller ones.
Check Hetzner’s current pricing →
5. Linode (Akamai) — best high-memory range
Linode’s high-memory plans are the relevant feature: if you’re co-locating a 13B model with a full agent stack and need 64GB, the range goes there without drama, and the platform is mature and pleasant to operate.
GPU instances are available for the inference half, and the CLI and API are good enough for a reproducible two-node setup.
Pricing sits well above the value options, which stings on a workload defined by how much memory you’re buying.
Pros: high-memory plans; GPU instances; mature tooling and API; strong network.
Cons: expensive per gigabyte; no templates; no money-back guarantee.
Who it’s for: large co-located stacks that need serious memory in one place.
6. IONOS — cheapest control node
IONOS earns its place in the split architecture specifically. If your plan is a small always-on node running OpenClaw, n8n and shared services while inference happens elsewhere, that node is unglamorous infrastructure and IONOS is the cheapest credible way to keep it running.
Unlimited traffic is useful for an agent node making a lot of outbound API calls, and the European data centres cover residency requirements for the orchestration layer.
Small entry plans, no GPU, backups extra. Not the choice for a co-located box.
Pros: cheapest credible always-on node; unlimited traffic; European data centres; approachable panel; 30-day money-back guarantee.
Cons: entry tiers too small for co-location; no GPU; backups extra.
Who it’s for: the agent half of a split setup, on a budget.
Check IONOS’s current pricing →
7. Contabo — most RAM per pound
Contabo’s whole proposition is memory volume at low prices, which is precisely the constraint this article is about. For a co-located stack that genuinely needs 32GB or more, nothing here is cheaper per gigabyte.
The caveat is CPU. Contabo’s shared cores can throttle under sustained load, and a co-located stack with several services doing work simultaneously is exactly the profile that runs into it. Memory volume without consistent CPU is a trade, not a free win.
Support is thinner than the majors, provisioning can be slow, and there’s no GPU.
Pros: the most RAM per pound available; large storage allocations; makes 32GB+ co-location affordable.
Cons: shared CPU throttling under exactly this kind of sustained multi-service load; thinner support; slow provisioning; no GPU.
Who it’s for: memory-hungry co-located stacks where budget dominates and CPU contention is tolerable.
How we picked
We ranked on what a multi-service stack actually needs: available memory at each realistic tier, RAM value (because this workload is memory-bound above all), whether the provider supports a split architecture with private networking, GPU availability for the inference half, and how easily you can scale vertically without migrating.
The component figures are operating estimates — resident and peak — rather than the published floors each project quotes, because the whole point of this article is that published floors mislead when you add them together. They’re guidance for budgeting, not benchmarks. Three of the seven providers here earn us nothing.
How to choose
- Are you running a local model? This is the whole decision. No means 8–16GB covers everything. Yes means 32GB co-located, or a split.
- Add operating figures, not minimums, and include the worst simultaneous peak.
- Share Postgres and Redis across tools before buying more memory.
- Set per-container memory limits so one service can’t kill the rest.
- Price the split before the big box. Small node plus hourly inference usually wins on cost and always wins on isolation.
For most people it’s Hostinger — the ladder reaches the tier a co-located stack needs and the templates speed up assembly. Hetzner or Contabo if you’re buying a big box on a budget, DigitalOcean or Vultr if you’re splitting with GPU inference, Linode for very large single boxes, and IONOS for a cheap control node.
FAQ
Can I run OpenClaw, n8n and Ollama on the same VPS?
Yes, but not on the 16GB you’d get from adding their published minimums. Operating figures put that combination at roughly 24–32GB once you include a browser for OpenClaw, queue mode for n8n, a resident 7–8B model, shared Postgres and Redis, and headroom for simultaneous peaks. Without local inference, the same stack fits comfortably in 8–16GB.
How much RAM do I need to self-host an AI stack?
8GB runs a headless agent plus n8n and shared services. 16GB adds browser automation, queue mode and a vector database. 32GB is where a local 7–8B model fits alongside all of that. The local model is the dividing line — it’s larger than everything else combined and holds its memory permanently.
Should I run everything on one server or split it?
Split, in most cases. A small always-on node handles the agents and automation in about 8GB, while inference goes to a hosted API or an hourly GPU instance. That’s usually cheaper than one large box, and it isolates the components — a runaway model load can’t take down your automation. One box makes sense when everything must stay on your own hardware.
How do I stop one service from killing the others?
Set per-container memory limits in Docker, sized from realistic operating figures with a little headroom, and apply them to every service rather than just the greedy one — an unlimited container will expand into whatever the limited ones released. Leave 10–15% of total RAM unallocated for the OS and Docker, and configure swap so a spike becomes a slowdown instead of a kill.
Related Blog Posts
