Size a VPS for Always-On Agents: OpenClaw, Hermes or n8n

Buy capacity for the work your server actually performs

Model calls can dominate spending, while broken integrations and repeated jobs consume your operating time. We recommend starting with a single Ubuntu 24.04 LTS VPS and a hosted model API. That keeps the initial deployment manageable while you learn what the agent actually needs.

With hosted inference, your VPS runs the agent process and its local tools. The model provider performs inference elsewhere, so renting a larger server does not automatically make model responses faster. More server capacity helps when local work becomes the constraint, such as processing documents or running browser sessions.

Always-on means the service remains available after your laptop disconnects. It does not require the agent to reason continuously or poll an inbox without a pause. Prefer event triggers where available, and put a bounded schedule around recurring work.

Choose the runtime that matches how work arrives

For an OpenClaw VPS, think of the gateway as the persistent home of the agent. Its state and workspace belong on storage you can restore, even when you interact from another device. The OpenClaw Linux server documentation describes this arrangement and recommends private gateway access.

Hermes Agent suits work where remembered context and reusable skills matter across sessions. Its tools can use different execution backends, so determine where commands actually execute before choosing hardware. A remote execution backend moves that workload elsewhere; see the Hermes Agent documentation for the available arrangements.

Choose n8n when you want the workflow structure to remain explicit, including where an AI step belongs. For supervised server maintenance and code changes, we recommend Claude Code with bounded permissions. Our guide to running Claude Code on a VPS or connecting from your laptop helps you decide whether that separate tool needs a permanent server process.

Start with headroom and a clear upgrade path

The sizes below are our starting recommendations, not project minimums or capacity guarantees. They assume hosted model inference and a VPS dedicated to the selected workload. Include the operating system and supporting services in your memory budget.

Browser automation changes the recommendation because the browser adds processes and working memory alongside the agent. Document conversion can also introduce substantial temporary files. If those tasks are occasional, run them sequentially before buying capacity for parallel execution.

Shared virtual CPUs are a reasonable starting choice for an agent that spends much of its time waiting on APIs. Consider dedicated CPU capacity when sustained local computation needs predictable scheduling. Neither option compensates for an upstream service that is slow or refusing requests.

Check whether resizing requires a shutdown and whether an expanded disk can later shrink. Favor a provider with a usable recovery console and a documented migration path. Once you know your workload class, use the AI agent hosting comparison to evaluate those operational details.

Size n8n around active executions and payloads

For n8n VPS requirements, the number of saved workflows tells you little about peak memory. A quiet instance can still exhaust memory when an execution loads a large response and passes it through several nodes. Overlapping executions compound the demand.

The official n8n memory troubleshooting guide identifies payload size and concurrent workflows as sources of memory pressure. Manual executions can consume additional memory because data is copied for the editor. Validate the production trigger path as well as an interactive run.

• Fetch bounded pages of records instead of retrieving an entire dataset in one execution.
• Pass references to large files where the integration permits it, rather than carrying file contents through every step.
• Limit execution overlap and stagger scheduled jobs that would otherwise start together.
• Set execution-data retention so routine successes do not fill the disk indefinitely.

Account for a local database and any task runners or sandbox services you enable. A basic workflow deployment and a deployment with additional execution services have different requirements. Raising the JavaScript heap limit also does not create RAM; the host still needs space for everything else.

We would keep an initial deployment on one VPS with a deliberate concurrency limit. Move heavy processing into a separate worker when it repeatedly competes with webhook handling. Distributing execution adds operational work, so make that change in response to an identified constraint.

Keep administration private and permissions narrow

An unattended agent with broad credentials can cause damage while using very little CPU. Give its service a dedicated operating-system account and access only to the directories it needs. Keep unrestricted sudo and the host Docker socket outside its reach.

Keep the OpenClaw gateway on loopback and reach its administration interface through an SSH tunnel or another authenticated private path. For n8n, expose required webhook routes through an HTTPS reverse proxy while restricting editor access. Check container port bindings explicitly, since publishing a container port can expose more than you intended.

Use separate credentials for each integration and restrict their permissions at the provider. Follow the procedure for secrets and scoped API tokens before connecting accounts that can change production resources. A prompt telling an agent to behave carefully is weaker than a credential that cannot perform the prohibited action.

Set bounded retries and a maximum job duration so a failing integration cannot run indefinitely. Configure spending limits where the provider supports them, with alerts as an additional signal. Use production agent guardrails to define which actions require human approval and how to stop the service.

Make restarts and restores part of the deployment

Run the service under systemd or a container deployment with a deliberate restart policy. Closing SSH must not terminate the agent, and boot must start it without an interactive login. If you use a systemd user service, verify that its lifecycle supports running while the account is logged out.

A restart can recover the process without recovering the job correctly. An external action may have completed just before the agent lost its connection. Use duplicate detection or idempotency keys where supported, and decide whether interrupted jobs should resume or wait for review.

Back up persistent state using an application-consistent method, then keep an encrypted copy outside the VPS. For n8n, preserve the credential encryption key alongside the database recovery material; the n8n Docker documentation explains why its data directory still matters when PostgreSQL is used. A database restore without the required key cannot recover usable encrypted credentials.

For OpenClaw or Hermes, include the agent's state and workspace in your recovery inventory. Restore into an isolated environment with outbound actions disabled so recovered schedules cannot send duplicate messages or modify live systems. Also check that an external monitor can alert you when the VPS itself disappears.

Verify the bottleneck before resizing

Run a representative job with a realistic payload before enabling a recurring schedule. Observe available memory during its heaviest stage, then repeat with the execution overlap you intend to allow. A successful empty workflow or short chat is not evidence that the server can handle your real workload.

Inspect CPU activity and storage behavior alongside memory. Sustained swapping can keep a process alive while making jobs unacceptably slow, so treat swap as a cushion rather than planned working capacity. Track disk growth across ordinary operation, including temporary files and retained execution data.

Change the constraint that explains the failure, then repeat the same representative workload. More RAM will not fix duplicate side effects, and more CPU will not remove a provider's request limit. Record the workload and permitted concurrency with the deployment so the next capacity decision has useful context.

Provision one workload and prove it survives unattended

Choose the matching starting size and provision Ubuntu 24.04 LTS. Complete the first-hour Ubuntu server setup, then install only the runtime needed for your first useful task. Keep that task read-only while you establish its resource needs.

Configure persistent storage and automatic startup, then run the task through its normal trigger. Disconnect your administration session and confirm the service remains available. During a maintenance window, reboot the VPS and repeat the task.

Restore the backup into an isolated environment and verify that the expected state is readable before enabling external integrations there. Confirm your stop procedure works from outside the agent itself. Enable the first unattended schedule only after these checks pass, with a named person receiving failure alerts.