The fastest way to get real value out of OpenClaw is to build it small. Not "my second brain, my inbox, my calendar, my life" — one narrow job, done reliably, on hardware that never sleeps. Mine is family tech support: the recurring stream of printer errors, router mysteries, and "which button do I press" questions that used to arrive in my Telegram at all hours. I scoped an OpenClaw agent to exactly that job, running on a cheap Hostinger VPS, and this post is the actual build — the config decisions, the security rules, and the parts most write-ups get wrong.
I run my production infrastructure on Hostinger already, so putting an agent on a VPS there was the path of least resistance for me. It also turned out to be the right architecture for reasons I did not expect, which we will get to.
What OpenClaw Is, in One Paragraph
OpenClaw is Peter Steinberger's open-source personal AI assistant: a gateway process that connects an LLM backend of your choice (Claude, GPT, local models) to the messaging apps you already use — Telegram, WhatsApp, Discord, Signal — with persistent memory and the ability to run tools on the machine it lives on. It started life as Clawdbot in November 2025, became Moltbot on January 27, 2026 after an Anthropic trademark complaint, and landed on OpenClaw two days later. It passed 247,000 GitHub stars within roughly three months of launch, and Steinberger announced on February 14, 2026 that he was joining OpenAI, with the project continuing as a community effort. That is the whole news cycle. Everything below is the part that survives it.
Why a VPS Instead of a Mac Mini
The popular OpenClaw setup is a Mac Mini on your desk. I went the other way, and the reasoning is worth spelling out.
First, the always-on requirement. A personal assistant that lives on your laptop is an assistant that sleeps when your lid closes. Family tech-support requests do not respect my Wi-Fi geography. The agent needs to be a service, and services belong on servers.
Second — and this is the part I would emphasize even if I were not already a Hostinger customer — the VPS is a blast-radius decision, not just an uptime decision. OpenClaw is a high-privilege agent platform: it executes tools, installs community skills, and holds credentials. On your personal machine, a compromised skill sits next to your SSH keys, your password manager, and your browser sessions. On an isolated $10-a-month VPS, the worst realistic outcome is that I destroy and reprovision a disposable box. Given what has happened in the OpenClaw skills ecosystem this year (real numbers below), that isolation is not paranoia; it is the baseline I would recommend to any client.
Third, the hardware math. You are not running the LLM on this box. The model inference happens at Anthropic or OpenAI or wherever your API key points. The VPS runs the gateway loop, the channel listeners, and your tools — a workload that idles in a few hundred megabytes of RAM. You need a small, always-on Linux box, not a GPU. Hostinger ships a one-click OpenClaw Docker template through its hPanel Docker Manager, and its own docs recommend the KVM 2 tier (2 vCPU, 8 GB RAM) for comfortable headroom; the entry KVM 1 tier works for a single scoped agent like mine. Promo pricing sits under $10 a month — check the renewal price before you commit to a term, because it roughly doubles.
The Build
The sequence, condensed to what matters:
1. Deploy. Either the Hostinger template (pick OpenClaw in Docker Manager, fill in the environment variables, deploy) or a manual install on any Linux VPS. Either way you end up with the OpenClaw gateway running as a persistent service.
2. Lock the gateway down before anything else. The gateway listens on port 18789 by default. That port must never be reachable from the public internet. Bind it to 127.0.0.1 and reach the dashboard through an SSH tunnel when you need it:
ssh -L 18789:localhost:18789 user@your-vps
Then open http://localhost:18789 locally. This is the same discipline I use for every admin surface on my production servers, and OpenClaw's own guidance agrees: loopback only, reverse proxy with auth if you truly need remote access.
3. Create the Telegram bot. Message @BotFather, run /newbot, name it, and copy the token. The token goes into the environment configuration, never into any file a skill can read. Pair the bot with OpenClaw's Telegram channel config, then message your bot once so the pairing handshake completes. If you want it in a family group chat, add it and grant it permission to read messages (Telegram bots default to a privacy mode that hides group messages from them).
4. Scope the agent with SOUL.md. This is the file that decides whether you built a delegate or a liability.
SOUL.md: Scope Is the Feature
OpenClaw reads a workspace file called SOUL.md that defines the agent's persona, purpose, and constraints. The abbreviated version of mine:
# Soul
You are Mejba's tech-support assistant. Your one job is handling
recurring technical questions from his family on Telegram.
## Voice
- Warm, brief, practical. Answer first, explanation second.
- Bengali or English, matching whichever the sender used.
- You are an assistant and you say so if asked. You do not
pretend to be Mejba.
## Rules
- Printer, router, phone, TV, account-recovery questions: answer.
- Anything involving money, passwords being shared in chat, or
buying things: do not act. Reply that Mejba will follow up.
- If the same person asks the same question a third time, write
a step-by-step note they can save, instead of another chat reply.
- Never install anything, never run commands on anyone's device
remotely, never open links sent by unknown numbers.
Two deliberate choices here. The assistant identifies itself as an assistant — an agent that impersonates you to your own family is a trust debt you will eventually pay with interest, and it gains you nothing. And the refusal rules are broader than the capability rules. The escalation list (money, credentials, purchases) is the part I expect to grow forever, because every month of operation teaches you a new category of message you do not want a bot answering.
That last point is the insight I would put on a poster: you discover the correct scope of a personal agent by running it, not by designing it. My first SOUL.md was half this strict. The rules above are what remained after watching real family messages hit it.
The Security Section You Should Not Skip
OpenClaw's growth attracted the supply-chain attackers you would expect, and the numbers are not hypothetical. Koi Security's audit of ClawHub, the community skills marketplace, found 341 malicious skills out of 2,857 examined — 335 of them part of one campaign distributing the Atomic macOS Stealer, disguised as crypto wallets, trading bots, and YouTube utilities, often with typosquatted names. Separately, CVE-2026-25253 (CVSS 8.8) was a genuine remote-code-execution flaw patched in January. This is a young, high-privilege platform with a package ecosystem; treat it the way you treated npm in 2016, except the packages can use your credentials conversationally.
My standing rules, all of them cheap:
- No ClawHub skill goes on the box unless I have read its SKILL.md and its scripts. Every skill runs with the agent's full privileges. For a scoped bot like mine, the correct number of community skills is close to zero — I wrote the two tools it needs myself.
- Gateway on loopback, always (step 2 above). Most published OpenClaw horror stories start with an exposed control port.
- Update on a schedule. Fast-moving project, fast-moving patches. The January RCE was fixed quickly; unpatched instances are the ones that got hurt.
- Keys live in the environment with least privilege, and the VPS holds nothing else I care about. My production servers and this agent box share a hosting provider and nothing else.
I wrote more broadly about vetting agent capabilities before granting them in my secure AI agent onboarding guide, and about OpenClaw's risk surface specifically in OpenClaw's autonomous agent security risks — the short version of both: an agent's permissions, not its intelligence, determine how bad its worst day is.
What It Actually Handles, and Where It Fails
After running this, the honest scorecard: the bot resolves the majority of routine questions without me — error-code lookups, settings walkthroughs, the eternal "turn it off and on, but in which order" genre. The step-by-step-note rule turned out to be the highest-value behavior, because repeated questions were most of the volume.
Where it fails is instructive. It cannot see hardware, so anything requiring eyes ("which light is blinking?") turns into a photo request, and photo quality from a stressed parent is its own comedy. And it occasionally over-helps — early on it produced a beautifully formatted, slightly wrong router guide because the model preferred completeness to admitting uncertainty. The fix was a SOUL.md line telling it to ask one clarifying question before any multi-step answer. Scope, again.
If you want the broader map of where OpenClaw fits among agent setups, my OpenClaw agent setup guide covers the general installation in more depth, and building an AI operating system around Claude Code shows the other end of the spectrum — the developer-side agent stack this assistant deliberately is not.
Start with one job. A bot that handles printer errors completely beats a "life assistant" that handles everything badly, and the scoped version teaches you what to build next.
If there is a workflow in your business that deserves this treatment — one recurring stream of requests, handled by an agent with hard boundaries — tell me about it and I will tell you honestly whether an agent is the right tool for it.
