This OpenClaw runbook was checked against a May commit and still says so

The header states which commit the guidance was verified against

The first thing the document does is date itself. A blockquote at the top says it was 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 is the single most useful line on the page and it is the reason to keep the page around. Configuration in a tool like this changes names and defaults between releases, so a runbook without a pinned revision is a set of guesses. The repository's own last push is dated 2026-05-26, one day after the commit it was checked against, and there are no GitHub releases, so there is nothing newer to compare against. Read the config with that date in mind and verify each key against the build you actually run.

Four disclaimers, and they are the most useful part

The document spends as much space disclaiming itself as describing itself. It is not official OpenClaw documentation. It is not a universal best setup. Under What this is not, the specific list reads: not a beginner replacement for the official docs, not a model leaderboard, not a ClawHub install guide, and not a claim that the author's exact config is right for everyone. The framing sentence above those lists is the useful one, that this is the way the author runs OpenClaw after enough broken configs, noisy agents and avoidable risk to want something predictable, and that it is written from the post-honeymoon phase. That is a statement about what kind of document you are reading: one operator's settled practice, not a comparison.

The gateway stays on loopback and Tailscale does the reaching

The access stance is the most transferable part of the whole runbook. Tailscale is the normal access path, and the text goes further than most setups would: it is used as the access route even when the author is sitting at the machine locally. The OpenClaw Gateway stays loopback-bound, and Tailscale handles anything remote. That ordering is the security property, because there is no listening socket on a routable interface for anything to find. For people who will not sign up for Tailscale, the fallback offered is to keep OpenClaw local and use a messaging channel such as Telegram for remote use. What is warned against is public ports and casual LAN exposure, phrased as something to avoid unless you know exactly what boundary you are accepting.

ClawHub is a search engine in this setup, and the config says so

The skills stance is a refusal with a procedure attached. The recommendation is not to install third-party skills from ClawHub blindly. Instead, use ClawHub as a discovery and source-reading tool: find an idea, read the source, then ask your agent to rebuild a local skill for the specific setup. The trade is stated openly, that this is slower than clicking install but safer than trusting unknown code, broad tool assumptions, hidden behaviour, or token-heavy abstractions. Those five nouns are the actual risk list, and they map onto what a skill can do to a running agent. The concrete detail that makes the stance checkable is in the example config: `clawhub` is disabled on purpose. If your config has it enabled, you have drifted from the documented setup without deciding to.

A single guide file carries the actual setup

The bulk of the content is one document, `guide.md`, which the README links as the main guide and says covers the current setup flow, Tailscale-first access, model routing, memory, automation, skills and security. Everything else in the repository is reference material around it. That structure is worth noting because it tells you where to look when something breaks: the guide for the shape of the setup, `examples/` for a concrete config and prompts, and `showcases/` for automation you can lift. The README is an index and a set of disclaimers rather than a tutorial, which is consistent with the audience it claims. It is aimed at people who want OpenClaw to run for weeks rather than minutes, so the guide assumes you have already been through an install and a first hour.

The examples folder is mostly prompts and security baselines

Fifteen files sit in `examples/`, and the mix tells you what this runbook thinks needs writing down. Security takes four: `security-hardening.md` for a baseline and audit workflow, `security-quickstart.md` with prompts for applying basic guardrails, `security-patterns.md` for prompt injection rules, and `vps-setup.md` for a VPS with Tailscale as the default remote path. Configuration takes three, including a sanitized config reference and a section-by-section guide. Operations take the rest: `spawning-patterns.md` for current `sessions_spawn` and subagent patterns, `heartbeat-example.md` for a heartbeat checklist and a `tasks:` pattern, and `task-tracking-prompt.md` for using OpenClaw's own task ledger instead of an external black box. Only one file is executable, `check-quotas.sh`, and it is marked optional with its own README.

Showcases mix the author's own work with community contributions

Nine entries live in `showcases/`, and they are not all the same kind of thing. Several read like personal automation: a daily brief with weather, calendar and tasks, overnight research on captured ideas, a weekly LinkedIn drafter, curated tech news. Others are infrastructure or review: `homelab-access.md` describes safer remote SSH through Telegram confirmations, `agent-orchestrator.md` routes coding tasks to configured agents and tools, and `coeus-knowledge-base.md` is a local semantic knowledge base example. Two are flagged as community contributions, an autonomous operation health-check pattern and `claworc.md`, described as a review of an external control-plane project. The instruction attached is to treat all of them as starting points and to review tool access, channels, delivery targets and model choices before running them unattended.

Contributing is welcome and explicitly not a free-for-all

The contributing section is two sentences and the second one is the point. Contributions are welcome, but this is not a free-for-all, and the README asks people to read `CONTRIBUTING.md` before opening issues or pull requests. Given the subject matter, that is a sensible boundary: a runbook about not trusting unreviewed automation has to hold contributors to the same standard it holds ClawHub. The project is MIT licensed, has a `CODE_OF_CONDUCT` reference through the usual repository conventions, and carries the standard set of pointers to community resources including the official documentation, ClawHub framed again as a discovery and source-inspection tool rather than something to install from blindly, and three community awesome lists. The site is an Astro project with a sitemap integration, a TypeScript config and a `mise.toml` for tool versions.

Editorial conclusion

This is worth reading if you have already installed OpenClaw and something about running it for weeks feels wrong, because the value is in the refusals rather than the steps: no public ports, no blind ClawHub installs, and an explicit list of what the document is not. It is not a substitute for the official documentation, which the runbook says twice in different words. Two things to weigh. The guidance is verified against a single OpenClaw commit from 2026-05-25 and an example config from a 2026.5.x setup, while the repository itself has not been pushed to since 2026-05-26, so treat every config key as needing rechecking against your own build rather than as current. And the showcases directory mixes the author's patterns with community contributions and a review of an outside control-plane project; the runbook says so, and the reason to read that warning is that unattended automation is exactly where an unreviewed tool access turns into an incident.

Frequently asked questions

Official sources

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