# Edición en español Esta versión en español fue preparada para que la experiencia principal del producto sea en español. El nombre de marca **AI Operator Playbook** se mantiene igual. --- # AI Operator Starter Guide for OpenClaw _Subtitle:_ Install OpenClaw on a VPS or private server, connect your first channel, and configure a safe, useful assistant without getting lost. _Version:_ Draft v2 _Last updated:_ 2026-03-18 UTC --- # Introduction Most people do not get stuck with OpenClaw because the idea is bad. They get stuck because the path from “I want this” to “I have a working assistant” is full of small technical decisions, confusing defaults, and avoidable mistakes. This guide exists to remove that friction. It is a beginner-first manual for people who want to install OpenClaw on: - a VPS - a private Linux server - a home server - a server with a VPN or tunnel access pattern And more importantly, it is about more than installation. A real OpenClaw setup should leave you with: - a healthy service - a working channel - a clear workspace - an assistant with identity - a memory structure that survives resets - basic safety rules - one useful workflow running That is the difference between “software installed” and “assistant operational.” --- # Part 1 — What success looks like A beginner install should be considered successful only if all of this is true: - OpenClaw is installed cleanly - the gateway is healthy - `openclaw status` shows a sensible state - one messaging channel is working - the assistant answers in the expected place - the workspace files are in place - the assistant has identity and memory structure - safety boundaries are written down - one first workflow is usable If you only have the software running, but not the rest, you are halfway there. --- # Part 2 — The best beginner deployment path The easiest route for most buyers is: ## Recommended baseline **Ubuntu VPS + SSH + OpenClaw + Telegram + file-based memory + conservative safety defaults** Why this path is the best baseline: - easy to document - easy to repeat - easy to support - easier to troubleshoot than custom home networking - enough flexibility for future upgrades ## Alternative path: private/home server Use this if: - you want more infrastructure control - you care about local ownership - you already run a Linux box reliably ## Alternative path: VPN/tunnel-assisted access Use this if: - you want safer admin access - you do not want to expose more surfaces than necessary - you want a tighter networking posture Important beginner note: Do not make the networking layer more complex than the product requires on day one. A slightly simpler deployment that works is usually better than an elegant architecture you cannot maintain. --- # Part 3 — Before you install ## What you need At minimum: - a Linux machine or VPS - SSH access - basic ability to copy/paste commands carefully - the patience to validate one layer at a time ## What you do not need You do not need to be: - a DevOps expert - a Linux kernel wizard - a full-time sysadmin ## What you should decide first Before installation, decide: - is this personal or business use? - do I want a VPS or a private machine? - what channel am I connecting first? - how conservative should the assistant be? These answers change the right setup. --- # Part 4 — Installation best practices ## Best practice 1 — Start with a clean environment A fresh machine reduces: - package conflicts - mystery processes - unclear permissions - debugging noise ## Best practice 2 — Validate the machine before blaming OpenClaw Check first: - internet access - package manager works - enough disk and RAM - machine time is sane - SSH is stable ## Best practice 3 — Use one channel only at first This is one of the highest-leverage beginner rules. Do not connect everything at once. Choose one. For most beginners, **Telegram is the best first option**. ## Best practice 4 — Follow the official install path first Do not build your installation from random snippets unless you know exactly why you are deviating. ## Best practice 5 — Validate each layer before moving on A strong install rhythm is: 1. machine ready 2. OpenClaw installed 3. gateway healthy 4. `openclaw status` sensible 5. one channel connected 6. workspace configured 7. first workflow tested ## Best practice 6 — Make the workspace real from day one The assistant should not depend only on chat memory. Create the file structure early. --- # Part 5 — Core installation flow ## Step 1 — Provision the host A current Ubuntu LTS VPS is the most practical beginner default. ## Step 2 — Install OpenClaw Use the official installation path for your environment. ## Step 3 — Verify gateway health Useful commands: - `openclaw gateway status` - `openclaw gateway start` - `openclaw gateway restart` If the gateway is unhealthy, stop and fix that first. ## Step 4 — Check platform status Useful commands: - `openclaw status` - `openclaw status --deep` - `openclaw help` A good status check gives you an immediate picture of: - gateway health - channel state - current session state - whether something obvious is broken ## Step 5 — Prepare the workspace Your workspace should become the source of truth for: - identity - memory - project state - operating rules - future continuity ## Step 6 — Connect one channel For the beginner edition of this product, Telegram should be the first documented path unless there is a strong reason otherwise. ## Step 7 — Send a real test The install is not complete until the assistant can receive and reply through a real channel. --- # Part 6 — The files that make OpenClaw actually useful A working install needs more than binaries and a running service. ## `IDENTITY.md` Defines the assistant's name, nature, vibe, and core identity. ## `USER.md` Defines who the assistant is helping and what matters about that user. ## `SOUL.md` Defines operating style, judgment, tone, and boundaries. ## `MEMORY.md` Stores durable long-term continuity. ## `memory/YYYY-MM-DD.md` Stores daily operational memory. ## `AGENTS.md` Defines workspace operating rules. ## Project docs Each real project should have a place to live. Without these files, most installs feel impressive for 10 minutes and forgettable after that. --- # Part 7 — Common installation problems and real fixes ## Problem: “It installed, but nothing replies.” ### Most likely causes - gateway not actually running - channel not authenticated - config incomplete - testing the wrong chat/account ### Best fix order 1. `openclaw gateway status` 2. `openclaw status` 3. restart gateway if needed 4. verify channel onboarding carefully 5. test the simplest possible path --- ## Problem: “The service is up, but messages do not arrive.” ### Common causes - channel setup incomplete - wrong token or wrong target - provider-side setup not finished - routing mismatch ### Fixes - validate the channel one step at a time - use `openclaw status --deep` if needed - simplify to one target chat first - do not debug two channels at once --- ## Problem: “The assistant works, but it feels blank or forgetful.” ### Common causes - no durable memory files - no identity layer - everything is being carried in chat - no project structure ### Fixes - create the root files - use daily memory - keep project state in docs - stop relying on giant repeated prompts --- ## Problem: “The assistant is too risky.” ### Common causes - no explicit ask-first rules - no distinction between internal and external actions - permissions are implied instead of written ### Fixes Write down: - what it can do without asking - what it must ask before doing - what it must never do - how it should behave in group chats --- ## Problem: “The assistant is too passive.” ### Common causes - overly vague instructions - no ownership model - no proactive safe-work rule ### Fixes Define: - what internal work it should continue on its own - what should trigger escalation - how to treat blocked branches --- ## Problem: “The setup works, but it is expensive or messy.” ### Common causes - huge chat transcripts - weak file-based memory - noisy heartbeats - poor project structure ### Fixes - keep memory in files - keep heartbeats small - summarize phases into docs - use project folders instead of endless chat context --- ## Problem: “I do not know if my server is too exposed.” ### Common causes - rushing deployment - public exposure without a clear reason - weak understanding of admin vs app surfaces ### Fixes - keep access narrow - prefer safer remote-admin patterns - consider VPN/tunnel access when it reduces risk - do not expose things just because you can --- # Part 8 — Best practices for VPS, private server, and VPN setups ## VPS best practices - keep the first deployment simple - avoid unnecessary services on the same host - keep admin access predictable - document what is installed and why ## Private server best practices - make sure power/network uptime is acceptable - know how you will access it remotely - keep the server role clear - do not mix too many experiments into the same box ## VPN/tunnel best practices - use them to reduce unnecessary public exposure - keep the access pattern understandable - avoid creating a maze that is hard to support later ## My practical advice If the buyer is a beginner, the default route should usually be: - public VPS for the app - conservative exposure - optional safer admin path - simple first channel That is easier to deliver and easier to support. --- # Part 9 — Safety configuration from day one This is where many beginner installs go wrong. They install the service but never define behavior boundaries. ## Minimum safety model ### Safe internal actions These can usually be allowed proactively: - reading files - organizing docs - drafting plans - writing internal notes - reviewing project state ### Ask-first actions These should usually require approval: - sending emails - posting publicly - deleting data - spending money - changing production systems - sharing sensitive information ### Group chat behavior The assistant should: - contribute when useful - stay quiet when it has no real value to add - avoid leaking private context - avoid talking like it owns the human's voice --- # Part 10 — The first workflow after install Do not end the setup when the channel works. That is only infrastructure. Pick one first workflow such as: - daily project tracking - internal note capture - ops review assistant - bilingual drafting support - research summarization This is what converts setup into value. --- # Part 11 — Post-install validation checklist A deployment should pass all of these: - OpenClaw is installed - gateway is healthy - `openclaw status` shows sensible output - one primary channel is connected - the assistant replies correctly - root identity/memory files exist - ask-first boundaries are written - one first workflow is defined and tested If these are not true, keep working. Do not mark the install complete too early. --- # Part 12 — Can installation support be productized? Yes. But it should be productized honestly. ## What can be delivered well asynchronously - readiness review - deployment recommendation - install guidance - troubleshooting analysis - starter configuration pack - validation checklist - first workflow setup guidance ## What should not be overpromised - universal hands-off implementation in every environment - unlimited troubleshooting - guaranteed resolution without enough diagnostics - every channel/plugin under one flat beginner package This is why the strongest service version is: **Assisted Install** not **magic done-for-you install for every case** --- # Part 13 — Final advice for buyers If you are starting from zero, keep your first OpenClaw setup: - simple - documented - conservative - file-based - single-channel - validated step by step That is how you get to trust. And trust is what makes a real assistant usable. --- # Conclusion A good OpenClaw install is not just a technical event. It is the beginning of an operating system. If you install it cleanly, validate it properly, define memory and identity early, and keep the first workflow simple, you give yourself something much more valuable than a chatbot. You get a system that can start becoming an operator.