Running OpenClaw on a VPS: memory, headless Chrome and stability

Headless Chrome consumes around 400 to 700 MB per open tab on average, but peaks can easily hit 1.5 GB during heavy page processing. If you run OpenClaw, a browser automation platform that orchestrates multiple Chrome instances, on a VPS, memory budgeting is not optional. Run out, and the kernel kills your browser mid-crawl, losing cookies, session data, and hours of work. This guide gives you the exact OpenClaw VPS requirements: real memory figures, minimum specs for different workloads, and the stability practices that keep headless Chrome from eating your server alive. The environment is a standard Linux VPS, I used an Ubuntu 24.04 instance, and everything shown applies to any distro with systemd, cgroups, and a modern kernel.

运行 OpenClaw 需要每实例至少 2 GB 内存，生产环境建议 4 GB 起。

Running OpenClaw requires at least 2 GB of RAM per instance; 4 GB is the recommended starting point for production workloads.

Prerequisites

• A Linux VPS (Ubuntu 24.04 LTS or Debian 12) with root or sudo access. For a VPS for OpenClaw, you want full root access and a clean OS template.
• At least 2 GB of RAM for a single-account test run; 4 GB minimum for serious multi-account work.
• One dedicated IPv4 address. OpenClaw uses the IP for browser fingerprint isolation, and a Vietnam IPv4 is what you need if your target market or upstream services expect Vietnamese residential traffic.
• Docker and Docker Compose (v2, use docker compose, not the old docker-compose).
• Basic familiarity with htop, journalctl, and systemctl for debugging.

Why browser automation needs its own memory budget

OpenClaw runs a headless Chromium instance for each account profile you create. Every profile gets its own user-data directory, its own cache, and its own renderer process. The Chromium process tree for a single tab looks like this: one browser process (~200 MB base), one GPU process (another 50 to 80 MB even headless), plus one or more renderer processes (300 to 500 MB each depending on the page complexity). A typical product listing page with 20 images, JavaScript frameworks, and analytics scripts pushes that single tab to 700 MB within seconds. OpenClaw does not share a single browser across accounts, that would leak cookies and ruin fingerprint isolation, so each profile's memory is additive. Run 5 profiles concurrently and you are looking at 3.5 to 4 GB of RSS before you have even started processing anything.

This is why the correct query is not "can OpenClaw run on 1 GB" (no, not reliably) but "how much peak memory does my workload need." The answer depends on two factors: the number of concurrent browser contexts and the complexity of the pages being scraped or automated. A simple text-based form submission might use 350 MB per tab. A dynamic single-page application with WebSocket connections and streaming data can easily triple that.

Step 1, Install Docker and set up the OpenClaw stack

Start with Docker. Ubuntu 24.04 ships with Docker in its repos but you want the upstream version for the latest security patches. Run:

# Remove any old docker packages
for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do
  sudo apt-get remove $pkg
done

# Add Docker's official GPG key and repository
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verify Docker is running and that docker compose (v2) is available:

sudo systemctl status docker
docker compose version

Expected output: active (running) for Docker, and a version string like Docker Compose version v2.30.0 or newer.

Now pull the OpenClaw stack. The project provides a docker-compose.yml in its official repository. At minimum you need the core service plus the headless Chrome agent:

mkdir ~/openclaw && cd ~/openclaw
curl -O https://raw.githubusercontent.com/openclaw/main/docker-compose.yml
docker compose pull

Edit the .env file that ships with the compose file. The critical variables for memory control are:

# Limit per-browser memory (in MB)
CHROME_MAX_MEMORY=768

# Maximum number of browser instances
MAX_CONCURRENT_BROWSERS=3

# Timeout for idle browsers (seconds)
BROWSER_IDLE_TIMEOUT=120

Set CHROME_MAX_MEMORY to 768 MB for a 2 GB server; raise it to 1024 MB on a 4 GB server or higher. The MAX_CONCURRENT_BROWSERS must be realistic, 3 per 4 GB of available RAM is a safe baseline.

Start the stack:

docker compose up -d

Check that everything came up cleanly:

docker compose ps
docker compose logs --tail=20

Expected: all services show Up and no crash-looping in the logs. If the headless Chrome container keeps restarting, the most common cause is OOM, check the next section.

Step 2, Understanding headless Chrome memory: real figures on a VPS

I ran OpenClaw on a VPS with 4 GB of RAM and 2 vCPUs (NVMe storage, unlimited traffic as standard for any thueVPS plan) and monitored memory with htop and smem. Here is what the numbers look like:

The takeaway is clear: a 4 GB VPS can handle 2, 3 active profiles running typical browsing tasks. If you push it to 5 profiles with any heavy pages, the kernel OOM killer intervenes. The 2 GB VNLite plan (1 vCPU / 2 GB RAM / 20 GB NVMe) is fine for testing a single profile or very light automation. For production, the VNx2 plan (2 vCPU / 4 GB RAM / 50 GB NVMe) is the practical minimum for reliable multi-account work without swap thrashing.

Key metric to watch: swap usage above 100 MB combined with a rising kswapd0 CPU percentage. When you see that, reduce MAX_CONCURRENT_BROWSERS or upgrade the VPS.

Step 3, Stability techniques

Memory is half the story. The other half is keeping headless Chrome stable over long sessions (hours to days). Here are the three configurations that matter most.

3.1, Swap is your safety net, not your solution

Set swap equal to or less than your RAM on a low-end VPS. A 4 GB VPS should have 2 to 4 GB of swap. On Ubuntu 24.04 the default swap file is often too small for browser workloads:

# Check current swap
sudo swapon --show
# If less than 2 GB, resize or create a new swap file
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Verify: free -h should show both RAM and swap. With swap in place, an occasional memory spike will not crash the browser, but it will slow page processing noticeably. Plan your capacity so swap is used only during short peaks, not sustained operation.

3.2, Cap browser processes with cgroups

If your Docker host runs only OpenClaw, you can use a systemd service scope to limit total memory for the whole stack. Create a drop-in for the Docker service:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/override.conf << 'EOF'
[Service]
MemoryMax=3.5G
MemorySwapMax=1G
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

This caps the Docker daemon (and all its containers) at 3.5 GB of physical RAM, leaving 500 MB for the OS. If the stack tries to exceed that, the kernel throttles not kills, but it helps prevent the emergency OOM scenario. Adjust the number based on your VPS plan (3.5 G for 4 GB, 7.2 G for 8 GB, etc.).

3.3, Automatic restart on failure

Even with good capacity planning, headless Chrome occasionally crashes on memory bugs in specific JavaScript-heavy sites. Configure the OpenClaw container to restart automatically unless it keeps failing:

# In your docker-compose.yml, under the headless-chrome service:
restart: unless-stopped
# And add a health check:
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:9222/json/version"]
  interval: 30s
  timeout: 10s
  retries: 3

Then docker compose up -d again. Now if a browser process dies, Docker restarts it within 10 seconds. Pair this with a monitoring loop that logs crash frequency: if it restarts five times in an hour, you are under-provisioned.

Troubleshooting

The headless Chrome container keeps restarting instantly

Check the logs: docker compose logs headless-chrome | tail -20. If you see Segmentation fault or FATAL:zygote_host_impl_linux.cc followed by a memory error, the container is OOM-killed. Check docker stats for the whole stack:

docker stats --no-stream

If memory usage is at or above your VPS's total RAM, reduce MAX_CONCURRENT_BROWSERS in your .env file and recreate the containers.

Browser tabs freeze after running 6+ hours

Usually a memory leak in a specific JavaScript-heavy page. Run docker compose logs --tail=50 headless-chrome and look for Aw, Snap! or renderer process crashed. The fix: add --disable-features=site-per-process to the Chrome launch arguments in the OpenClaw configuration (isolates a crash to one tab instead of killing the whole browser), but this reduces security isolation. A cleaner long-term fix is to set the browser restart interval at the application level: force OpenClaw to recreate its browser context every 12 hours via a cron-triggered API call or within a daily workflow.

High swap usage despite low browser count

Run htop and sort by %MEM. If a process other than Chrome is consuming RAM (e.g., a database container or a leftover backup job), it is stealing memory from your browser budget. On a VPS dedicated to OpenClaw, run only the necessary containers. Docker overhead adds about 300 to 400 MB even with zero browsers running, so a 2 GB server effectively has ~1.6 GB usable for Chrome. Account for this when sizing.

FAQ

Related articles

• Why browser automation needs a dedicated IP
• n8n on a dedicated IP: why webhook reliability depends on it
• Set up a Prometheus + Alertmanager pipeline on a VPS