OpenClaw Runbook: An Opinionated Operating Guide, Not Official Docs

The problem: agents that run for minutes, then cost money or leak a port

The README frames the project around three failure modes it says it exists to prevent: burning money, exposing your gateway, and trusting random automation you did not inspect. That is a narrower promise than most agent tooling makes. It is not trying to make OpenClaw easier to install, and it explicitly says it is not a beginner replacement for the official documentation. It is written, in the author's words, from the post-honeymoon phase, which is a useful signal about who the audience is. The intended reader already has OpenClaw running and has hit the point where a working demo is no longer the problem. The problem is predictability over weeks. The repository is a runbook in the literal sense: a set of procedures and stances for day-to-day operation, plus example configs and prompt templates that the author actually uses. Anyone evaluating it should read the access stance and skills stance first, because those two positions drive most of the concrete guidance that follows.

Tailscale-first access and a loopback-bound gateway

The access stance is the most concrete architectural decision in the material. The author states that Tailscale is the normal access path, including when local, and that the Gateway stays loopback-bound while Tailscale handles remote access. That is a specific boundary: the service does not listen on a public interface, and remote reachability is delegated to the overlay network. The README offers an explicit alternative for people who will not sign up for Tailscale: keep OpenClaw local and use a messaging channel such as Telegram for remote use. It then warns against public ports and casual LAN exposure unless you know exactly what boundary you are accepting. Note what this section does not contain. There is no port list, no firewall rule set, no ACL example. The vps-setup.md file in examples/ is described as covering VPS setup with Tailscale as the default remote access path, so the operational detail lives there rather than in the README. If you need the exact steps, that file is the one to open, and the README alone will not tell you whether your provider's networking model fits.

Skills: ClawHub as a reading list, not an installer

The skills stance is a deliberate constraint rather than a feature. The author does not recommend installing third-party skills from ClawHub blindly, and describes the intended workflow as using ClawHub for discovery and source reading: find an idea, inspect the source, then ask your agent to rebuild a local skill for your setup. The stated trade-off is speed against risk, with the risks named as unknown code, broad tool assumptions, hidden behavior, and token-heavy abstractions. The example config keeps clawhub disabled on purpose, which means the default posture is that the install path is closed until you open it. There is a prompt template for this at examples/skill-builder-prompt.md. This is the part of the project most likely to frustrate new users, because it converts a one-click action into a reading and rewriting task. It is also the part that is hardest to argue with on its own terms: rebuilding a skill locally is the only way to know what tools it assumes. Whether that cost is worth paying depends on how many skills you intended to run.

What is actually in the repository, and how the guide is laid out

The repository is an Astro site published at digitalknk.github.io/openclaw-runbook, with the main written guide in guide.md at the root. The README states that guide.md covers the current setup flow, Tailscale-first access, model routing, memory, automation, skills, and security. Two supporting directories carry the operational weight. examples/ holds templates and references: sanitized-config.json as the current sanitized config reference, config-example-guide.md as a config section reference, agent-prompts.md, spawning-patterns.md for sessions_spawn and subagent patterns, heartbeat-example.md with a tasks: pattern, task-tracking-prompt.md, and four security files (security-hardening.md, security-quickstart.md, security-patterns.md for prompt injection rules, and vps-setup.md). check-quotas.sh is described as an optional quota check helper. showcases/ holds adaptable automation patterns such as daily-brief, idea-pipeline, linkedin-drafter, tech-discoveries, homelab-access, agent-orchestrator and coeus-knowledge-base. Two entries, autonomous-operation.md and claworc.md, are labelled community-contributed, and the README asks that their attribution be kept intact. Treat showcases as starting points, and the README says to review tool access, channels, delivery targets and model choices before running them unattended.

Running it: config files, prompts and one helper script

There is no install command in the README. The material gives you a set of files to copy from rather than a package to add. The config reference is examples/sanitized-config.json, with examples/config-example-guide.md as the section-by-section explanation of the keys it contains. The config is pinned: the README states it is checked against OpenClaw at commit 5dccba7405 dated 2026-05-25, and that the example config is based on a working 2026.5.x setup. That pin matters, because a sanitized config is only meaningful against the schema it was written for. The one executable artifact named in the README is examples/check-quotas.sh, described as an optional quota check helper. The security path is documented as prompts rather than scripts: examples/security-quickstart.md is described as prompts for applying basic guardrails, and examples/security-hardening.md as a security baseline and audit workflow. For heartbeat scheduling the relevant file is examples/heartbeat-example.md, which the README says contains a checklist and a tasks: pattern. If you want to follow this runbook, the practical order is: read guide.md, diff sanitized-config.json against your own config with config-example-guide.md open beside it, then take the security prompts. Nothing here runs itself.

Where this runbook is the wrong tool

The README is unusually direct about its own limits, and those limits are real. It is not official OpenClaw documentation, it is not a universal best setup, and it is not a claim that the author's exact config is right for everyone. It is also not a ClawHub install guide, which follows from the skills stance. The sharper limitation is the pin. A runbook checked against commit 5dccba7405 and a 2026.5.x config drifts the moment OpenClaw's config schema or session APIs change, and the repository has no releases, so there is no versioned artifact to track. You get a git history and a last-push date, nothing more. The second limitation is coverage: the README states plainly that it is not a beginner replacement for the official docs, so if you have not yet stood OpenClaw up, this is the wrong first document. The third is the Tailscale dependency. The fallback it offers (local plus Telegram) is a different operational shape with its own surface, and the README does not attempt to make the two equivalent. If your environment forbids overlay networks and you need remote dashboard access, this runbook's central recommendation does not apply to you.

How it differs from the official docs and the awesome lists

The community resources section names the alternatives directly, and the difference in approach is clear from how each is described. The official OpenClaw Docs at docs.openclaw.ai are the reference for what the software does. The awesome-openclaw-usecases, awesome-openclaw and awesome-openclaw-skills repositories are collections: real-world use cases, curated tools and community-contributed skills. Those lists optimise for breadth of discovery. This runbook optimises for a single operating posture that one person has sustained, and it is willing to tell you not to install things. The closest thing to a peer project inside the repository is claworc.md, described as a community-contributed review of an external control-plane project, which suggests a different answer to the same problem: centralising control rather than documenting a personal stance. If your need is a catalogue of what is possible, the awesome lists serve you better. If your need is a defensible default for access and skill provenance, the runbook's narrowness is the point, and the fact that it argues against installing from ClawHub is the clearest expression of that.

Maintenance, licence and what to check before you commit

The project is MIT-licensed, which permits reuse and modification of the guide text, config templates and prompts, subject to the licence terms; that is a statement about the licence, not legal advice, and you should read the LICENSE file for the operative wording. Maintenance cost sits on you, not on the repository. There are no releases to upgrade through, so the upgrade path is re-reading guide.md and re-diffing examples/sanitized-config.json against your config whenever OpenClaw changes, with commit 5dccba7405 as your reference point. The repository is not archived and the last push recorded is 2026-05-26, one day after the commit the README cites, so the pin and the code were in sync at that moment. Contributions are accepted but gated: the README asks that you read CONTRIBUTING.md before opening issues or pull requests, and it states that this is not a free-for-all. Before adopting anything here, confirm that your installed OpenClaw version still matches the pinned schema, that sanitized-config.json parses against it, and that check-quotas.sh runs with your provider credentials. If any of those three fails, you are reading a historical document rather than a runbook.

Editorial conclusion

Adopt this runbook if you already run OpenClaw and want a documented, Tailscale-first baseline for access, model routing and skill handling, and you accept that its config is one person's working setup pinned to commit 5dccba7405. Do not adopt it as a beginner substitute for the official docs, and do not copy the sanitized config into production without checking each key against your own OpenClaw version. Verify first that the commit the README cites still matches your installed release, that examples/sanitized-config.json parses against it, and that examples/check-quotas.sh works with your provider credentials before you rely on it for cost control.

Official sources

1. digitalknk/openclaw-runbook on GitHub
2. Issues
3. License: MIT
4. Project website
5. README