A tiny engineer pauses at the foot of the stone temple steps, holding a small checklist scroll, facing a colossal newly-arrived pedestal that glows warm amber with a lobster-claw silhouette inside — held back behind a half-built protective cage of thin gold lattice and one band of claw-red caution cordon, not yet allowed onto the platform.
June 22, 20266 min readby Rishabh Kumar

Before I Self-Host OpenClaw: An Honest Pre-Flight From the Guy Whose Agent Mined Monero

OpenClaw went from nine thousand GitHub stars to sixty thousand in a single weekend, and it hasn't slowed down since — it's north of 210,000 now, which makes it one of the fastest-climbing open-source projects anyone has ever watched in real time. It's a self-hosted personal AI assistant: you run it on your own box, it wires a model into your messaging apps, your browser, and your shell, and — the headline trick — it will write its own new skills. My first instinct was to put it on my VPS that same night.

I didn't. This is the honest reason why — and it has nothing to do with OpenClaw being a bad project, and everything to do with the afternoon a stranger turned my last self-hosted agent into a Monero miner. So before OpenClaw goes anywhere near my real credentials, consider this the pre-flight I wish I'd run the first time: what it actually is, why the whole internet starred it in a weekend, the part my last agent taught me the expensive way, and exactly how I'd cage it on my box. I'll say it plainly up front — I haven't deployed it yet. This is the honest read before the install, not a hands-on log of one.

What OpenClaw actually is

OpenClaw is the project formerly known as Clawdbot, built by Peter Steinberger, the founder of PSPDFKit. It picked up the OpenClaw name after going viral in January 2026; Steinberger has since joined OpenAI and handed the project to an open-source foundation. At its core it's a local-first gateway: it connects an AI model — OpenAI, Anthropic, or Google on the back end — to fifty-plus integrations like WhatsApp, Telegram, Slack, Discord, Signal, and iMessage.

The pitch is seductive if you've read my self-hosting stack: it runs entirely on your own devices, your data never leaves your machine, and it can browse the web, fill out forms, run shell commands, write and execute code, poke your smart home, and autonomously develop new skills for itself. It's the assistant a lot of us have been hand-rolling out of cron jobs and glue code, except someone built the polished version and gave it away.

Why the internet starred it in a weekend

The appeal isn't hard to read. Every hosted AI assistant asks you to pour your messages, your calendar, and your half-formed ideas into someone else's cloud. OpenClaw flips that: it's your assistant, on your hardware, talking to the apps you already live in, with a one-command install and a friendly onboarding wizard. For the self-hosting crowd it hits the exact nerve a managed product can't — ownership. You're not renting a seat; you're running the thing.

And to be fair, the local-first design is a genuinely good instinct. Keeping the orchestration on your own box is the right default. The catch is that 'on your own box' moves every hard security decision onto you, too — which is where my history starts whispering.

The part my last agent taught me the hard way

Read that capabilities list again, but as a threat model instead of a feature list: an always-on process that takes instructions in plain English, holds the keys to my messaging apps, and can run arbitrary shell commands. That is, almost line for line, a description of the agent I already got burned by. Mine had an exposed control plane and ran as root. A prompt injection walked straight in and spent an afternoon mining Monero on my CPU. The lesson I carried out of that wreck now shapes everything I put on the box: anything that takes untrusted input and then acts on it should be treated as already compromised.

OpenClaw's own community is refreshingly honest about this. Security researchers have flagged the broad permissions the agent asks for, and the skill repository — the very thing that lets it 'learn new skills' — isn't rigorously vetted, which makes a malicious skill a supply-chain problem waiting to happen. Microsoft's security team went as far as recommending you only run it in an isolated environment with no access to any credentials or data you can't afford to leak. When the people writing the guides are this blunt, you listen.

Reading the install before I run it

The boring facts first, because they matter. OpenClaw wants Node.js 22 or later, and the recommended path is Docker for isolation and clean updates. The shell installer drops a ~/.openclaw/ config directory and an openclaw onboard wizard that walks you through the gateway, workspace, channels, and skills. Plan for at least 2 vCPU, 4 GB of RAM and 20 GB of disk on Ubuntu 22.04 or 24.04; 4 vCPU and 8 GB is the comfortable setting.

And then there's the line from OpenClaw's own docs that made me close the tab and start writing this instead of installing: do not expose port :18789 publicly without TLS and authentication. Bind it to 127.0.0.1. The local-first promise is real, but it's conditional: misconfigure one interface and your private assistant becomes a public one. I've met that exact failure mode. I'm not meeting it twice.

How I'd cage OpenClaw on my VPS

So here's the deployment I'd actually trust — the same least-privilege playbook I rebuilt my ops agent around, applied before the first run rather than after the first incident:

# how I'd cage OpenClaw before trusting it on my box
user     -> dedicated, unprivileged 'openclaw' account (never root)
runtime  -> Docker container, scoped volumes only, CPU + memory quota
network  -> bind 127.0.0.1:18789, NO open inbound port
access   -> reach it via Cloudflare Tunnel + auth, never a public port
creds    -> throwaway API keys + dummy accounts, zero real secrets
skills   -> review every skill before install; treat the repo as untrusted
assume   -> it WILL be prompt-injected; design for the blast radius

None of this is exotic. It's the boring discipline that turns 'an agent with shell access' from a liability into a tool. The unprivileged user and Docker quota cap what a runaway process can touch. Routing access through a Cloudflare Tunnel instead of an open port means there's no :18789 listener for a scanner to find in the first place. And the throwaway-credentials rule is the one I'd never skip again: if it gets popped, it gets nothing worth having.

The honest verdict

Would I run OpenClaw? On a throwaway VPS, with dummy accounts and keys I'd happily rotate, absolutely — it's the most exciting self-hosted thing of 2026 and it deserves the stars. Next to my real stack, my real credentials, and the database that runs this blog? Not until it's caged exactly like the list above. The number that should drive that decision isn't 210,000 GitHub stars. It's blast radius.

That's the pre-flight. When I do put OpenClaw on the box — caged, sandboxed, and wired through the tunnel — you'll get the hands-on version: what the onboarding actually feels like, which skills earn their keep, and whatever breaks that I didn't see coming. Because the first time, the thing I didn't see coming cost me an afternoon and a chunk of someone else's Monero. This time, I'm reading the manual first.

More writing

Like what you read?

Stay in the loop.

New articles on engineering, architecture, and building software that lasts. Straight to your inbox.

or follow