Community Guide

Install OpenClaw

The practical install guide for OpenClaw, covering the recommended onboarding path, platform choices, first-run checks, and what to do after setup.

Mar 19, 2026

The fastest supported install path

If you want the shortest supported route today, the sequence is simple:

install the CLI
run openclaw onboard --install-daemon
verify the Gateway
open the Control UI
add channels and extra tooling only after the base install works

The important detail is that OpenClaw now treats the onboarding wizard as the main setup path, not as an optional extra. The official docs and README both center the install flow around openclaw onboard.

What a successful OpenClaw install actually means

A real install is not just “the command ran once.”

You want four things to be true:

the openclaw CLI is available
the Gateway can start and stay running
the workspace exists and is writable
you have at least one working way to talk to the assistant

That last point matters. The fastest first chat is usually the browser Control UI, not Telegram or WhatsApp. The official docs explicitly recommend using the dashboard for the first working interaction because it removes channel setup from the critical path.

Pick the right install route before you start

macOS

For most solo operators, macOS is still the cleanest first route. It is the easiest place to validate the local-first setup, the onboarding flow, and the operator loop before you complicate the environment.

If that is your path, go deeper here:

Install OpenClaw on macOS

Docker

Docker is useful when you want cleaner environment isolation or you already know you want a more server-shaped deployment. It is not automatically the best first install for everyone.

If that is your path, go here:

Deploy OpenClaw with Docker

Windows

OpenClaw on Windows is currently best treated as a WSL2 install, not as a native Windows-first runtime. The official platform docs are explicit about this. If your main machine is Windows, the safest expectation is “Linux inside Windows.”

VPS or remote host

A VPS makes sense when you care about uptime more than simplicity. It also introduces new decisions around auth, exposure, nodes, backups, and remote access. If you do not need always-on operation yet, local install is usually the better starting point.

Prerequisites

Before you install anything, make sure these assumptions are true:

Node 22 or newer is available
you are prepared to use Node as the main runtime
if you are on Windows, you are willing to use WSL2
you have at least one model/provider path in mind

The official platform docs also note that Bun is not the recommended Gateway runtime. That does not mean Bun is useless everywhere, but if your goal is a stable first install, do not start by inventing a non-default runtime story.

Install the CLI first

The official Getting Started guide currently shows these entrypoints:

macOS and Linux

curl -fsSL https://openclaw.ai/install.sh | bash

Windows PowerShell

iwr -useb https://openclaw.ai/install.ps1 | iex

If you are using Windows, the better mental model is still:

install WSL2
open Ubuntu inside WSL2
run the OpenClaw install there

If you are contributing from source rather than installing as a normal operator, that is a different workflow. For most SEO-oriented readers, this page should stay focused on the supported user install path.

Run the onboarding wizard

This is the actual center of the install process:

openclaw onboard --install-daemon

The wizard is not just a convenience wrapper. It configures the pieces that people most often miss when trying to “manual-install” too early:

model and auth setup
workspace location
Gateway port and auth mode
optional channels
daemon or service install
health checks
optional skills

If you are new, use the default flow first. The wizard has QuickStart and Advanced modes, but QuickStart exists for a reason: it removes many early wrong turns.

What the wizard is doing for you

When openclaw onboard --install-daemon works correctly, it is solving more than one problem at once.

It creates a usable workspace

OpenClaw needs a real workspace, not just a binary on disk. The docs describe a workspace with bootstrap files such as AGENTS.md, SOUL.md, USER.md, and optional memory files. That means install and operator state are connected from the beginning.

It installs the Gateway service

The service target depends on the OS:

macOS uses a LaunchAgent
Linux and WSL2 use a systemd user service

That is why --install-daemon matters. A first install is much better when the Gateway can restart in a predictable way instead of living inside one terminal session you might close by accident.

It keeps the setup sequence sane

The wizard is opinionated in a useful way:

local Gateway first
one workspace
auth configured early
one working chat path before more complexity

This is not restrictive. It is operationally correct.

Verify the Gateway before anything else

Do not jump from “install command finished” straight into channels, group routing, or public access.

Run the checks first:

openclaw gateway status
openclaw status
openclaw doctor

At this stage, what you want is boring:

the Gateway is reachable
the config looks sane
runtime and auth are not obviously broken
diagnostics do not point to a missing baseline requirement

If these checks fail, you still have an install problem. Do not rename it into a Telegram problem or a model problem yet.

Open the Control UI for the first real test

The official docs explicitly recommend the dashboard as the fastest first chat:

openclaw dashboard

You can also open the local Gateway URL directly if needed. The point is to prove the base loop:

the Gateway is up
the UI can connect
the assistant can respond

This is much cleaner than trying to debug channel configuration at the same time.

The right order after the first boot

Once the dashboard works, the next steps should stay narrow.

1. Confirm one model path only

Do not configure every provider you own on day one. Pick one path that you trust and make sure it works.

If you want guidance after install:

Recommended OpenClaw Model Stack

2. Add one channel only

Telegram is often the best first channel because it is easier to reason about than a larger, more entangled communication setup.

Connect OpenClaw to Telegram

3. Review security before public exposure

The official docs are very clear that inbound messaging surfaces are untrusted input. That means a successful install is not the same thing as a safe install.

OpenClaw Security & Cost Control

Common install mistakes

Starting with too many moving parts

Installation, auth, channels, models, and remote nodes are different systems. If you change all of them at once, you lose the ability to debug cleanly.

Treating Docker as the default “serious” choice

Docker is useful, but it is not automatically simpler. If your real goal is to understand whether OpenClaw works for you at all, local onboarding is often the better first test.

Ignoring WSL2 on Windows

The official Windows docs do not present native Windows as the preferred route. If you fight that recommendation early, you are creating extra work for yourself.

Skipping service install and health checks

Running one foreground process is not the same as having a stable install. If the Gateway cannot be checked, restarted, and reasoned about, the install is not done yet.

Confusing local and remote assumptions

People often mix these states:

the Gateway runs locally
the Gateway runs remotely
the browser lives on another machine
nodes live elsewhere

The farther you move from local-first defaults, the more careful you need to be about what lives where.

Which route should you choose?

If you are unsure, use this rule:

choose macOS if you want the cleanest local-first path
choose Windows via WSL2 if your main machine is Windows
choose Docker if you already know you want containerized deployment
choose VPS only when always-on uptime is worth the extra operational weight

That is a better decision framework than “Which route looks more advanced?”