Cloudways Hermes Server Requirements: RAM, CPU & Sizing

Scout is the minimum sensible starting tier for light Hermes use

Scout provides 1 vCPU, 2 GB RAM and 50 GB SSD storage. It is enough to learn the Hermes workflow, experiment with persistent memory and create a small number of skills without committing to a larger server. A personal agent that performs occasional research, file work or command-line tasks can begin here while you discover which capabilities are genuinely useful.

The important word is light. Hermes can become more demanding as it retains more project state, runs local tools and delegates work. The fact that a basic session launches successfully on 2 GB does not mean every development workflow belongs on 2 GB. If you expect the agent to be active through the day or handle several tasks together, Operator gives a more realistic operating margin.

Starting on Scout is valuable when uncertainty is high. The plan lets you prove the workflow before buying capacity. If the agent becomes central to daily work, the increase to Operator is small relative to the value of a responsive tool. Requirements should follow adoption rather than precede it by months.

Operator suits an active persistent Hermes workspace

Operator provides 2 vCPUs, 4 GB RAM and 80 GB SSD storage. It is a strong fit for a Hermes agent that is used every day for focused technical work. The extra memory supports a more persistent environment with logs, local files and helper processes, while the second vCPU gives more headroom when terminal tasks or tools overlap.

Four gigabytes is especially useful when Hermes is more than a chat interface. A developer may ask it to inspect a repository, run commands, research an issue, save a reusable skill and schedule a follow-up. Each step can involve local work around the remote model calls. The server does not perform the model’s reasoning, but it still hosts the orchestration and execution environment.

Operator can also support limited child-agent use, but regular delegation changes the profile. If multiple tasks are expected to run in parallel, Squad is aligned more closely with the architecture. Monitor task latency and memory pressure rather than assuming 4 GB remains sufficient just because the number of human users stays at one.

Squad is the natural tier for regular child-agent delegation

Cloudways positions Squad, with 4 vCPUs and 8 GB RAM, for multiple sub-agents coordinating on tasks. Hermes can delegate bounded work to child agents, which makes this tier particularly relevant. A single user can trigger several parallel execution paths, and each path may have its own context, temporary files, tools and model calls. That makes the server feel more like a small worker pool than a single chat session.

Eight gigabytes also gives more room for several project workflows, persistent services and larger local artifacts. The benefit is not simply that tasks become faster; the larger resource envelope reduces contention when several useful tasks overlap. That can matter for an agent used in development or research where waiting for one long operation to finish before another can begin would break the workflow.

Delegation should still be controlled. If every request spawns several child agents, model cost can grow quickly and the server can become busy without producing proportional value. Define which tasks benefit from parallel work and set boundaries. Squad gives capacity for a multi-agent design; it does not remove the need to design that system carefully.

Swarm is for continuous technical automation, not ordinary use

Swarm provides 8 vCPUs, 16 GB RAM and 320 GB SSD storage. It is appropriate when Hermes is part of a heavy production environment with many agents, tools or scheduled tasks running continuously. The capacity can support substantial parallel work, but most personal or small-team deployments should not start here without a known reason.

A reasonable Swarm use case could involve several child agents, continuous monitoring, frequent code or research tasks, multiple connected channels and persistent local project data. Another could be an agency that uses Hermes as a shared technical automation layer for several controlled workflows. In those cases, responsiveness and concurrency can be worth more than the incremental server cost.

Before moving to Swarm, identify whether the bottleneck is compute, memory, storage or workflow design. If storage grows because logs are unbounded, fix retention. If one child-agent loop creates unnecessary load, fix orchestration. If the workload is legitimately heavy and parallel, the larger tier is the correct tool. Sizing should solve the measured problem, not hide it.

Persistent skills and local artifacts affect disk planning

Hermes can save reusable skills and retain information that makes future work easier. Depending on the workflows, the server may also accumulate repositories, downloaded documents, generated files, logs and execution artifacts. Cloudways tiers provide progressively larger SSD allocations, from 50 GB on Scout to 320 GB on Swarm. That storage should be treated as working capacity rather than an unlimited archive.

Decide which files are authoritative. Source code belongs in version control. Important business data may belong in dedicated storage. Temporary research files and logs should have retention rules. A persistent agent makes it easy to keep everything because old context can feel useful, but uncontrolled accumulation eventually creates clutter, privacy risk and backup overhead.

If disk usage rises while CPU and memory remain low, do not automatically move to a much larger compute plan just for storage. Clean temporary data or externalize durable artifacts first. Choose a larger tier when the overall workload justifies it, not because file hygiene was ignored.

Channels and MCP increase capability and responsibility

Cloudways allows Hermes to use supported communication channels and documents MCP connectivity for Managed AI Agents. Together, those features can make a hosted Hermes instance accessible from messaging while also giving it structured access to external tools and APIs. That is powerful for remote technical work, but it also expands the permission surface that must be controlled.

From a sizing perspective, channels increase the chance of asynchronous activity while MCP tools can trigger local or remote operations that overlap with other work. A lightly used terminal-only Hermes instance may fit Scout. The same agent connected to team channels and several operational tools may be more comfortable on Operator or Squad even if only a few people use it.

From a security perspective, keep credentials scoped and separate. The agent should not receive broad production permissions simply because it can technically use them. Read access, limited write scopes and explicit confirmation for destructive actions create a safer progression. Managed infrastructure solves host maintenance; it does not solve authorization design for you.

How to validate Hermes requirements after launch

Pre-deployment sizing is a hypothesis. After Hermes is running, monitor the system during real work. Look at CPU and memory when child agents are active, watch storage growth from skills and artifacts, and note whether scheduled tasks overlap with interactive sessions. Task latency is also useful because a server can appear technically healthy while users experience long queues during busy periods.

Cloudways advises evaluating usage over a period of time before scaling. Follow that guidance because one large job can create a short spike that does not justify a permanent upgrade. Persistent pressure across representative days is a better signal. If the agent is mostly idle, you may even be able to move down a tier after the experiment matures.

Keep the sizing decision documented. Record the tier, workload assumptions, connected channels, typical number of child agents and the reason for each resize. That history helps you distinguish growth from inefficiency and makes future capacity planning much easier than starting from memory every time the bill or performance changes.

Revisit the sizing assumptions whenever Hermes gains a new project, execution environment or delegation pattern. A persistent technical agent evolves over time, and the server that was comfortable during the first week may face a different workload after months of accumulated skills and automation. Capacity planning should therefore be part of change management, not a one-time checkbox at deployment.

Hermes production-readiness requirements beyond compute

A production Hermes instance needs more than enough memory for the current workload. Persistent skills and project context make configuration continuity important, so document which skills are business-critical, where source files live and how important state is backed up or reproduced. The more valuable the agent becomes over time, the more important it is to distinguish durable knowledge from temporary working files.

Credentials also need explicit ownership. Hermes may interact with repositories, terminals, messaging channels, MCP servers and other APIs, each with different risk. Use separate tokens where practical, scope them to the task and record who can rotate them. A persistent technical agent should not become a permanent container for credentials that nobody remembers creating.

Test failure and recovery scenarios before relying on Hermes for important operations. Know what happens if the model key is revoked, a channel disconnects, storage fills or a skill produces an incorrect action. The goal is not to eliminate every failure. It is to make failures understandable and recoverable so the agent can become a dependable part of the technical workflow.