OpenClaw
OpenClaw is an AI-powered, open-source agent that connects AI models with messaging channels, browser sessions, files, tools, and scheduled jobs. You can operate it on your own computer or deploy it on a remote host when the assistant needs to remain available while your device is offline.
You choose the model provider, credentials, tools, permissions, and hosting environment. That control is useful for technical users, but it also makes installation, uptime, security, updates, and recovery part of the operator's responsibility.
Quick answer: OpenClaw can run locally without Docker or a VPS. Docker is an optional deployment method. A remote host becomes useful when you need persistent access or scheduled work without keeping your personal computer online.
Technical details on this page are based on the official Getting Started, Gateway Architecture, ClawHub, and Security documentation.
Who this is forNon-technical professionals, solopreneurs, and lean teams who want recurring browser, file, research, and monitoring workflows without self-hosting OpenClaw, configuring a server, or keeping a personal computer awake.
OpenClaw: The Open-Source AI Agent You Self-Host
OpenClaw is a self-operated personal AI assistant platform. A standard chatbot mainly produces responses inside a conversation. This agent can also work through approved tools, interact with websites, handle files, receive messages from connected channels, and execute scheduled work.
The open-source project provides the runtime and control layer. The operator provides the host computer, model access, credentials, permissions, and maintenance around it.
| OpenClaw is | OpenClaw is not |
|---|---|
| An open-source AI agent runtime | A model provider by itself |
| A way to connect AI models with tools and messaging channels | A maintenance-free cloud subscription |
| Configurable for local or remote operation | Automatically available when its host is offline |
| Designed around an operator-controlled environment | A shared hostile-user security boundary by default |
Depending on its configuration, the assistant can support:
- Research across websites and documents
- Browser-based information collection
- File creation, organization, and transformation
- Scheduled checks, reminders, and recurring reports
- Tasks received through supported messaging channels
- Reusable workflows built with skills and plugins
- Local or remote tools allowed by the operator
This model usually fits users who value source access, infrastructure control, and custom configuration. It requires more involvement than a hosted assistant because the person running it remains responsible for keeping the environment available and appropriately secured.
How OpenClaw Works: Skills, ClawHub & Messaging Channels
The official architecture describes a single long-lived Gateway that owns the connected messaging surfaces. Control-plane clients, including the CLI and web interface, connect to the Gateway over WebSocket.
For readers, the request path can be summarized with the following simplified flow. This is an explanatory model for this page, not an official five-stage architecture defined by the project.
| Simplified step | What happens |
|---|---|
| Message | A request arrives through the web interface or a connected messaging channel |
| Gateway | The Gateway receives the client request within the configured environment |
| Agent run | The selected model processes the request and determines how to respond |
| Approved capabilities | The agent may use available skills, plugins, browser access, files, or other permitted tools |
| Result | The response or completed output is returned through the relevant client or channel |
Gateway
The Gateway is a real OpenClaw architecture component, not a label created for this page. The official architecture documentation describes one long-lived Gateway per host and identifies it as the component that owns messaging surfaces such as Telegram, Slack, Discord, Signal, WhatsApp, iMessage, and WebChat.
The Gateway needs to remain available for connected clients and channels. If its host or process stops, the assistant may no longer receive requests or continue scheduled work until the service returns.
Control UI
The Control UI is the browser-based interface used to chat with and manage the running assistant. The official getting-started flow instructs users to open the dashboard after confirming that the Gateway is running.
Skills
Skills are versioned instruction bundles that can include a SKILL.md file and supporting resources. They describe how the agent should approach a task and may include references, templates, scripts, or other files.
A skill may still depend on external packages, environment variables, API credentials, browser access, or system tools. Review those requirements before installation.
ClawHub
ClawHub is officially described as the public registry for OpenClaw skills and plugins. OpenClaw commands can search, install, and update packages from the registry.
ClawHub also exposes version information, files, changelogs, compatibility metadata, install activity, and security scan summaries. Because community packages may interact with credentials, files, browsers, or external services, scan information should supplement rather than replace source review and permission controls.
Messaging Channels
The official documentation lists multiple messaging surfaces that can connect through the Gateway. Each channel has its own setup and authorization requirements, such as a bot token, account connection, sender policy, or pairing process.
A personal assistant and a shared workplace bot should not automatically use the same credentials, browser profile, workspace, or tool permissions. Channel access should match the people allowed to direct the agent.
OpenClaw Setup: Docker, Node & VPS Requirements
OpenClaw requires a supported runtime, model access, onboarding, and a running Gateway. Exact runtime versions and installation commands can change between releases, so this page does not duplicate version-specific setup instructions.
Use the OpenClaw Getting Started documentation as the source of truth for current system requirements and installation commands. This avoids running instructions copied from an older article after the project has changed.
Docker is optional rather than a requirement for every installation. A VPS is also optional unless you want the runtime available independently of your personal computer.
| Deployment | Requirements | Operator responsibility | Typical fit |
|---|---|---|---|
| Local installation | Supported operating system, current runtime requirements from the official documentation, model credentials | Device uptime, local permissions, updates, browser and file access | Testing and personal workflows on an available computer |
| Docker | Docker Engine or Desktop, Docker Compose, persistent storage | Images, containers, mounts, networking, secrets, updates | A containerized Gateway or repeatable deployment |
| VPS or remote host | Server or VM, secure remote access, runtime, persistent storage | Authentication, firewall rules, backups, logs, updates, uptime | Persistent access without relying on a personal device |
Local Installation
Local installation is the shortest path to testing the assistant. Follow the current official setup flow, complete onboarding, configure model access, and confirm that the Gateway is running.
The main limitation is availability. If the computer sleeps, restarts, disconnects, or stops the Gateway process, remote conversations and scheduled tasks may be interrupted.
Docker Deployment
The official Docker documentation describes Docker as an optional setup for users who want a containerized Gateway. Docker can provide a clearer runtime boundary and make deployments easier to reproduce, but the operator must still manage images, volumes, networking, permissions, secrets, and updates.
A container is not automatically secure. Sensitive host mounts, exposed ports, or broad capabilities can weaken the intended boundary.
VPS Deployment
A remote host keeps the agent available independently of a personal computer. It also introduces server maintenance, restricted network access, Gateway authentication, secret management, storage, backups, and monitoring.
Open-source software may have no license fee, but an always-on deployment can still involve model usage, infrastructure, and operator time.
Is OpenClaw Safe? The Local-Access "Security Nightmare"
The phrase "security nightmare" should not be treated as a universal verdict. The actual risk depends on who can send instructions, which tools the agent can use, what those tools can reach, and how the host is configured.
The official security guidance assumes one trusted operator boundary per Gateway in a single-user personal-assistant model. It explicitly states that one shared Gateway is not intended to provide hostile multi-tenant isolation for mutually untrusted users.
| Risk area | Why it matters | Safer approach |
|---|---|---|
| Logged-in browser | The model may reach accounts and data available in that browser profile | Use a dedicated agent profile without personal password-manager access |
| File and command tools | Tool actions may affect local data or processes | Restrict tools, use sandboxing, and limit workspace access |
| Prompt injection | Websites or documents may contain instructions that try to redirect the agent | Keep permissions narrow and require confirmation for sensitive actions |
| Shared channels | Approved senders may steer the same set of tools and credentials | Separate personal and shared agents, workspaces, and credentials |
| Community packages | Skills and plugins may introduce dependencies or additional access | Review source, permissions, compatibility, and required credentials |
| Remote exposure | An externally reachable Gateway expands the access surface | Require authentication and avoid unnecessary public exposure |
Browser Access
The official security documentation warns that enabling browser control allows the model to drive a real browser. If the browser profile already contains authenticated sessions, the model may be able to access those accounts and their data.
Use a dedicated browser profile instead of an everyday browsing profile. Avoid connecting unnecessary personal accounts, browser synchronization, or password-manager access.
File and Command Access
File, shell, and process tools expand what the assistant can accomplish. They also increase the possible impact of an incorrect or manipulated instruction.
Use sandboxing, workspace restrictions, tool allowlists, read-only access, and confirmation points where appropriate. Do not grant every tool simply because it is available.
Prompt and Content Injection
Web pages, documents, emails, and messages can contain instructions intended to influence an agent. Prompt safeguards can reduce risk, but permission boundaries remain more important.
An agent that only reads public pages has a different risk profile from one that can modify files, run commands, and use authenticated accounts.
Shared Channels
Every approved sender may be able to steer the tools available to a shared agent. Keep personal-data assistants private.
For team use, consider separate credentials, workspaces, browser profiles, agents, or Gateways based on the organization's trust boundaries.
Practical Security Checklist
- Keep the runtime and installed packages updated.
- Use the built-in security audit described in the current official security documentation after important configuration changes.
- Restrict Gateway access and approved senders.
- Grant only the browser, file, network, and command tools required.
- Use a dedicated browser profile, workspace, and credentials.
- Review community skills and plugins before installation.
- Back up important configuration and workspace data.
- Rotate credentials after suspected exposure.
No configuration removes all agent risk. The practical goal is to minimize permissions and isolate the environment according to the sensitivity of the work.
Managed OpenClaw Hosting vs Running It Yourself
Managed hosting changes who operates the computer underneath the agent. It does not remove the need to protect connected accounts or review sensitive workflows.
Disclosure: We make MoClaw. Other products are described using publicly available information. Features and plans change, so verify details on each product's official site.
| Area | Self-hosted OpenClaw | Managed cloud claw |
|---|---|---|
| Service model | Open-source, self-operated runtime | Provider-managed service |
| Host | Personal computer, VM, container host, or server | Managed cloud environment |
| Setup responsibility | Handled by the operator | Handled mainly by the service provider |
| Availability | Depends on the operator's host and processes | Designed for persistent cloud operation |
| Updates and recovery | Handled by the operator | Handled by the service provider |
| Model access | Operator configures supported providers | Built-in access, BYOK, or both, depending on the service |
| Skills and tools | Installed and maintained by the operator | Built-in capabilities with supported extensions |
| Primary use case | Runtime ownership and custom infrastructure | Delegating work without operating the host |
Self-hosting may fit when you need source access, custom runtime changes, local execution, or direct infrastructure ownership.
Managed hosting may fit when you want browser work, research, file tasks, monitoring, and scheduled workflows without maintaining a Gateway or server.
OpenClaw Alternative: A Cloud Claw With No Install
MoClaw is an AI-powered personal assistant that runs on its own managed cloud computer. It is designed for users who want an always-on agent experience without installing a local runtime, configuring containers, or maintaining a VPS.
Users assign tasks through chat while the cloud environment handles supported browser actions, files, skills, and scheduled jobs. The assistant can continue running when the user's personal computer is offline and return results through supported channels.
MoClaw may be useful for:
- Recurring research and competitor monitoring
- Collecting information from websites into structured outputs
- Working with files, PDFs, images, and data
- Scheduling tasks without leaving a personal computer awake
- Running browser tasks in a separate cloud environment
- Starting with built-in capabilities before adding custom skills
The managed environment reduces infrastructure work, but it is not the same choice as owning the complete open-source runtime.
Technical users who need low-level configuration, custom infrastructure, or direct runtime control may still prefer self-hosting. Users who mainly want to assign work and receive results may prefer a managed cloud computer.
You can review MoClaw use cases, explore its supported integrations, or check the pricing page before deciding whether managed hosting fits your workflow.
OpenClaw vs Manus vs Lindy
OpenClaw, Manus, Lindy, and MoClaw all support AI task delegation, but their official product positioning and operating models differ.
| Product | Operating model | Public positioning | Main workflow described by the product |
|---|---|---|---|
| OpenClaw | User-operated open-source runtime | Personal AI assistant with connected tools and messaging surfaces | Custom agent workflows under operator-controlled infrastructure |
| Manus | Product-managed AI service | An action engine that executes tasks and automates workflows | Broad task execution and workflow automation |
| Lindy | Product-managed AI assistant | An AI executive assistant for administrative work | Inbox organization, calendar scheduling, meeting preparation, and follow-ups |
| MoClaw | Managed AI assistant on a cloud computer | Always-on personal AI assistant without self-hosting | Browser, research, file, and scheduled work in a managed environment |
These products are not identical replacements. Choose according to the tasks you need completed and the amount of infrastructure responsibility you want to keep.
Questions
Is OpenClaw Free to Use?
The source code is open source, but operating it may involve model-provider charges, hosting, storage, backups, and maintenance. Review the requirements of your chosen providers and deployment before estimating the total cost.
Does OpenClaw Support BYOK?
Yes. The runtime can use credentials from supported model providers and external services. You remain responsible for securing those credentials and paying any charges from the providers you connect.
Do I Need Docker or a VPS?
No. Docker is optional, and the agent can run locally. A remote host becomes useful when you want persistent access and scheduled work without keeping your personal computer online.
Should I Trust Every ClawHub Skill or Plugin?
No package should be trusted automatically. Review its source, permissions, dependencies, compatibility information, scan results, and required credentials before installation.
Can OpenClaw Skills Work With MoClaw?
MoClaw supports OpenClaw-compatible skills, but compatibility may depend on packages, credentials, permissions, and system assumptions. Customized skills may require adjustment before they work in a managed environment.
Want an always-on AI assistant without operating another computer or server? Compare the managed workflow with self-hosting and choose the level of control that fits your work.
Want a claw without the setup?
MoClaw is a hosted cloud claw — OpenClaw-style automation, always on, with no Docker, VPS, or server to babysit. Bring your own key.