JW
Writing

Running OpenClaw on a VPS Without Ruining Your Life

I like OpenClaw. You set it up on a VPS, connect it to Telegram or WhatsApp, and you've got an always-on assistant that can run shell commands, manage files, automate things while you're not at your desk.

But here's what people don't think about before they start plugging in API keys and connecting their personal accounts: every chat platform you connect to OpenClaw is an open door. Anyone who can message you can try to prompt-inject your agent. And your agent has shell access.

The lethal trifecta

OpenClaw has three properties that, together, make for a bad time if you're not careful:

  1. It can execute shell commands and access files on the host machine.
  2. It accepts input from messaging platforms (WhatsApp, Telegram, Signal) where other people can message you.
  3. It runs autonomously, often without you watching.

Every messaging platform OpenClaw connects to is an attack surface. Anyone who can send you a message can attempt a prompt injection. A crafted WhatsApp message from a stranger, a Telegram group message, a forwarded link with embedded instructions. The agent reads it, interprets it, and it has shell access.

Prompt injection is unsolved. Nobody has a reliable way to separate "real instructions" from "injected instructions" in arbitrary text. If someone can get text in front of your agent, they can try to make it do things.

So the security model isn't "be careful what you connect." It's: assume the agent will eventually be manipulated, and make sure that doesn't matter.

If OpenClaw has your personal email credentials and someone prompt-injects it into forwarding your inbox, that's catastrophic. If it only has a throwaway email and capped API keys, the same attack is meaningless. The difference isn't whether the attack happens. It's whether you care when it does.

Give it its own identity

This is the step people skip because it feels like overkill. It's not.

Make a new GitHub account. Don't add the VPS as an SSH key on your personal GitHub. Create a separate account and add it as a collaborator on the repos you want it to work with. If that account gets compromised, you revoke access. Your personal account, your private repos, none of it is touched.

Same for email. OpenClaw connects to services that need email verification. Don't give it yours. Create something like openclaw-worker@proton.me. If it gets compromised, you shrug.

Same for Vercel, Supabase, whatever your stack needs. Isolated blast radius for each one.

You wouldn't run a web server as root. Don't run an agent that accepts input from strangers with your personal identity.

Every API key is already stolen

That's the mindset. Every key you put on that VPS should have limits that make theft boring.

Set spending caps. OpenAI, Anthropic, whatever model you're feeding OpenClaw. Set a hard monthly cap you're comfortable losing entirely. Not "comfortable" as in "it's fine," but "comfortable" as in "I'll be annoyed, not in trouble."

Use the narrowest scope possible on every token. Read-only where you only need reads. Repo-specific where you only need one repo. Don't use admin tokens when contributor tokens exist.

Use short-lived tokens where services support them. Rotate regularly. A key that's been sitting there for six months without rotation is six months of unnecessary exposure.

Keep your VPS keys and local keys separate. Different keys for different machines. When the VPS key leaks, you revoke it without disrupting your own workflow.

The litmus test: "If this key appeared on a public GitHub repo right now, what's the worst that could happen?" If the answer goes beyond "someone runs up a capped bill," tighten it.

Getting secrets onto the server

Sometimes you need to get a key onto the box. The best option is just SSH. You're already authenticated, the channel is encrypted, copy the key directly into an environment variable or secrets manager on the server. Done.

If for some reason you need to send a secret through a less secure channel (chat, for example), encrypt it first. Share a symmetric key through a secure channel once at setup time, then encrypt any subsequent secrets before transmitting. The encrypted blob is useless without the key even if someone reads the message.

If you can't do that either, something like Privnote (one-time-read, self-destructing notes) is still better than pasting raw secrets into a chat window. Not great, but better than nothing.

The hierarchy: SSH directly > encrypted via pre-shared key > Privnote > don't.

On the VPS itself, secrets belong in environment variables or a secrets manager. Not in .env files sitting in home directories or committed to repos. If you must use files, lock down permissions.

Network basics

SSH key authentication only. Disable password auth. Use a dedicated SSH key for this VPS, not the same one you use for GitHub or other servers.

Firewall everything you don't need open. If OpenClaw doesn't need to serve web traffic, close 80 and 443.

The VPS shouldn't be able to reach your home network, your company VPN, or any internal services. It's an isolated box on the internet. Keep it that way.

What doesn't belong on that server

  • Your personal email credentials. Ever.
  • Cloud storage tokens. No Google Drive, no Dropbox, nothing touching your personal files.
  • Password manager access.
  • Production database credentials. Read-only replica if it truly needs DB access. Never write access to prod.
  • Credentials to other servers. The VPS shouldn't be a stepping stone into the rest of your infrastructure.

Simple rule: if losing this data would keep you up at night, it doesn't go on that server.

Setup checklist

  1. Fresh VPS (Hetzner, whatever). New SSH key pair just for this box.
  2. Dedicated GitHub account, added as collaborator to relevant repos.
  3. Dedicated email for service signups.
  4. All API keys created fresh with spending caps and minimal scopes.
  5. Secrets transferred via SSH, stored as environment variables.
  6. Firewall configured, password auth disabled, nothing unnecessary open.
  7. Nothing personal on the machine. No personal tokens, no personal accounts, no personal data.
  8. Connect your chat app (Telegram, WhatsApp, Signal) and start using it.

Once it's set up

You stop worrying. OpenClaw runs, handles tasks, messages you through your chat app, and if the entire VPS got compromised tomorrow you'd lose some compute time and a few capped API keys. No personal data. No long-term access to anything that matters.

That's the bar. Meet it, and the rest is just figuring out what to make it do.