OpenClaw on a Lean VPS

Complete Optimization Guide for 1 vCPU, 2 GB RAM

Generated: April 20, 2026  ·  Research by Babu AI

TL;DR — The Golden Rules ★

1. Channels: Resource Cost Analysis

Your choice of messaging channel is the single biggest runtime variable after config. Some channels maintain persistent WebSockets; others are purely webhook-driven. Here's the full breakdown for a 1 CPU / 2 GB VPS:

Channel Verdict for Small VPS

2. Skills: What to Install (and What to Skip)

What Makes a Skill Heavy

• Spawns multiple parallel subagents (e.g., deep-research)
• Runs browser automation / Playwright (100–300 MB per browser instance)
• Maintains persistent subprocess connections (e.g., Gmail watcher)
• Uses large LLM context windows for synthesis
• Triggers sandbox Docker builds

Recommended Minimum Skill Set

Skills to Skip on 2 GB VPS

Skill Loading Overhead

Skills are loaded into the Node.js process at startup and kept resident. Each skill typically adds 5–50 MB of RAM depending on dependencies. Loading 10 skills could consume 200–400 MB of your 2 GB before doing anything.

• Audit your installed skills: openclaw skills list
• Remove unused skills: rm -rf ~/.openclaw/skills/<skill-name>
• Install skills on demand rather than pre-installing everything

3. Config Tweaks for Small VPS

The following openclaw.json changes are the most impactful for running lean on 1 CPU / 2 GB RAM:

Concurrency Limits — The Big Ones

{
  "agents": {
    "defaults": {
      "maxConcurrent": 1,                    // <-- CRITICAL: one conversation at a time
      "subagents": {
        "maxConcurrent": 1,                  // <-- CRITICAL: one subagent task at a time
        "maxChildrenPerAgent": 2,             // limit parallel child subagents
        "maxSpawnDepth": 1,                   // no recursive subagent spawning
        "archiveAfterMinutes": 30              // auto-clean subagent sessions fast
      },
      "heartbeat": {
        "isolatedSession": true,              // stateless heartbeat — no context carry
        "lightContext": true,                  // only HEARTBEAT.md loaded
        "every": "60m"                         // 60 min instead of default 30 min
      }
    }
  }
}

Session Pruning — Don't Let History Grow

{
  "session": {
    "maintenance": {
      "pruneAfter": "7d",        // evict sessions older than 7 days
      "maxEntries": 100,        // cap session store entries
      "rotateBytes": 5000000,    // rotate at 5 MB
      "maxDiskBytes": "100mb"    // per-agent session disk budget
    },
    "idleMinutes": 30,
    "store": "jsonl"
  }
}

Cron Jobs — Sequential Only

{
  "cron": {
    "maxConcurrentRuns": 1,       // <-- CRITICAL: never run cron jobs in parallel
    "sessionRetention": "1h",     // prune cron run sessions after 1 hour
    "runLog": {
      "maxBytes": 500000,         // 500 KB max per cron run log
      "keepLines": 500            // truncate aggressively
    }
  }
}

Context Limits — Stay Lean Per Turn

{
  "agents": {
    "defaults": {
      "contextLimits": {
        "memoryGetMaxChars": 6000,      // truncate memory reads at 6K chars
        "toolResultMaxChars": 8000,     // truncate tool outputs at 8K
        "postCompactionMaxChars": 900   // minimal context after compaction
      },
      "compaction": {
        "reserveTokensFloor": 4000,
        "truncateAfterCompaction": true  // wipe raw transcript after summarization
      },
      "contextPruning": {
        "mode": "cache-ttl",
        "softTrim": { "maxChars": 2000 }
      }
    }
  }
}

Logging — Reduce I/O and Memory

{
  "logging": {
    "level": "warn",           // drop info/debug to reduce log volume
    "maxFileBytes": 10000000,  // 10 MB cap per log file
    "consoleLevel": "error"    // minimal console output
  }
}

Experimental Lean Mode

{
  "agents": {
    "defaults": {
      "experimental": {
        "localModelLean": true   // drop heavyweight default tools
      }
    }
  },
  "tools": {
    "profile": "minimal"         // load only essential tools
  }
}

4. Background Process Management

Heartbeat

The heartbeat runs a lightweight agent turn on a timer to check for pending work (emails, calendar, notifications). Each heartbeat:

• Loads the full agent context (AGENTS.md, SOUL.md, memory files, HEARTBEAT.md)
• Runs a model inference turn
• On a 1 CPU / 2 GB VPS this competes directly with user conversations

Set heartbeat.every to "60m" — the default 30 minutes is too frequent for a constrained box. On a lean VPS, checking every hour is plenty. Make sure lightContext: true is set so only HEARTBEAT.md is loaded, not the full workspace bootstrap.

Cron Jobs

• Never set maxConcurrentRuns above 1. Multiple cron jobs firing simultaneously is one of the most common OOM triggers.
• Stagger schedules. OpenClaw has built-in stagger (up to 5 minutes) for top-of-hour cron expressions — use it.
• Keep cron sessions short-lived. Set cron.sessionRetention: "1h" so completed cron run sessions don't accumulate.
• Avoid heavy cron payloads. Don't schedule deep-research or report generation on a 2 GB VPS. If you need reports, run them manually.

Subagents

Each subagent process costs approximately 400 MB RSS. With a 2 GB total budget:

• Gateway at rest: ~760 MB RSS
• 1 subagent active: ~400 MB → total ~1.16 GB
• 2 subagents active: ~400 MB × 2 → total ~1.56 GB
• Any spike (LLM token generation, large tool output): +200–400 MB burst

Keep maxConcurrent: 1 and maxChildrenPerAgent: 2 at most. On a truly lean 2 GB VPS, consider setting maxChildrenPerAgent: 1.

5. Memory & Swap Management

Node.js Heap: The #1 Tuning Knob

OpenClaw runs on Node.js. By default it may be configured with --max-old-space-size=2048 — fine on a 4 GB+ machine, but deadly on 2 GB. You need to cap it so the Node heap doesn't consume the entire RAM, leaving no headroom for the OS, disk cache, or kernel buffers.

NODE_OPTIONS="--max-old-space-size=1536"

--max-old-space-size=768

Swappiness

Linux default swappiness=60 is too aggressive for a VPS where disk I/O is slow. When Node.js heap pages get swapped out, performance collapses.

# Set temporarily
sysctl vm.swappiness=10

# Set permanently
echo "vm.swappiness=10" >> /etc/sysctl.conf

Swap — Safety Valve, Not Primary Memory

Add a 1–2 GB swap file as emergency headroom. Do NOT treat it as usable memory — any process that hits swap on a VPS will effectively stall.

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo "/swapfile none swap sw 0 0" >> /etc/fstab

Systemd Memory Guard

Set a hard memory limit on the OpenClaw gateway process via systemd. This makes the kernel prefer killing the OpenClaw process group via cgroup OOM before the system-wide OOM killer fires unpredictably.

# Create override
sudo systemctl edit openclaw-gateway

# Add:
[Service]
MemoryMax=2G
MemorySwapMax=1G

OOM Recovery Priority

If you want subagents to be killed before the gateway when OOM fires, adjust the OOM score:

# In systemd override:
[Service]
OOMScoreAdjust=-200   # makes gateway less likely to be killed

6. Monitoring & Alerting

Key Metrics to Watch

OpenClaw Built-in Status Commands

openclaw gateway status        # gateway health, memory, active sessions
openclaw status                # overall system status
openclaw logs                  # recent log entries
openclaw health                # deep health check with token
systemctl --user show openclaw-gateway  # MemoryCurrent vs MemoryMax

Recommended Monitoring Setup

Alert Thresholds

• RAM: 75% used (i.e., MemAvailable < 512 MB on 2 GB) — start investigating
• RAM: 90% used (MemAvailable < 200 MB) — immediate action required
• CPU: 80% sustained — check for stuck cron jobs or runaway subagents
• Disk: 90% full — log files or session store bloat

7. What to Absolutely Avoid

8. Recovery from Resource Exhaustion

If your VPS runs out of memory, here's the recovery sequence in order:

1. Restart the gateway:

   openclaw gateway stop && openclaw gateway start

   This frees all held memory and resets session state.
2. Check if OOM killed:

   dmesg | grep -i oom

   Exit 137 = OOM kill confirmation.
3. Clear cron run logs (these accumulate fast):

   find ~/.openclaw/cron/runs/ -type f -delete

4. Prune session transcripts — reduce session.maintenance.maxEntries and restart.
5. Reduce running channels — disable all but one in openclaw.json, restart.
6. Disable sandbox if enabled — set agents.defaults.sandbox.mode: "off".
7. Lower cron concurrency — set cron.maxConcurrentRuns: 1.
8. Clear media cache:

   rm -rf ~/.openclaw/media/

9. Add swap as a safety valve if not already present.
10. Monitor going forward:

    openclaw gateway status && free -m

    Run this after every restart until stable.

9. Final Checklist

Research compiled by Babu AI for Thota · April 20, 2026 · OpenClaw on Lean VPS Project