OpenClaw Server Requirements: VPS Specs, RAM, and OS Guide 2026

If you want to run OpenClaw on your own infrastructure, the first question you need to answer is: what kind of server do you actually need? The answer depends entirely on what you're doing with it. A lightweight text agent checking a Telegram channel needs something very different from a browser-automating research agent juggling five communication channels and running Python scripts.

This guide breaks down the exact specifications you need, organized by use case. We cover the absolute minimums, the recommended configurations, the best VPS providers for self-hosting OpenClaw, and when it starts making more sense to skip the server entirely and use managed hosting instead. If you're still deciding between self-hosting and managed infrastructure, use these specs as a comparison baseline - they map directly to what each ClawTrust tier includes.

OpenClaw Minimum Server Requirements 2026

These are the floor requirements for running OpenClaw at all. Below these specs, you will encounter performance degradation, Docker instability, or outright failures during skill loading and browser sessions.

The important caveat here: "minimum" means the agent will start and run. It does not mean it will run well under load. On a 2 vCPU / 4GB server, you should expect:

• Slow cold starts when loading skills
• Higher latency on concurrent requests from multiple channels
• Chromium crashes or OOM errors if browser automation is enabled
• Limited headroom for log retention and workspace file accumulation

For a single-channel, text-only agent that does not run browser automation or Python environments, 2 vCPU and 4GB RAM is genuinely fine. For anything more complex, keep reading.

One non-obvious requirement: the 4GB minimum assumes no concurrent browser automation. Enabling Chromium for a single session consumes 2-4GB alone, leaving less than 1GB free for the agent runtime. Production browser use requires 8GB. Getting this wrong causes silent OOM kills that look like random agent crashes. ClawTrust sizes container memory limits per tier so browser automation never competes with the agent runtime for RAM. The Starter plan allocates 3.5GB to the agent container on a 4GB VPS; Pro allocates 7GB on an 8GB VPS with separate browser memory pools.

Recommended Specs by Use Case

OpenClaw's resource footprint scales dramatically depending on what skills and channels you enable. The table below gives practical recommendations based on real deployment patterns, not theoretical maximums.

A few things worth understanding about why these numbers look the way they do:

Chromium is the biggest wildcard. OpenClaw's browser automation routes to a locally installed Chromium instance. A single browser session with a few tabs open can easily consume 2-4GB of RAM. On a 4GB server, that leaves almost nothing for the rest of the stack. This is why browser automation effectively doubles the RAM requirement.

Python environments accumulate fast. When OpenClaw installs packages into a Python sandbox, those environments persist on disk and consume RAM when active. A server running multiple Python-heavy skills will see storage grow over weeks and RAM pressure during active skill execution.

Multi-channel concurrency is CPU-bound. When five channels (Telegram, Slack, email, WhatsApp, Discord) are all active simultaneously and a user message comes in on each at the same time, OpenClaw spawns concurrent work. More vCPU means lower latency on those concurrent requests.

One thing worth noting: these numbers assume the VPS is dedicated to OpenClaw. ClawTrust agents run in containers with resource limits carved out of a dedicated VPS - the 8GB on Pro isn't shared with anything else, and the browser automation pool is sized to run concurrent sessions without competing with the agent for memory.

Operating System Requirements for OpenClaw

OpenClaw is a Linux-native application. It runs inside Docker containers and requires a Linux host. Here is how the major OS options stack up:

Ubuntu 22.04 LTS is the de facto standard for good reason. Docker's own installation documentation uses Ubuntu as its primary example. Community forum posts, GitHub issues, and troubleshooting guides are overwhelmingly written against Ubuntu. When something breaks at 2 AM, you want to be on the most-documented platform.

If you are provisioning with cloud-init or a VPS template, select Ubuntu 22.04 x64 and you will not have to think about OS compatibility again.

Storage Requirements: How Much Disk Space OpenClaw Needs

Storage requirements for OpenClaw are not static - they grow over time as your agent accumulates logs, workspace files, Python environments, and Docker image layers. Plan for growth from day one.

Base installation: The OpenClaw Docker image and its dependencies consume approximately 8-12 GB on first pull. Add the OS overhead and you are looking at 15-20 GB before your agent does anything.

Workspace data: Files the agent creates, downloads, and processes accumulate in the workspace directory. For an active agent processing documents, images, and outputs daily, plan for 1-5 GB per month of workspace growth.

Python environments: Each pip install creates a persistent environment. A few heavy data-processing libraries (pandas, numpy, requests, BeautifulSoup) can push 500MB-2GB per environment. Multiple skill environments multiply this.

Logs: OpenClaw generates structured logs for every tool call, session, and model interaction. Without log rotation configured, this can grow to several gigabytes over months. Configure logrotate or set Docker logging limits early.

The 40 GB minimum gets you started. For any agent you plan to run for more than a few months, 80 GB gives comfortable headroom. If you are running browser automation or expecting to accumulate significant workspace files, 80-100 GB from the start prevents a painful disk expansion procedure down the road. ClawTrust agents ship with log rotation pre-configured and disk usage alerts at 80%, so you never wake up to a full disk and a crashed agent.

OpenClaw Install Size and Disk Requirements

A common question before provisioning: how much disk space does OpenClaw actually need? The answer depends on which features you enable.

Base Install Size

The core OpenClaw Docker image is approximately 2-3GB. This includes the runtime, base tools, and core skill set. Pull time on a fresh VPS with a 1 Gbps connection: 20-40 seconds.

With Browser Automation

When browser automation is enabled, the Chromium browser is bundled into the container. This adds 1.5-2GB to the image size, bringing the total to approximately 4-5GB. If you plan to use OpenClaw for web research, form automation, or computer use tasks, account for this in your disk planning.

Workspace Growth Over Time

The persistent workspace (where your agent stores files, downloads, and working data) is separate from the image and grows over time. Starting size: 0. After 30 days of active use: typically 500MB-5GB depending on what your agent does. Tasks involving file downloads, screenshot archives, or large datasets will grow this faster.

Disk Size Recommendations by Use Case

Storage Type: SSD vs. NVMe vs. HDD

OpenClaw is I/O-sensitive during Docker image pulls, container starts, and workspace operations. HDD is not recommended. SATA SSD is the minimum. NVMe is ideal for fast container restarts and responsive workspace operations - especially if your agent processes files frequently.

Most VPS providers in 2026 default to NVMe or fast SSD storage. Verify before ordering: some budget tiers still use SATA SSD with lower IOPS.

Best VPS for OpenClaw Self-Hosting in 2026

The table below includes self-hosted VPS options and the fully managed alternative. All VPS prices are hardware only - add $20-100/mo for AI model costs plus monitoring, security tooling, and 2-4 hours/mo of your time for maintenance.

Notes on specific providers:

Contabo offers extraordinary specs per dollar, but the tradeoffs are real: shared networking infrastructure, slower support response times, and a reputation for variable network performance. It works, but you will notice the difference during peak hours. Good for development or budget-constrained non-critical agents.

Vultr and DigitalOcean are the standard US choices. Both offer decent performance, good API access, and reliable support. DigitalOcean has a slightly more mature ecosystem and better documentation. Vultr tends to be marginally cheaper for equivalent specs and has faster provisioning times via their API.

Hostinger KVM looks attractive on the spec sheet but uses shared vCPUs. For CPU-intensive workloads like browser automation or sustained Python execution, shared vCPUs mean your performance depends on your neighbors. Fine for light agents, not for production.

OpenClaw Dedicated Server Requirements

Most OpenClaw deployments do not require bare metal dedicated servers. A VPS with dedicated vCPUs covers the vast majority of use cases, including high-volume production. The distinction matters more in specific scenarios:

When a dedicated server makes sense:

• You are running multiple concurrent browser automation sessions (each requiring 2-4GB RAM), and a VPS with 16GB is no longer sufficient
• You have compliance or data isolation requirements that prohibit shared hardware at the hypervisor level
• You are running GPU-accelerated workloads alongside OpenClaw (local model inference, image generation)
• CPU performance consistency is non-negotiable and you cannot tolerate any noisy-neighbor effects

For dedicated server deployments, the minimum meaningful configuration would be:

Providers to consider for dedicated hardware include OVHCloud (global coverage) and Vultr bare metal (US-focused). For most teams reading this guide, a 4 vCPU / 8GB dedicated vCPU VPS from Vultr or DigitalOcean will be the pragmatic choice.

OpenClaw VPS Recommendations by Budget

Hardware price is the smallest line item. The honest breakdown accounts for AI model costs ($20-100/mo), setup time (4-20 hours first month), and ongoing maintenance (2-4 hours/mo). Here is what each tier actually costs:

From $55/mo all-in (recommended): ClawTrust Starter. Dedicated 2-3 vCPU / 4GB VPS (same hardware as Vultr Cloud Compute 4GB), pre-hardened, zero open ports, AI credits included, all channels configured, BrainTrust persistent memory, smart model routing, EDR monitoring, no maintenance. 5-day free trial. This is the actual cheapest way to run a production OpenClaw agent when you count your time. Pro ($159/mo) gives 4 vCPU / 8GB with agent email identity and Python execution.

$100-230/mo real cost (DIY VPS): Hardware at $36-38/mo (Vultr or DigitalOcean) plus $20-50/mo in AI model costs, plus monitoring tools ($10-30/mo for UptimeRobot Pro, Grafana Cloud, or Better Stack), plus security tooling ($0-20/mo for fail2ban, log aggregation, intrusion detection setup), plus 4-20 hours initial security hardening and 2-4 hours/mo ongoing maintenance at your hourly rate. If you value your time at $50/hr, maintenance alone is $100-200/mo. Dedicated vCPUs, reliable support - but you own everything that breaks at 2 AM.

$45-160/mo real cost (budget VPS, higher hidden cost): Hardware at $17-28/mo (Contabo or Hostinger) plus AI costs plus setup time. Shared vCPUs mean variable performance. The low hardware price is offset by slower support, more setup friction, and more time debugging performance issues. Better for dev/testing than production.

$100+/mo (hyperscaler cloud): AWS t3.large ($60/mo), GCP e2-standard-4 ($97/mo), Azure B4ms ($130/mo), all before AI costs. Enterprise reliability and SLAs. Makes sense if you already have cloud credits or compliance requirements. Significant overkill cost-wise for a single OpenClaw agent.

Network Requirements: Bandwidth and Port Considerations

OpenClaw's network requirements are modest by modern standards, but there are some important configuration considerations for self-hosted deployments.

Bandwidth: For a typical agent processing text-based tasks and API calls, monthly bandwidth usage is low - generally under 50 GB/month. If your agent handles significant file transfers, downloads, or browser automation that pulls large web pages and assets, bandwidth can climb to 100-200 GB/month. Most VPS providers include 2-4 TB of monthly bandwidth at the price points listed above, so this is rarely a constraint.

Latency: Matters more than raw bandwidth for conversational agents. Each LLM API call involves a round trip to an external provider (OpenRouter, Anthropic, OpenAI). Choose a VPS region geographically close to your primary API provider's endpoints. For US-based API providers, a US East or US West VPS. For EU providers, a Frankfurt or Amsterdam DC.

Port configuration after hardening: A properly hardened OpenClaw deployment should have a minimal public attack surface:

OpenClaw's gateway should be bound to loopback (127.0.0.1) only. Exposing port 18789 publicly, even with authentication enabled, dramatically increases your attack surface. External access should be routed through a tunnel (Cloudflare Tunnel, Tailscale, or a reverse proxy with TLS and rate limiting).

This setting must survive Docker restarts and OS kernel updates. A misconfigured Docker network bridge can re-expose the port after a container restart even with UFW in place. Shodan shows 42,665 instances where this went wrong. Yours needs ongoing verification, not just one correct configuration.

This is one of the less obvious self-hosting requirements: getting the networking right is not just about opening firewall rules. It requires understanding how OpenClaw's gateway binding works, configuring UFW or iptables correctly, setting up a secure tunnel for remote access, and keeping all of this maintained as Docker restarts and network interfaces change. It is doable, but it is non-trivial work. See our OpenClaw setup guide for the full walkthrough, or read our comparison of managed vs self-hosted OpenClaw to understand the ongoing maintenance burden. See the full security hardening guide for step-by-step configuration.

When to Skip the Server Entirely

There is a version of this guide where we walk through provisioning a VPS, installing Ubuntu 22.04, hardening SSH, installing Docker 24, configuring UFW, setting up a Cloudflare Tunnel, deploying the OpenClaw Docker stack, configuring log rotation, setting up monitoring, managing SSL certificates, and then doing all of it again when you need a second agent.

That is the reality of self-hosting OpenClaw well. It is not just picking the right VPS. It is the ongoing responsibility of:

• OS security patches (CVEs do not wait for business hours)
• Docker version upgrades and image rebuilds
• Certificate rotation and tunnel health monitoring
• Disk space management as workspace and logs accumulate
• Incident response when the agent goes down at 11 PM
• Backup and recovery strategy for workspace data
• Security hardening as OpenClaw and its dependencies release updates

For teams where this is worth the engineering time - either because you need the control, have specific compliance requirements, or have the infrastructure expertise on staff - self-hosting is a valid path. The specs in this guide will set you up correctly.

For everyone else, the fully managed alternative removes all of this from your plate. You get a dedicated VPS provisioned and hardened automatically, the OpenClaw stack deployed and configured, all channels available from day one, ongoing security updates applied automatically, and monitoring and incident response handled for you. The 5-day trial includes a live agent with real AI credits, which also lets you validate whether OpenClaw's capabilities match your use case before committing to the infrastructure cost either way.

If you have read this far and realized that choosing the right VPS is only the beginning of the self-hosting journey, that is an accurate read of the situation. The server requirements above are correct. The ongoing maintenance burden is real. Managed hosting exists precisely because running secure, reliable AI agent infrastructure is a full-time problem for most teams, not a one-afternoon project.

How Big Is OpenClaw?

Before provisioning a server, you need to know what you are actually installing. OpenClaw is not a lightweight CLI tool. It is a multi-component Docker stack that includes a Node.js runtime, a Chromium browser, Python, and dozens of bundled skills. Here is a breakdown of what consumes disk space and how fast it grows.

Total recommended disk: 20 GB minimum, 40 GB recommended for production. If you enable browser automation, Python execution, and plan to run the agent for more than a few months, 80 GB gives comfortable headroom without needing to resize later.

The Docker image pull itself takes 20-40 seconds on a 1 Gbps connection. On a slower VPS connection (100 Mbps), expect 2-3 minutes. The image is cached after the first pull, so subsequent container restarts are near-instant.

Minimum vs Recommended vs Production Specs

The three tiers below represent the real-world sweet spots for OpenClaw deployments. "Minimum" will run a basic agent. "Recommended" handles most production workloads. "Production" is for teams running browser automation, multiple concurrent users, or agents that need to stay responsive under sustained load.

These costs are hardware only. Add $20-100/mo for AI model API costs (OpenRouter, Anthropic, OpenAI) depending on usage volume. Self-hosted deployments also require your time for setup, security hardening, and ongoing maintenance.

The "Recommended" tier is where most production agents should start. It gives you enough RAM for browser automation, enough CPU for concurrent channel processing, and enough disk for months of operation without resizing. Moving to "Production" specs makes sense when you are running multiple agents on the same host or handling sustained high-volume workloads.

What Happens When You Under-Spec

Under-provisioning an OpenClaw server does not produce clean error messages. It produces silent failures, intermittent crashes, and behavior that looks like software bugs but is actually resource starvation. Here are the specific failure modes for each resource constraint.

The common thread: under-specced servers produce symptoms that look like application bugs. Before filing an issue or debugging your OpenClaw configuration, verify that your server meets the minimum specs in the table above. Resource starvation is the number one cause of "OpenClaw keeps crashing" reports in community forums.

Docker Resource Allocation

Running OpenClaw in Docker without explicit resource limits is a common mistake. Docker defaults give the container access to all host resources, which sounds fine until the container consumes everything and the host OS (including SSH) becomes unresponsive. Proper resource limits protect both the agent and your ability to manage the server.

Memory limit: Set the container memory to approximately 87% of host RAM. On a 4 GB VPS, that means 3.5 GB for the container, leaving 512 MB for the host OS, SSH daemon, and monitoring agents. On an 8 GB VPS: 7 GB for the container. On 16 GB: 14 GB. Going higher than 90% risks the OOM killer targeting host processes instead of the container.

CPU limit: Set to N minus 0.5 cores, where N is the total vCPU count. A 4 vCPU host should allocate 3.5 CPUs to the container. This leaves headroom for the host OS, SSH sessions, and any monitoring or logging daemons you are running alongside OpenClaw.

SHM size: This is the one that catches everyone. Docker's default shared memory allocation is 64 MB. Chromium uses shared memory for IPC between its renderer processes. At 64 MB, browser automation crashes immediately with SIGBUS errors or silent tab crashes. Set shm_size to at least 512 MB. For production browser automation with multiple tabs, 1-2 GB is safer.

PID limit: Set to 512 minimum. This prevents fork bombs from malicious or buggy skills from consuming all available process IDs on the host. Without a PID limit, a single runaway skill can make the entire server unresponsive.

Here is a reference docker-compose.yml snippet with proper resource limits for an 8 GB / 4 vCPU host:

services:
  openclaw:
    image: openclaw/openclaw:latest
    container_name: openclaw-agent
    restart: unless-stopped
    init: true
    shm_size: "1g"
    deploy:
      resources:
        limits:
          memory: 7g
          cpus: "3.5"
        reservations:
          memory: 2g
          cpus: "1.0"
    pids_limit: 1024
    tmpfs:
      - /tmp:size=256m
    volumes:
      - openclaw-data:/data
    network_mode: host

The init: true flag is important. It runs a tiny init process (tini) inside the container that reaps zombie processes. Without it, long-running agents accumulate defunct child processes from tool calls and skill executions, eventually hitting the PID limit. The tmpfs mount gives skills a fast scratch space that does not persist across restarts, preventing temporary files from consuming disk over time.

Network and Bandwidth Requirements

OpenClaw's network profile is asymmetric: it makes many small outbound requests (LLM API calls, skill HTTP calls) and occasionally pulls large payloads (browser page loads, file downloads). Understanding this pattern helps you choose the right VPS plan and configure your firewall correctly.

Outbound bandwidth per request: LLM API calls are small, typically 1-5 KB per request and 1-50 KB per response depending on output length. Streaming responses arrive in chunks of a few hundred bytes each. Skill HTTP calls vary widely, from sub-KB status checks to multi-MB file downloads.

Typical monthly usage: A moderately active agent (50-200 conversations per day, occasional browser use) consumes 5-20 GB per month of bandwidth. Agents that heavily use browser automation consume more because each page load pulls HTML, CSS, JavaScript, images, and fonts. Video and image processing skills can spike bandwidth further.

Latency: For responsive conversations, you want less than 100 ms round-trip time to your LLM API provider's endpoint. Every LLM call involves at least one network round trip, and many tool calls involve multiple sequential API calls. A VPS in US East with an API provider in US West adds 60-80 ms per call. Over a multi-step tool chain with 5-10 API calls, that latency compounds. Choose a VPS region geographically close to your primary API provider.

Ports: With ClawTrust, zero inbound ports are required. The Cloudflare Tunnel establishes an outbound-only encrypted connection from your VPS to Cloudflare's edge network. No port forwarding, no public-facing services, no attack surface. For self-hosted deployments without a tunnel, you need port 18789 (OpenClaw gateway) accessible through a reverse proxy with TLS termination. Never expose 18789 directly to the internet.

Firewall configuration: The correct default posture is deny-all inbound, allow SSH (port 22) from your IP only. All OpenClaw traffic is outbound. UFW makes this straightforward: ufw default deny incoming && ufw default allow outgoing && ufw allow from YOUR_IP to any port 22 && ufw enable. But there is a well-known gotcha: Docker bypasses UFW entirely by writing its own iptables rules, so even with UFW configured correctly, Docker-exposed ports are still reachable from the internet. Fixing this requires manual iptables overrides that most guides skip. ClawTrust eliminates this entire attack surface. Zero inbound ports, no firewall to misconfigure, no Docker iptables bypass to worry about. The agent communicates through an outbound-only encrypted Cloudflare Tunnel.

VPS Provider Comparison for OpenClaw

The table below maps VPS providers directly to OpenClaw's three spec tiers. All prices are hardware only. Self-hosted deployments require additional spending on AI model API keys ($20-100/mo), monitoring tools, and your time for setup and maintenance.

ClawTrust pricing includes the VPS, security hardening (7-layer defense), encrypted Cloudflare tunnels, credential vault, AI model credits, health monitoring, automatic updates, and BrainTrust persistent memory. Raw VPS pricing does not include the 8-20 hours of security setup, ongoing maintenance time, AI API costs, or monitoring infrastructure.

The price gap between a raw Hetzner VPS (EUR 7.49/mo) and ClawTrust Starter (from $55/mo) represents the cost of security, reliability, and your time. If you have the infrastructure expertise and enjoy the operational work, self-hosting on Hetzner or Vultr is a valid choice. If you want to focus on configuring your agent rather than your server, the managed option exists for that reason.

The bottom line: OpenClaw needs real server resources, and the specs matter. Underprovisioning causes silent OOM kills, browser crashes, and degraded response times. But the hardware is the easy part. Of the 42,665 publicly exposed OpenClaw instances found by security researchers, the problem was never the CPU or RAM. It was the security configuration that most operators never completed. ClawTrust is the only managed OpenClaw provider that combines right-sized hardware with zero exposed ports, runtime EDR, encrypted tunnels, and a credential vault on every deployment.