Self-Hosted Multi-Agent VPS: Five AI Roles on One Server

You've seen the pitch: a team of AI agents handling research, writing, code, admin, and design — each with a specialty, all working together. The usual path is a SaaS subscription per seat, per agent, per month. But there's a quieter alternative: run every agent yourself, on a single VPS you rent for under $15/month.

A self-hosted multi-agent VPS isn't theoretical. People run five, eight, even a dozen specialized agents on one box. The catch is knowing the real resource numbers, the architecture that prevents agents from stepping on each other, and where to spend money (cloud API keys) versus where to save it (local models).

This guide gives you the concrete numbers — RAM per component, CPU headroom, storage, monthly cost — so you can size a server, pick a provider, and deploy with confidence instead of guessing.

What Five Specialized AI Roles Actually Means

"Five agents" doesn't mean five copies of ChatGPT running in parallel. Each agent has a distinct role, different system prompt, different skill set, and often a different underlying model. Here's a realistic roster:

• Secretary — reads and drafts email, manages calendar, triages incoming messages, summarizes Slack threads. Mostly short outputs, frequent calls, low token volume per task.
• Coder — writes code, reviews pull requests, refactors functions, generates tests. Long contexts, large outputs, benefits from a strong reasoning model.
• Researcher — searches the web, reads documents, synthesizes findings into structured briefs. Medium context, moderate output, often hits API rate limits due to web-fetch loops.
• Copywriter — drafts blog posts, ad copy, social content, landing pages. Creative tasks, variable output length, benefits from a model with good prose.
• Designer — generates SVGs, writes CSS, creates image prompts, builds mockup layouts. Often pairs a text model with an image-generation endpoint.

Each of these is a persistent process (or set of processes) that boots once and waits for tasks. They share the server, but they're not all consuming resources at the same time. That distinction is what makes one VPS viable.

Real Hardware Requirements for a Self-Hosted Multi-Agent VPS

Let's break down what actually consumes RAM and CPU on the server, component by component.

Base operating system + Docker daemon: ~600 MB RAM, negligible CPU when idle.

Agent runtime (one framework orchestrating all five agents): ~300–800 MB RAM total. A Python-based orchestrator with five agent definitions loaded into memory. This is not five separate applications — it's one process managing five roles.

Task queue (Redis or RabbitMQ): ~50–150 MB RAM. Handles serialization so two agents don't hit the LLM API simultaneously. Lightweight.

Vector database (Qdrant, ChromaDB, or SQLite-VSS): ~200–500 MB RAM depending on corpus size. Stores embeddings for the agent memory layer — past decisions, company facts, document chunks.

Local embedding model (e.g., nomic-embed-text via Ollama): ~300–600 MB RAM. Generates vector embeddings for the memory system without calling a paid API.

Local helper model (e.g., Mistral 7B or Llama 3 8B via Ollama): ~4–6 GB RAM. Handles low-stakes tasks — formatting, summarizing, text extraction — for $0 in API cost.

Total with a local model: ~6–9 GB RAM actively used, leaving headroom on a 16 GB box.

Total without a local model (cloud-only): ~1.5–2.5 GB RAM. An 8 GB VPS is plenty.

CPU: The bottleneck is token generation, which is I/O-bound against the GPU or the network (for cloud APIs). Four vCPUs handle concurrent agent tasks without contention. Two vCPUs work if tasks are strictly queued.

Storage: 20–40 GB SSD. Docker images, model weights (a 7B quantized model is ~4 GB), vector database files, logs. A 40 GB disk gives comfortable room.

Architecture: How Agents Share One Server

The worst mistake is running five independent Docker containers, each with its own web server, its own database, its own Ollama instance. That bloats RAM fast and creates conflicts over ports and GPU access.

Instead, use a shared architecture:

1. One orchestrator process holds all five agent definitions, routes incoming tasks to the right agent, and manages the task queue. Frameworks like CrewAI, AutoGen, or a custom FastAPI service handle this.

2. One shared LLM gateway. If you run Ollama locally, one instance serves all agents. If you use cloud APIs, one proxy endpoint (LiteLLM or a simple reverse proxy) handles rate limiting, retries, and model routing per agent.

3. One vector database instance with separate collections per agent. The researcher stores web findings; the coder stores code snippets and decisions; the secretary stores meeting notes. Same Qdrant process, different namespaces.

4. One Redis instance for the task queue, rate limiting, and ephemeral cache (conversation windows, intermediate results).

5. Shared file storage — a single volume mount where agents read and write files. The copywriter produces a draft; the designer picks it up and adds layout. No inter-container networking needed.

A docker-compose.yml with five services (orchestrator, LLM gateway, vector DB, Redis, file store) typically runs in under 3 GB of RAM before you add the local model. Add Ollama and you hit 8–9 GB. Add 4 GB of OS headroom and you're at 12–13 GB — comfortable on a 16 GB VPS.

Queuing is critical. Without a queue, if the researcher and coder both trigger an LLM call at 14:00:01, one fails or both degrade. Redis-backed task queues (Celery, BullMQ, or even a simple FIFO list) serialize calls and let you assign priority. The coder gets priority over the copywriter for formatting tasks. The secretary gets low priority since email drafts can wait 200 ms.

The Hybrid Approach: Local Models for Free, Cloud for Hard Problems

Not every task needs a frontier model. Here's a practical split:

Run locally (free):

• Generating vector embeddings for the memory layer
• Summarizing short text (< 500 tokens)
• Extracting structured data from emails (sender, date, subject)
• Formatting output (markdown to HTML, JSON cleanup)
• Generating headlines and meta descriptions from a draft

A quantized 7B model on CPU handles these in 1–5 seconds per task. No API cost, no latency to an external server, no data leaving your VPS.

Route to cloud API (paid):

• Long-form content generation (blog posts, reports)
• Complex code generation and debugging
• Multi-step research requiring reasoning chains
• Creative tasks where prose quality matters
• Anything requiring > 8K context with coherent reasoning

Use OpenRouter to access multiple providers through one API key. Point the coder at Claude Sonnet ($3/$15 per million in/out tokens). Point the copywriter at GPT-4o ($2.50/$10). Point the researcher at a cheaper model like Gemini Flash ($0.075/$0.30). The key insight: assign the right model to the right role, not the strongest model to everything.

This hybrid approach typically cuts API spend by 60–80% compared to routing every task to a frontier model.

Total Monthly Cost Breakdown

Here's what the self-hosted multi-agent VPS actually costs to run, using real provider pricing:

Compare that to SaaS agent platforms charging $20–50 *per agent per month*. Five agents on a SaaS plan runs $100–250/month and climbing. The self-hosted route is 70–90% cheaper after the first month.

The VPS itself is the smallest line item. The API key is where your money goes — and the hybrid model approach keeps that bill low.

Scaling note: If usage grows, you don't add a second VPS. You upgrade the existing one. Hetzner lets you resize from CX31 to CX41 (8 vCPU, 32 GB) for €16.49/month with a reboot. The architecture stays the same; you just get more headroom for a heavier local model or more concurrent agents.

Three Mistakes That Crash Multi-Agent Setups

1. Running separate Ollama instances per agent. Each Ollama instance loads its own copy of the model into RAM. Five agents × a 4 GB model = 20 GB just for inference. Run one Ollama instance. All agents call it through a single endpoint.

2. No rate limiting on API calls. An aggressive researcher agent with web-search loops can burn through your daily API budget in an hour. Set per-agent token budgets. Cap the researcher at 200K tokens/day. Cap the copywriter at 100K. Redis makes these limits trivial to implement.

3. Ignoring the embedding pipeline. People set up the agents and forget the memory layer. Without embeddings, agents can't recall past decisions and re-research the same topics every session. Set up the vector database on day one. Even a basic text-embedding-3-small call per document chunk (fractions of a cent) prevents hours of redundant LLM work later.

Making It Work Long-Term

A self-hosted multi-agent VPS isn't just cheaper — it gives you control that SaaS can't. Your data stays on your server. Your prompts, your system instructions, your company knowledge base — none of it passes through a third-party platform's training pipeline. For regulated industries (legal, healthcare, finance), this isn't a nice-to-have; it's a requirement.

The technical bar is real but not steep. If you can write a docker-compose.yml and run curl | bash, you can deploy this. The key is starting with the right hardware spec (16 GB RAM, 4 vCPU), one shared architecture (not five silos), and a hybrid model strategy that puts the expensive reasoning where it earns its keep.

Start small: deploy two agents (secretary + researcher), confirm they share resources cleanly, then add the remaining three. Within a week, you'll have a working AI team running on infrastructure you own, for less than the cost of a single SaaS seat.

--- slug: five-ai-roles-one-vps-full-team lang: en title: "Self-Hosted Multi-Agent VPS: Run 5 AI Roles on One Server" description: "Real numbers on RAM, CPU, and cost for running a complete self-hosted multi-agent VPS — five AI agents sharing one affordable server." keywords: self-hosted multi-agent VPS, AI team server, multi-agent system, self-hosted AI agents, Docker AI deployment, local AI models, VPS AI infrastructure eyebrow: Guide read: 8 min read date: 2026-07-07 h1: "Self-Hosted Multi-Agent VPS: <span class=\"accent\">Five AI Roles</span> on One Server" crumb: Multi-Agent Deployment faq:

• q: Can a single VPS really run five AI agents simultaneously?

a: Yes. The agents don't all execute at once — they queue tasks and share resources. A 16 GB RAM VPS with 4 vCPUs comfortably handles five roles because idle agents consume near-zero CPU and minimal memory. Only the task in progress draws heavy resources.

• q: What's the minimum VPS spec for a self-hosted multi-agent VPS?

a: 8 GB RAM and 2 vCPUs will run five agents if you offload everything to cloud APIs and skip local models. For a hybrid setup with a small local model handling routine work, 16 GB RAM and 4 vCPUs is the practical floor.

• q: Do I need cloud APIs, or can everything run locally?

a: Simple tasks (formatting, text extraction, headline generation) run fine on a 7B-parameter local model. Complex reasoning, long-form writing, and code generation still benefit from frontier models via API. A hybrid approach gives you the best cost-to-quality ratio.

• q: How much does it actually cost per month to run a self-hosted AI team?

a: A Hetzner CX31 (16 GB, 4 vCPU) costs €8.49/month. API spend for a small business averages $5–25/month depending on usage. Total: roughly $12–35/month for five specialized agents — far less than SaaS per-seat pricing.

• q: What happens when two agents need the LLM at the same time?

a: A task queue serializes LLM calls so they don't collide. Most agent frameworks support priority levels — give the coder higher priority than the copywriter for formatting tasks, for instance. The second agent waits milliseconds, not minutes.

• q: Is my data safe running AI agents on a VPS?

a: Everything runs in Docker containers on infrastructure you control. No data leaves your server unless you explicitly call an external API. For regulated industries, you can route all LLM traffic through a single outbound proxy and log every request. ---

You've seen the pitch: a team of AI agents handling research, writing, code, admin, and design — each with a specialty, all working together. The usual path is a SaaS subscription per seat, per agent, per month. But there's a quieter alternative: run every agent yourself, on a single VPS you rent for under $15/month.

A self-hosted multi-agent VPS isn't theoretical. People run five, eight, even a dozen specialized agents on one box. The catch is knowing the real resource numbers, the architecture that prevents agents from stepping on each other, and where to spend money (cloud API keys) versus where to save it (local models).

This guide gives you the concrete numbers — RAM per component, CPU headroom, storage, monthly cost — so you can size a server, pick a provider, and deploy with confidence instead of guessing.

What Five Specialized AI Roles Actually Looks Like

"Five agents" doesn't mean five copies of ChatGPT running in parallel. Each agent has a distinct role, different system prompt, different skill set, and often a different underlying model. Here's a realistic roster:

• Secretary — reads and drafts email, manages calendar, triages incoming messages, summarizes meeting notes. Mostly short outputs, frequent calls, low token volume per task.
• Coder — writes code, reviews pull requests, refactors functions, generates tests. Long contexts, large outputs, benefits from a strong reasoning model like Claude Sonnet or GPT-4o.
• Researcher — searches the web, reads documents, synthesizes findings into structured briefs. Medium context, moderate output, often hits API rate limits due to web-fetch loops — requires careful throttling.
• Copywriter — drafts blog posts, ad copy, social content, landing pages. Creative tasks, variable output length, benefits from a model with good prose.
• Designer — generates SVGs, writes CSS, creates image prompts, builds mockup layouts. Often pairs a text model with an image-generation endpoint like DALL-E or Flux.

Each of these is a persistent process (or set of processes) that boots once and waits for tasks. They share the server, but they're not all consuming resources at the same time. That distinction — idle agents cost nearly nothing — is what makes one VPS viable for the whole team.

Real Hardware Numbers for a Self-Hosted Multi-Agent VPS

Let's break down what actually consumes RAM and CPU on the server, component by component.

Base operating system + Docker daemon: ~600 MB RAM, negligible CPU when idle.

Agent runtime (one framework orchestrating all five agents): ~300–800 MB RAM total. A Python-based orchestrator with five agent definitions loaded into memory. This is not five separate applications — it's one process managing five roles.

Task queue (Redis): ~50–150 MB RAM. Handles serialization so two agents don't hit the LLM API simultaneously. Lightweight and battle-tested.

Vector database (Qdrant, ChromaDB, or SQLite-VSS): ~200–500 MB RAM depending on corpus size. Stores embeddings for the agent memory layer — past decisions, company facts, document chunks. This is what prevents agents from re-researching the same topics every session.

Local embedding model (e.g., nomic-embed-text via Ollama): ~300–600 MB RAM. Generates vector embeddings for the memory system without calling a paid API — a detail that saves $5–15/month at moderate scale.

Local helper model (e.g., Mistral 7B or Llama 3 8B, quantized, via Ollama): ~4–6 GB RAM. Handles low-stakes tasks — formatting, summarizing, text extraction — for $0 in API cost.

Total with a local model: ~6–9 GB RAM actively used, leaving headroom on a 16 GB box.

Total without a local model (cloud-only): ~1.5–2.5 GB RAM. An 8 GB VPS is plenty.

CPU: Token generation is I/O-bound (against the GPU or network). Four vCPUs handle concurrent agent tasks without contention. Two vCPUs work if tasks are strictly queued.

Storage: 20–40 GB SSD. Docker images, model weights (a 7B quantized model is ~4 GB), vector database files, and logs. A 40 GB disk gives comfortable room with space to grow.

Quick reference table

Architecture: How Five Agents Share One Server

The worst mistake is running five independent Docker containers, each with its own web server, its own database, its own Ollama instance. That bloats RAM fast and creates conflicts over ports and GPU access.

Instead, use a shared architecture:

1. One orchestrator process holds all five agent definitions, routes incoming tasks to the right agent, and manages the task queue. CrewAI, AutoGen, LangGraph, or a custom FastAPI service all handle this.

2. One shared LLM gateway. If you run Ollama locally, one instance serves all agents. If you use cloud APIs, one proxy endpoint (LiteLLM or a simple reverse proxy) handles rate limiting, retries, and model routing per agent.

3. One vector database instance with separate collections per agent. The researcher stores web findings; the coder stores code snippets and decisions; the secretary stores meeting notes. Same Qdrant process, different namespaces.

4. One Redis instance for the task queue, rate limiting, and ephemeral cache (conversation windows, intermediate results).

5. Shared file storage — a single volume mount where agents read and write files. The copywriter produces a draft; the designer picks it up and adds layout. No