TL;DR
OpenClaw is light: the floor is about 1 GB of RAM, one core, and 500 MB of disk on a 64-bit OS (the Raspberry Pi guide's number); 2 GB+ is comfortable. Node 24 recommended, Node 22.19+ works. Install is one line: curl -fsSL https://openclaw.ai/install.sh | bash. The security default that makes a VPS deployment sane: the Gateway binds to loopback and needs zero inbound ports, so the correct firewall state is SSH open and everything else dropped. Three traps: hardening after installing instead of before (a fresh public IP gets scanned by bots within minutes), exposing the gateway to save yourself a tunnel, and running with no backup of state and workspace.
Search "openclaw vps" and you get the official docs plus five-minute tutorials that paste the install command and stop. The command works; what those posts skip is that you now own a computer on the public internet with an AI agent on it, and the internet noticed before you finished onboarding. I provision and harden these boxes for production, so this guide covers the parts those posts leave out.
What OpenClaw needs (system requirements)
Runtime. Node 24 is recommended; Node 22.19+ works. The installer script installs Node for you. Bun is not recommended as the Gateway runtime (known bugs in the WhatsApp and Telegram channels under Bun); run the daemon on Node, keep Bun for CLI-only use. pnpm only matters if you're building from source.
OS. macOS, Linux, or Windows. On Windows, WSL2 is more stable than running natively.
Resources. The floor comes from the Raspberry Pi guide: 1 GB RAM, one core, 500 MB free disk, 64-bit OS. Treat it as a floor. 2 GB+ of RAM is where you stop thinking about memory; at 2 GB or below, add swap, because the standard small-box failure is the kernel killing the gateway when memory runs out. More on that below (exit 137).
ARM. ARM64 works: Node, Telegram, WhatsApp, and Chromium all run. The one catch is optional Go or Rust CLI tools some skills pull in; not all publish ARM builds. Check a tool's release page for linux-arm64 or aarch64 before you're stuck compiling from source.
No GPU, no external database; sizing is a RAM-and-CPU question, and it changes with how many agents run at once.
Running several agents at once. The 1 GB floor is one light agent. OpenClaw runs several isolated agents in one gateway, each with its own workspace, session, and, when it reaches for the web, its own headless Chromium. The browser is the cost that scales: an active agent doing real work sits around 0.5-1.5 GB, mostly Chromium, while idle agents cost little. The math is base (gateway plus OS, 1-2 GB) plus 0.5-1.5 GB per active agent. Five to seven agents at once is a comfortable 16 GB box; heavy parallel or browser-heavy fleets want 32 GB. CPU scales the same way, cores per concurrent agent, and a handful of active ones runs fine on 8 vCPU. Swap won't save you here: when real memory runs out the kernel kills the gateway (exit 137), so size the RAM for the peak, not the average.
Where to run it: paid VPS, free ARM, or a box at home
People keep asking which VPS is best for OpenClaw, but the provider is the wrong variable. Any Linux VPS with 2 GB of RAM runs it the same; what separates a solid deployment from a compromised one is the lockdown below, not the provider.
A ~$5/month VPS. The docs' own list: Railway and Northflank if you want one-click, DigitalOcean, Fly.io, Hetzner, Hostinger, GCP, Azure. AWS works too (EC2 or Lightsail, free tier included). Pick whichever console you can tolerate, give it 2 GB, and move on.
Free: Oracle Cloud Always Free ARM. Up to 4 OCPU, 24 GB RAM, and 200 GB of storage, for free. The manual's example shape is 12-24 GB of memory and a 50-200 GB boot volume, far more machine than the Gateway needs. Two catches: it's ARM (the skill-CLI note applies), and patching, firewall, and backups are the same work at $0 as at $5.
At home. A Mac mini as an always-on macOS box (the gateway runs under a LaunchAgent), or a Raspberry Pi 4 or 5 with 2 GB+, better 4. On a Pi, boot from a USB SSD; SD cards are slow and wear out under a daemon that writes all day. The trade is uptime, backups, and maintenance, all yours, and the agent is only as reachable as your home connection.
A VPS buys you an agent reachable from anywhere, an IP that doesn't move, and hardware someone else keeps powered. In exchange it's a machine on the public internet, which is what the next section is about.
Install
One ordering note: if the box has a public IP and you haven't done the lockdown in the next section, do that section first. The install takes five minutes; scanners find a fresh IP faster than that.
The installer script detects the OS, installs Node, and walks you through onboarding:
curl -fsSL https://openclaw.ai/install.sh | bashWant it non-interactive? curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard skips onboarding.
If you'd rather manage Node yourself, npm works:
npm install -g openclaw@latest
openclaw onboard --install-daemonThat second command is the one that matters on a server: on Linux it sets up a systemd user service, so the gateway starts on boot and comes back after a crash (openclaw gateway install does just the service part). With pnpm: pnpm add -g openclaw@latest plus pnpm approve-builds -g (pnpm wants explicit approval for build scripts), then the same onboard. Bun installs the CLI fine; the daemon still belongs on Node. Docker is an option for containerized or headless setups; on a plain VPS the native installer is simpler.
One known npm gotcha: if the install trips over the sharp image library on a machine with a global libvips, SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm install -g openclaw@latest gets past it.
Then verify, every install:
openclaw --version
openclaw doctor
openclaw gateway statusVersion tells you what's live, doctor checks config and state, gateway status confirms the daemon is up. Thirty seconds, and it catches the cases where install printed success but nothing is actually running.
Lock the box down before you expose anything
This is the section those quick tutorials skip. A fresh VPS on a public IP starts collecting password-guessing attempts within minutes. Nobody targeted you; scanners sweep whole IP ranges around the clock, and your box is in one of them. On my machines, everything in this section happens before OpenClaw is installed at all.
The first four items are standard hardening for any internet-facing Linux box; the OpenClaw-specific part follows.
SSH first. Keys only, password authentication off, root login off, fail2ban running to slow whoever keeps knocking. It's the first change on the box. OpenClaw's deployment docs agree on the ordering: harden admin SSH before you install; if you run Tailscale, tailnet-only SSH keeps the port off the public internet entirely.
Firewall, default deny. The gateway lives on loopback, so the box needs no inbound ports beyond SSH. That makes the entire firewall policy four lines:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enableWith nothing open beyond SSH there's nothing else to attack; most of this deployment's security is those four lines plus the loopback default.
Patch the OS. unattended-upgrades, or your distro's equivalent, plus an occasional manual pass. The machine under OpenClaw ages like any other; agent-security talk fixates on the agent while the kernel and sshd go unpatched.
A dedicated non-root user. Run OpenClaw under its own OS user. The VPS docs call for a dedicated user, with one warning worth repeating: don't sign the runtime into your personal Apple, Google, or browser profiles. If a skill misbehaves, the blast radius is that one home directory rather than your personal accounts.
Now the OpenClaw-specific layer, from the project's own docs rather than general hygiene.
Leave the Gateway on loopback. The secure default binds the Gateway to 127.0.0.1, control plane at ws://127.0.0.1:18789. Nothing external can reach it. You reach it through an SSH tunnel, or Tailscale Serve on a tailnet. Loopback plus a tunnel closes about 90% of the attack surface people worry about, because the only thing left facing the world is SSH, which you just hardened.
If you bind wider, auth is mandatory. Bind the gateway to lan or tailnet and you must set gateway.auth.token or gateway.auth.password. And never set gateway.auth.mode="none" on anything exposed: it leaves /tools/invoke, plus any /v1/* endpoints you've enabled, callable without a secret. That's a remote control for an agent with shell access on your machine, and configurations like that get found.
Then check your work:
openclaw security audit
openclaw doctoropenclaw security audit warns about exposure, auth, and tool-policy problems; it's the quickest way to catch a config that drifted from safe defaults. This page covers the server side of hardening. The agent side (tool policy, channels, the rest) is its own piece: openclaw-security-best-practices.
Traffic: nothing in, a short list out
"Agent on a VPS" sounds like it needs open ports. Inbound: zero, if you kept the loopback default. The only exposed listener is SSH, and with SSH moved into a tailnet, none at all.
Outbound is where the traffic is, by design: the box calls out. Two destinations cover nearly all of it: your model provider's API, and api.telegram.org if you've wired up the Telegram channel. That short list is also a diagnostic: a Telegram bot that goes silent on a VPS is often an egress problem, not a code problem, and I wrote that failure family up in openclaw-telegram-bot-not-working.
If you need more than "allow outbound", there's a managed filtering-proxy setup for egress restriction and SSRF/DNS-rebinding protection (OPENCLAW_PROXY_URL, proxy.loopbackMode); OpenClaw's network-proxy doc covers it. For a personal box, loopback plus the four-line firewall is the right baseline.
Tuning small and ARM boxes
On a 1-2 GB VPS or a Pi, three adjustments make a real difference.
Faster starts. NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache and OPENCLAW_NO_RESPAWN=1 in the gateway's environment make starts noticeably quicker on weak and ARM hosts.
Supervision. In the systemd unit: Restart=always, RestartSec=2, TimeoutStartSec=90 (slow boxes may need the full window). Keep state and cache on an SSD; on a Pi that means the USB SSD, not the SD card.
Memory. A gateway that dies with exit 137 was killed by the kernel for running out of memory. The fix is more RAM, or swap at 2 GB and below, per the Pi guide, and the advice transfers to any small VM. When a small box feels slow or keeps falling over, it's nearly always memory pressure or a worn-out SD card. The floor really is about 1 GB.
The hardening checklist, plus my tool that checks it
Before the gateway touches anything real, every line here should be a yes:
- SSH: keys only, password login off, root login off, fail2ban running.
- Firewall: default deny incoming, only SSH allowed.
- OS: automatic security patching on.
- OpenClaw under a dedicated non-root user, signed into no personal accounts.
- Gateway bound to loopback, reached via SSH tunnel or Tailscale Serve.
- If bound to
lanortailnet:gateway.auth.tokenset, andgateway.auth.mode="none"nowhere near an exposed interface. openclaw security auditandopenclaw doctorboth clean.- Backups of state and workspace exist, and you've done one restore drill.
Checking this by hand across boxes gets old, so I wrote an open-source tool that does it: openclaw-hardening-check. It looks at a box's firewall state, gateway exposure, and auth setup for OpenClaw and reports what's off. Disclosure: it's my tool and my repo, and the code is open. Run it, read the code, and skip any check you disagree with.
One habit from production
The Gateway on the VPS owns state and workspace; that machine is the source of truth for everything the agent remembers and every file it produced. Back both up on a schedule, and run the first restore as a drill, not during an incident. openclaw backup create snapshots state, config, and workspace in one command. Same logic for versions: decide your rollback version while everything still works, and update deliberately. That discipline has its own guide: how-to-update-openclaw.
When a VPS is the wrong answer
I put OpenClaw on rented boxes for a living, and I'll still steer you away from one in three cases.
A home box you'll genuinely maintain. Mac mini or Pi: no monthly rent, hardware behind your own router, nobody else operating it. If patching and backups will actually happen at your house, home is cheaper over time and there's nothing wrong with it.
Zero cloud calls as a requirement. A VPS doesn't get you there, and neither does this setup on any host: prompts go out to a model provider's API by design. If nothing may leave hardware you control, you're looking at local models, a different build with different hardware and outside this guide's scope.
You already know you won't harden it. If you read the lockdown section and know none of it will happen, don't put an agent with shell access on a public IP. Run it at home where it isn't exposed, or pay for a managed setup where hardening is someone's actual job. An unhardened agent box on a public IP is the worst available option.
If you'd rather have this done for you
Everything on this page is exactly the work a managed setup takes off your hands: the firewall, the SSH lockdown, the loopback-only gateway, the patching, the backups, the version discipline. That's basically what Cain is: OpenClaw on a dedicated server provisioned for you, one client per server, hardened along the lines of this guide, patched, and kept on a pinned build that passed our upgrade matrix instead of the latest release. The box is provisioned with headroom, 8 vCPU and 16 GB as a floor, so several agents can run at once without the OOM math above. Prompts go straight to the model provider you already pay for, not through a shared cloud. It's one option; the other good one is to rent a $5 VPS and do every step above yourself.
FAQ
What are OpenClaw's system requirements? Node 24 (or Node 22.19+) on macOS, Linux, or Windows (WSL2 is the stable route on Windows). The floor is about 1 GB RAM, 1 core, and 500 MB of free disk on a 64-bit OS; 2 GB+ RAM is comfortable, and at 2 GB or below add swap.
What's the best VPS for OpenClaw? Any Linux VPS. A ~$5/month box from DigitalOcean, Hetzner, Vultr, or Hostinger does it, and Oracle Cloud's Always Free ARM tier does it for free. The brand matters less than 2 GB+ of RAM and whether you hardened the box.
Can I run OpenClaw on a free VPS? Yes. Oracle Cloud Always Free ARM gives you up to 4 OCPU, 24 GB RAM, and 200 GB of storage for free, which runs the Gateway comfortably. The ops and the hardening are still on you.
How do I secure OpenClaw on a VPS? Firewall default-deny with only SSH open; the gateway sits on loopback and needs no inbound ports. SSH by key only, no root login, fail2ban, and keep the OS patched. Reach the gateway through an SSH tunnel or Tailscale; if you bind to lan, set gateway.auth.token, and never expose gateway.auth.mode="none". Then run openclaw security audit and fix what it flags.
Can I run OpenClaw on a Mac mini or Raspberry Pi? Yes to both. A Mac mini works as an always-on macOS box, and a Pi 4 or 5 with 2 GB+ (4 GB is nicer) runs it well if you boot from a USB SSD instead of an SD card. Home is cheaper and more private than a rented box; maintenance, backups, and uptime are on you.
Should I install OpenClaw with Docker or natively? The native installer script is the simplest path and what I'd default to on a VPS. Docker makes sense for containerized or headless environments. Either way, run the Gateway daemon on Node; Bun isn't recommended for it.
How much RAM does OpenClaw need? The floor is about 1 GB; 2 GB+ is comfortable, and at 2 GB or below add swap. If a tiny box keeps dying with exit 137, that's the kernel's OOM killer telling you it's a RAM problem, not a heavy runtime.
Ilya Prudnikov runs private OpenClaw and Hermes instances. These are an operator's notes on VPS deployment, not project documentation; requirements, defaults, and commands drift, so check OpenClaw's current docs for the authoritative version.