OpenClaw VPS Requirements for Browser-Based Agents on Hetzner

What VPS size does OpenClaw need for browser-based agents on Hetzner?

For light browser work, start around 2 vCPU and 4 GB RAM. For any setup that keeps multiple authenticated browser sessions open, 4 vCPU and 8 GB RAM is a safer baseline. The reason is simple: browser-driven agent runs consume more CPU time, more RAM, and more disk churn than API-only workflows.

OpenClaw's VPS docs explicitly call out low-power VM tuning and recommend treating the server as the system of record for state and workspace (OpenClaw Linux server docs). That advice matters more once the runtime is juggling real browser sessions.

Quick answer

Use this rule of thumb:

• light browser work: 2 vCPU, 4 GB RAM
• steady daily browser work: 4 vCPU, 8 GB RAM
• multi-session or approval-heavy browser work: 4 to 8 vCPU, 8 to 16 GB RAM

If you are still on a tiny box and wondering why sessions reset or queue times spike, that is usually your answer.

Why browser-based agents need more than API-only runs

API-only agents mostly spend resources on model calls, logs, and a small amount of orchestration. Browser agents add a different class of overhead:

• rendering web pages
• running client-side JavaScript
• keeping sessions and cookies alive
• downloading files or screenshots
• dealing with retries and anti-bot friction

That is why "it worked fine on the cheapest VPS" often means "it worked fine until the browser got involved."

What Hetzner gives you that matters here

Hetzner lets you choose between shared vCPU and dedicated vCPU plans, and it allows later rescaling if you outgrow the first server shape (Hetzner server overview). That is useful because browser workloads rarely stay small once they become genuinely useful.

Two practical notes:

• shared vCPU plans are fine for early testing
• dedicated vCPU plans start making more sense when browser work becomes constant or parallel

Minimum starting specs

If you want the smallest setup that is still honest:

• 2 vCPU
• 4 GB RAM
• SSD storage with room for logs and browser artifacts
• Ubuntu LTS

That is enough for:

• one operator
• one or two light browser tasks
• basic Slack or channel integrations

It is not enough for heavy concurrent browser work.

Recommended specs by workload size

Light browser workloads

Good for:

• one founder or solo operator
• occasional logged-in browser tasks
• lightweight monitoring and approvals

Start around:

• 2 vCPU
• 4 GB RAM

Medium browser workloads

Good for:

• several runs per day
• routine login-based work
• Slack approvals plus browser steps

Start around:

• 4 vCPU
• 8 GB RAM

Heavy multi-session workloads

Good for:

• parallel browser tasks
• larger authenticated workflows
• multiple operators or teams

Start around:

• 4 to 8 vCPU
• 8 to 16 GB RAM

At that point, you should also think about process isolation and whether the browser lane deserves its own host.

When CPU becomes the bottleneck

CPU pressure usually shows up first when:

• several tabs are active at once
• pages are JavaScript-heavy
• you are retrying on flaky sites
• you are running multiple sessions in parallel

Hetzner's dedicated vCPU plans are designed for CPU-intensive applications, while shared plans are more naturally framed as individual app or development environments (Hetzner server overview).

When RAM becomes the bottleneck

RAM is usually the earlier pain point in browser-heavy runs.

Watch for:

• slow page loads after a few tasks
• session resets
• browser crashes or restarts
• swap use climbing even when the box looks quiet

The browser itself, screenshots, downloads, logs, and agent memory all push in the same direction.

Storage and network basics

Storage is rarely the first thing to break, but sloppy storage assumptions cause annoying failures later.

Plan room for:

• logs
• downloaded files
• screenshots
• browser profile artifacts
• workspace data you actually want to keep

If the machine is public, remember Hetzner cloud servers do not include a public IP by default in the old sense; networking choices and primary IP setup are explicit parts of server creation (Hetzner server overview).

Signs you should upgrade

Upgrade the VPS when:

• browser tasks queue longer than the model calls themselves
• sessions reset under routine load
• one operator is fine but two operators make the box unstable
• your incident pattern is now "restart the browser and hope"

That last one is not a performance plan.

FAQ

Can OpenClaw run browser agents on a tiny VPS?

Technically yes. Operationally, only for very light use.

Is RAM or CPU more important for browser agents?

RAM usually bites first. CPU becomes the bigger issue once concurrency or rendering load climbs.

Should I start on shared or dedicated vCPU?

Shared is fine for experimentation. Dedicated becomes more sensible once browser tasks are frequent or parallel.

Sources and notes

• OpenClaw Linux server docs
• Hetzner server overview

Related reading: How to host OpenClaw on Hetzner for solo builders, Best Hetzner VPS for OpenClaw browser agents, Managed OpenClaw Hosting.