FREE SELF-PACED COURSE · VERIFIED 2026-07-24
OpenClaw Setup & Operator Foundations
Install OpenClaw, understand the Gateway, configure a model and channel safely, then build and maintain your first useful agent.
WHO THIS IS FOR
New operators who want a working local OpenClaw installation without skipping the security boundaries.
Prerequisites
- A supported macOS, Linux or Windows system (WSL2 recommended on Windows)
- Administrator access for installing the supported Node.js runtime
- Credentials for at least one model provider
- A separate test channel/account where practical
BY THE END
You will be able to
- Explain the Gateway, agent, workspace, channel and model boundaries
- Install with a current supported runtime and verify the service
- Configure one model and one channel without exposing the Gateway
- Create a constrained first workflow and test its failure path
- Update, diagnose and recover the installation safely
1. Understand the operating boundary
Outcome: Know which OpenClaw component owns messages, tools, credentials and execution.
- The Gateway is the long-running control plane. It owns channel connections, sessions and client authentication.
- The model proposes work; configured tools determine what can actually happen on the machine.
- Workspace files shape behaviour and memory. They are instructions and data, not a security boundary.
- Treat every channel message and fetched document as untrusted input whenever tools can read, write or execute.
PRACTICAL TASK
Self-check: Does a careful SOUL.md replace tool restrictions or Gateway authentication?
No. Prompt instructions guide behaviour; access controls, sandboxing, tool policy and Gateway authentication enforce boundaries.
2. Prepare the machine
Outcome: Confirm the runtime, installation path and recovery plan before changing the system.
- Check the current runtime requirement in the verified installation guide before installing; supported patch versions can change.
- Decide whether this is a personal workstation, dedicated host, container or remote Gateway. That choice changes exposure and persistence risk.
- Back up any existing OpenClaw configuration and workspace before upgrading or reinstalling.
- Prefer a dedicated non-root user and a separate test account or channel for first setup.
PRACTICAL TASK
Self-check: Why is “Node 22+” not a sufficient compatibility check?
OpenClaw can require minimum patch versions within supported majors. Verify the exact current range rather than assuming every Node 22 or 24 build works.
3. Install and verify the CLI
Outcome: Complete a current installation and prove the CLI is the expected binary.
- Use the current official installer or the documented package-manager path. Inspect scripts first when your environment requires it.
- After installation, start a fresh shell and verify both the resolved binary path and version.
- Do not copy historical installer domains from old tutorials. Use links verified against current official documentation.
- If a command is missing, fix PATH or runtime ownership before proceeding; reinstalling repeatedly usually hides the cause.
PRACTICAL TASK
Self-check: What must you verify besides seeing an OpenClaw version number?
Verify which binary is being executed and which Node runtime owns it, so an old global install or mismatched shell cannot masquerade as the new setup.
4. Onboard one model safely
Outcome: Create the initial configuration without leaking provider credentials or overexposing the Gateway.
- Run the current onboarding flow and choose a single model provider first. Complexity can be added after the baseline works.
- Keep the Gateway bound to loopback unless remote access is deliberately designed and authenticated.
- Never paste API keys into course notes, screenshots, tickets or workspace files.
- Use the generated Gateway authentication rather than treating local network access as trusted by default.
PRACTICAL TASK
Self-check: When is binding the Gateway to all interfaces an acceptable beginner default?
Never. Remote exposure should be an explicit design with authentication, transport protection and network controls—not a convenience default.
5. Connect one constrained channel
Outcome: Receive and send a test message without granting the whole world access to the agent.
- Start with one channel and one authorised sender. Pairing and allowlists are different from linking a channel account.
- A successful QR scan or OAuth flow proves the session connected; it does not prove credentials will survive a restart.
- Keep group access disabled or mention-gated until direct-message behaviour is understood.
- Restart the Gateway and confirm the channel reconnects before calling the setup complete.
PRACTICAL TASK
Self-check: Does linking WhatsApp automatically authorise every sender?
No. Channel linking establishes the transport; sender pairing, allowlists and group policies decide who may invoke the agent.
6. Shape the workspace
Outcome: Set useful instructions and memory without confusing them for permissions.
- Keep identity, user context, tool notes and operational instructions concise enough to review.
- Put durable facts in the appropriate memory surface; do not dump raw secrets, transcripts or credentials there.
- Review every imported skill before use. A skill is executable guidance and may expand what the agent attempts.
- Version the workspace privately after excluding credentials and volatile state.
PRACTICAL TASK
Self-check: What is the security implication of installing a third-party skill?
It adds instructions and possibly scripts that influence tool use. Treat it like code or operational automation: inspect the source, permissions and maintenance history first.
7. Build one bounded workflow
Outcome: Turn the installation into a useful agent while limiting blast radius.
- Choose a repeatable, reversible task with a clear success condition.
- Start read-only. Add write or execution permissions only after the read path works.
- Specify when the agent must ask before acting and how it verifies external side effects.
- Test the happy path, one malformed input and one unavailable dependency.
PRACTICAL TASK
Self-check: What makes a good first agent workflow?
It is useful, repeatable, easy to verify and low-consequence when it fails. Read-only collection or reporting usually beats autonomous writes on day one.
8. Diagnose, update and recover
Outcome: Maintain the system without turning every fault into a reinstall.
- Use status, health and doctor output to identify the failing boundary before changing configuration.
- Read release notes before updates and back up configuration, workspace and channel state.
- After an update, verify Gateway health, one model request, channel reconnect and the critical workflow.
- Keep a rollback path. “Latest” is not a recovery strategy.
PRACTICAL TASK
Self-check: What should you do before applying a speculative configuration fix?
Capture the error and current status, identify which boundary failed, back up the current state and change one thing at a time.
COURSE COMPLETE
Use the work, not the badge.
You should now have practical notes, tests and a safer operating baseline. Revisit the course after major OpenClaw releases: commands and configuration can change.