I started installing OpenClaw manually — reading through the docs, figuring out each step, hitting the usual walls. It was taking too long, so I stopped and decided to try a different approach. So instead of repeating the process, I wrote a skill for it: a set of instructions and references that lets an AI coding agent handle the whole thing. This is the skill-driven development approach I described in a previous post — let the agent do the work, fix the skill when it gets something wrong, repeat until it gets it right.
The result is a skill that handles the full installation and configuration of OpenClaw on a VPS. You tell your agent "set up OpenClaw on my server" and it walks through everything: provisioning, hardening, messaging channels, backups. The skill encodes the gotchas so you don't have to hit them yourself.
What you get
With the skill loaded, setting up OpenClaw goes roughly like this:
"Set up OpenClaw on my new Hetzner server"
The agent asks a few questions — SSH access details, which messaging channels you want, which model providers you have API keys for — then works through the phases in order. It handles:
- Server provisioning — SSH setup, initial access
- OS hardening — UFW firewall, Fail2Ban, SSH lockdown
- Disk encryption — LUKS full-disk or encrypted block storage volumes
- Runtime installation — Node.js, Python, build tools
- OpenClaw installation — clone, configure, systemd service
- Model configuration — API keys (Anthropic, OpenAI, etc.) or local Ollama
- Messaging channels — Signal, Telegram, WhatsApp, Discord, and others
- Multi-agent routing — different agents for different contacts
- Remote access — Cloudflare Tunnel, Tailscale, or Caddy reverse proxy
- Docker sandboxing — container isolation with proper firewall rules
- Backups — local snapshots, GitHub push, cloud provider images
- Social media integration — optional, third-party schedulers
- Ongoing maintenance — updates, log rotation, health checks
At each step, the agent adapts to your choices. Pick Telegram instead of Signal? The Signal-specific build steps get skipped. Want Tailscale instead of Cloudflare Tunnel? Different config, different verification. The skill describes the trade-offs; the agent presents them and moves on.
Without the skill, an agent can still attempt all of this — the information exists in OpenClaw's docs and platform-specific guides. But it takes hours of trial and error, and several of the issues below are genuinely hard to figure out from scratch.
Issues the skill handles for you
These are the problems that came up during the SDD loop — things the agent got wrong, that I fixed in the skill, and that you won't have to deal with.
Docker bypasses UFW
This one is not well-known. When Docker publishes a port, it writes its own iptables rules that bypass UFW entirely. Your firewall says "deny all incoming," but Docker's containers are wide open anyway.
The skill includes explicit DOCKER-USER chain rules that block all inbound connections to containers unless they come from loopback (127.0.0.1) or your Tailscale CGNAT range (100.64.0.0/10). Without this, any container you run is exposed to the internet regardless of your UFW config.
Signal on ARM64 has no pre-built binary
If you're running on an ARM64 VPS (Hetzner CAX series, for example), signal-cli's libsignal JNI binding doesn't have a pre-built binary. You have to clone the signal-cli repo and build libsignal from Rust source yourself. This requires openjdk-25-jre-headless, build-essential, cmake, libclang-dev, protobuf-compiler, and rustc — a dependency chain that takes a while to sort out.
The skill documents the exact build steps and dependencies. Without it, the agent installs signal-cli, it silently fails at runtime, and you spend a while figuring out why.
Secrets end up in config files
Left to its own devices, the agent will store API keys in environment files or config files because it's the fastest path. The skill enforces storing all secrets in pass (the standard Unix password manager) and reading them at runtime. No API keys in plain text, ever.
Services "started" but not actually running
A common agent failure: it runs systemctl start openclaw, gets no error, and declares the phase complete. But the service might have crashed immediately after starting, or it might be listening on the wrong port, or a dependency might be missing.
The skill marks verification as (Non-Negotiable) — the agent must confirm each service actually responds via HTTP before moving on. This single rule prevented most of the false-completion issues during the SDD loop.
Disk encryption on a cloud VPS
LUKS full-disk encryption on a cloud VPS isn't straightforward. You need to boot into rescue mode, set up cryptsetup, and install dropbear-initramfs so you can unlock the disk remotely after every reboot. The skill documents this path but also offers a simpler alternative: Hetzner encrypted block storage volumes for sensitive data only, which avoids the rescue-boot complexity for most use cases.
Remote access done wrong
Exposing ports directly to the internet is the default instinct, but it's the wrong one. The skill requires one of three approaches: Cloudflare Tunnel (outbound-only, Zero Trust), Tailscale Serve (private mesh), or Caddy reverse proxy with password auth. Each has documented trade-offs. The agent asks which one you prefer and configures it accordingly.
How the skill is structured
The main SKILL.md file is around 160 lines and covers the decision flow and ordering constraints. Detailed procedures live in reference files that the agent pulls in as needed:
| Reference | What it covers |
|---|---|
| Security hardening | SSH config, UFW rules, Fail2Ban jails, Docker iptables bypass |
| Local models | Ollama installation, model selection by RAM, GPU passthrough |
| Messaging channels | Per-channel setup (Signal ARM64 build, WhatsApp QR pairing, Telegram BotFather) |
| Multi-agent routing | Contact-to-agent bindings, DM access policies, agent personalities |
| Remote access | Cloudflare Tunnel vs Tailscale vs Caddy — trade-offs and setup |
| Social media | Third-party schedulers, risk considerations |
| Backups | Local snapshots, GitHub push with deploy key, cloud provider images |
This progressive disclosure keeps context usage reasonable. The full Signal ARM64 build instructions only get loaded if you're actually setting up Signal on ARM64.
Limitations
The skill isn't tied to a specific setup. It asks what you're working with — VPS or local machine, which OS, which architecture, which provider — and adapts accordingly. It can fetch current VPS pricing (Hetzner CAX series, DigitalOcean, etc.) so you can compare options before committing. If you want to run OpenClaw on a spare laptop instead of a cloud server, it adjusts the flow — no VPS provisioning, different networking, local Ollama instead of cloud API keys.
That said, my own setup (Hetzner ARM64, Ubuntu 24.04) is the only tested path so far. Other combinations should work but may have gaps in the gotcha coverage.
The skill is also a snapshot as of early 2026. OpenClaw is actively developed. Signal might ship ARM64 binaries eventually. Docker might fix the UFW bypass. Treat specific version numbers with appropriate skepticism.
And while the skill handles the setup, it doesn't replace understanding what's running on your server. If something breaks outside the skill's playbook, you'll need basic comfort with SSH, firewalls, and systemd to debug it.
Getting it
npx skills add https://github.com/souliane/skills --skill ac-openclaw -g -y
It works with any AI agent that can read files and run commands.
Top comments (0)