Hermes Agent Hardware Requirements: CPU, RAM & Disk

Hermes Agent runs on minimal hardware when you use cloud APIs. With local model inference, the hardware demands jump significantly. This guide explains what you actually need for every use case, and how to map that to Opsily's hosting plans so you stop guessing at your server specs.

Cloud vs. Local: The Decision That Changes Everything

Hermes Agent's hardware footprint depends almost entirely on one choice: are you calling cloud APIs or running a language model locally?

If you use cloud APIs--Claude, OpenAI, OpenRouter, Gemini--Hermes itself is lightweight. The agent sits in memory, sends requests out, and waits for responses. Average memory consumption is 282 MB, with peak usage around 1.1 GB during concurrent operations. This is measured from 31 production containers across real workflows.

If you run a local language model, you're buying a second machine worth of resources. A 7B parameter model needs 8-16 GB of RAM just for inference. A 70B model needs 80+ GB. This is why most Hermes users start with cloud APIs and only self-host the model if they have specific compliance or latency constraints.

The decision is economic: cloud APIs cost per request (typically $0.01-$1 per call depending on the model). Local inference costs in hardware, electricity, and maintenance. For a personal bot with 100 requests per day, cloud APIs cost cents. For a production system with 10,000 daily requests, local inference becomes cheaper, but you need to own the hardware.

Most Opsily users choose cloud APIs. The agent runs on our smallest plans. The model runs elsewhere or on a separate, more powerful machine connected over a LAN.

Minimum Hardware: What EUR 5/Month Buys

Opsily's starter plan gives you 1 vCPU, 1 GB RAM, and 2 GB disk. This is genuinely enough for Hermes Agent if you use cloud APIs.

What works on these specs: chat-only personal bots, dashboards that poll data and display results, agents that respond to webhooks a few times per day. A single concurrent user is never a constraint. The limit is your patience with latency when the CPU is busy.

What doesn't work: browser automation (plan for at least 2 GB RAM when the browser component activates), local model inference, running 5+ concurrent agents in parallel, or persistent memory databases that grow unbounded.

Real-world example: you build a Slack bot that responds to questions 5% of the time your team is online. It idles 95% of the day. Running 20 copies of this bot on a 1 vCPU machine costs the same as running one large instance. When each bot is active for 5 minutes, the CPU can handle all 20. This is why Opsily scales by container count, not just instance size.

If your use case fits this pattern--low concurrent load, cloud APIs, no browser tools--EUR 5/month works. You will not notice performance differences compared to a EUR 20/month plan. You are hitting CPU limits, not RAM limits, and CPU in this tier is shared fairly.

Recommended Hardware by Use Case

These estimates assume cloud API calls and container-based hosting on Opsily. They are benchmarks, not absolute rules. Your mileage varies by how often the agent calls the API, how many concurrent users you have, and how much context you load into memory.

These mappings reflect Opsily's published plan specs. The "Pro" plan handles browser automation in Hermes because 2 GB RAM is enough for the agent plus headless Chrome running in the same container. The "Business" plan scales horizontally: two Business containers, each with 2 vCPU and 4 GB, gives you 4 vCPU and 8 GB of total capacity, enough for multiple concurrent agents with browser tools.

The "Enterprise" plan starts when you exceed 40 concurrent API calls to your model provider, or when a single workflow must complete in under 5 seconds. This is rare for Hermes users, but it happens in high-frequency trading bots and real-time customer-support triage systems.

What Actually Happens When You Undershoot

Choosing a plan that is too small does not break Hermes Agent. It degrades gracefully until it hits a wall.

Phase 1: RAM pressure. The agent runs fine, but latency increases. Response times that should be 2 seconds become 5 seconds. This is because the OS is swapping memory to disk. You do not notice this in logs. You notice it when users say "the bot is slow."

Phase 2: CPU throttling. Opsily's platform fair-shares CPU when multiple containers compete for the same vCPU. If you have one agent container and several other containers on the same host, they split time. Your agent gets its slice, but it is interrupted frequently. Response times lengthen further.

Phase 3: OOM kill. The kernel terminates your container to free memory. This happens silently in most monitoring setups. Your agent vanishes, is restarted by the orchestrator (usually within 10 seconds), and is ready again. During those 10 seconds, API requests fail. Users see "error, try again."

PhasePlus: Browser tools. This is the biggest single memory jump in Hermes Agent. Adding browser automation to a 1 GB agent can push peak memory usage from 300 MB to 2-3 GB because headless Chrome carries its own runtime and page cache. If you move a bot from chat-only to browser-enabled without changing the plan, you jump from phase 1 to phase 3. You will see frequent container restarts.

Honest trade-off: you can run Hermes Agent on 1 GB RAM if you do not use browser tools and your API calls are serialized (one call at a time). But the moment you add concurrency or tools, you need 2 GB. On Opsily, jumping from Starter to Pro costs an extra EUR 10/month. For a production system, this is cheaper than the operational work of debugging slow response times and container crashes.

Subagents (Hermes's parallel agent feature) cost roughly 200-300 MB of RAM per active subagent, but only while the subagent is running. They are not a blocker on small plans unless you spawn dozens in parallel.

Local Model Inference: The Big Hardware Jump

If you want to run a language model locally--because your data is sensitive, your region has no API coverage, or you are building a research system--you move from the table above into a different world.

A 7B parameter model (like Mistral 7B or Llama 2 7B) needs 8 GB of RAM in RAM for the model weights alone. Add the KV-cache (the working memory that holds context while generating tokens) and you are at 10-12 GB for typical Hermes workflows that hold a 4K token context window.

A 13B model needs 16 GB. A 70B model needs 80 GB. There is no way around this. The model needs RAM proportional to its parameter count, divided by the number of bits per parameter (usually 4-8 bits with quantization). This is the hard physics constraint.

Hermes itself, running on the same hardware, still only needs 1-2 GB. But you do not buy hardware to run just Hermes. You buy hardware to run both Hermes and the model.

Here is the common architecture: deploy Hermes Agent on a small Opsily container (1-2 vCPU, 2-4 GB). Deploy the language model on a separate machine with 16-32 GB of RAM, connected over your LAN or a private network. Hermes calls the model over HTTP or a local API. This splits the load and lets you scale independently. You can upgrade the model machine without touching Opsily, and you can upgrade Opsily without retraining the model.

Many teams run the model on a shared GPU server or a dedicated high-RAM VPS. This adds cost, but the math works when your API call volume exceeds 500 requests per day. At lower volumes, cloud APIs (OpenRouter, Anthropic) are cheaper and require zero hardware.

One final note: Hermes itself does not require a GPU. A 7B model runs fine on a CPU-only machine in 30-60 seconds per response. A GPU reduces this to 1-3 seconds. If response latency matters to your use case (it does if you are building a chat interface), you want a GPU. If you are running batch jobs at night, a CPU-only machine is acceptable.

We have a guide to choosing the right model for Hermes that covers the cloud vs. local decision in detail.

Deployment Paths and Total Cost of Hardware

You have three real choices: self-hosted VPS, Docker containers on your own infrastructure, or managed hosting on Opsily.

Self-Hosted VPS: Rent a VPS from a provider like Hetzner, DigitalOcean, or Vultr. Install Python 3.11 or newer (Hermes requires 3.11+; some features break on 3.10 due to dependency updates). Install Hermes from pip. Run it in a process manager like systemd or supervisor.

Pros: full control, no vendor lock-in, cheapest if you are comfortable with Linux.

Cons: you handle security patches, monitor uptime yourself, manage scaling (if you need two copies, you rent two VPS). A 2 vCPU, 4 GB VPS from Hetzner costs EUR 6-12 per month. Add backups (EUR 2), a static IP (often free), and you are at EUR 15/month. Opsily's Pro plan costs EUR 15 for the same specs, but includes automated backups, a managed network, and horizontal scaling without extra work.

Docker Containers on Your Infrastructure: Build a Docker image of Hermes, push it to a container registry, and run it on your Kubernetes cluster, Docker Swarm, or managed platform like AWS ECS.

Pros: portable, scales easily, integrates with existing CI/CD.

Cons: you own the platform (Kubernetes or Swarm setup is non-trivial), monitoring, and certificate management.

This path makes sense if you already run a Kubernetes cluster. It adds zero incremental cost. If you are starting from scratch, standing up Kubernetes is 40+ hours of work and ongoing maintenance.

Managed Hosting on Opsily: Deploy Hermes using our CLI or web console. Specify your hardware tier (Starter, Pro, Business, Enterprise). We handle the rest: networking, backups, monitoring, scaling, SSL certificates, environment secrets.

Pros: no infrastructure work, linear pricing (you only pay for what you use), automatic scaling when you add more containers, EU data residency (all data stays in Europe), transparent pricing with no surprise charges.

Cons: less control than self-hosted (you cannot SSH into the container and install packages), slightly slower iteration than running locally, and pricing scales as you grow (EUR 65/month for the Enterprise plan vs. EUR 6/month for a single Hetzner VPS).

The tradeoff is operational: on Hetzner, you pay less in money but spend time patching, monitoring, and scaling. On Opsily, you pay more in money but spend zero time on operations. For most founders, this is the right trade.

We have detailed pricing and plan comparisons if you want to map your use case to a specific tier.

Frequently Asked Questions

How much RAM does Hermes Agent actually need?

For cloud APIs: 1 GB is the absolute minimum, 2 GB is comfortable, 4 GB handles concurrent load. For local models: add 8-16 GB on top of that for the model itself. The 282 MB median figure from production containers reflects agent-only workloads with cloud APIs.

Does Hermes Agent need a GPU?

No. A GPU speeds up local model inference (30-60 seconds on CPU becomes 1-3 seconds on GPU), but Hermes Agent itself runs fine on CPU only. If you use cloud APIs, a GPU is irrelevant.

Can I run Hermes Agent on a EUR 5 VPS?

Yes, if the bot uses cloud APIs and never invokes browser automation. A EUR 5/month VPS with 1 vCPU and 1 GB RAM is exactly the Starter tier on Opsily. If you add browser tools, upgrade to 2 GB RAM (EUR 10-15/month).

What's the difference between CPU and RAM needs for cloud vs. local models?

Cloud models: both are low. You are bottlenecked by network latency (API response time), not your hardware. Local models: RAM is the hard constraint. You need enough RAM for the model weights plus working memory. CPU matters for speed (inference latency), not capacity.

How much disk space does Hermes Agent use?

The Hermes Agent codebase is roughly 50-100 MB. Add Python dependencies (another 100-200 MB). The agent itself grows disk usage only if you store conversation history, session files, or skill definitions locally. A 5 GB disk is enough for thousands of conversations. A 20 GB disk is plenty for teams running multiple agents.

Is 2 GB RAM enough for Hermes Agent with browser tools?

Barely. Browser automation (headless Chrome) in the same container as Hermes typically uses 1.5-2.5 GB of RAM under load. If you have 2 GB total and the OS/Hermes takes 0.5 GB, you have 1.5 GB for the browser. If the user's webpage is heavy or the session is long, you will hit swapping. We recommend 4 GB RAM for browser tools on a production system.

What Python version does Hermes require?

Python 3.11 or newer. Hermes uses features from the standard library that were added in 3.11 (notably, improvements to exception handling and typing). If you try Python 3.10, you will see import errors when you install certain dependencies. Most cloud providers default to 3.12 now, so this is usually not a problem.

Can Hermes run multiple independent bots on the same hardware?

Yes. Each bot is a separate process or container. On a 4 vCPU, 8 GB machine running three bots, they share the hardware fairly. If one bot is idle, the others get more CPU. This is why container-based deployments on Opsily are efficient: you deploy three containers, each sees 1.3 vCPU and 2.6 GB, but they scale up if one is idle. The cost is the same, but resource usage is optimized.

The Bottom Line

Hermes Agent is hardware-light when you use cloud APIs and resource-heavy when you run models locally. The distinction changes everything about how you size your deployment.

For cloud API setups: start with Opsily's Pro plan (EUR 15/month, 2 GB RAM, 1 vCPU) if you need browser tools, or Starter (EUR 5/month) if you don't. These plans handle single bots and small teams fine.

For local model inference: separate your concerns. Run Hermes on a small Opsily container and the model on a separate machine with dedicated RAM. This costs more upfront but scales cleanly as you add features.

Ready to pick a plan? Check Opsily's Hermes Agent pricing and choose the tier that matches your needs.