Build OpenClaw from source, or run the prebuilt image?
npm global, prebuilt container, or git clone + pnpm: three official install paths with different trust and effort profiles. Who each one is for, and what the Docker setup script does by default.
For almost everyone: don’t build from source. The npm package (npm install -g openclaw@latest) is the default install, and the prebuilt container images (ghcr.io/openclaw/openclaw, mirrored on Docker Hub) are the server-shaped equivalent: both are what the project publishes, tests, and expects you to run. Building from source is for people changing OpenClaw itself or carrying a patch that hasn’t merged. It’s a real, documented path (clone, then pnpm install && pnpm build), but it trades away easy updates for control you only need if you’re editing the code.
The three official paths, compared
npm global is the path the onboarding docs assume: quick, easy to update, runs directly on the host. Its trust model is the npm registry plus the package’s install scripts, which is why verifying you’re installing the real package matters more than any build-vs-image debate. Prebuilt image wraps a known-good runtime (Node included, running as a non-root user) in a container: best isolation-by-default, easiest rollback (tags are immutable versions), and the natural fit for a VPS. From source gives you exactly the code you checked out (auditable before building, patchable at will) at the cost of owning the toolchain (pnpm, a full build including the UI) and re-building for every update. Notice what’s not on the scoreboard: performance. All three run the same JavaScript; a source build is not a faster OpenClaw.
What building from source actually involves
The documented sequence, for the curious or committed:
git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install && pnpm build && pnpm ui:build
pnpm link --global # makes 'openclaw' on your PATH point at your buildFrom there it behaves like an npm install, except updates are now yours to perform: git pull, rebuild, and re-test, every time. The moment you carry a local patch you also inherit merge conflicts when upstream moves. OpenClaw moves fast, so that cost recurs monthly, not yearly. If your reason for source is “I want to read the code before trusting it,” you can do that without building at all: audit the repo, then run the published artifact of the same version.
A subtlety in the Docker path
Here’s the one that surprises people reading the repo’s Docker setup: the helper script builds locally by default. Running ./scripts/docker/setup.sh produces a local openclaw:local image from the checkout, which is effectively the source path wearing a container. To run the prebuilt, published image instead, point the script at it first:
export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"Or better, a pinned version tag rather than latest, so updates happen when you decide. (Which tag names exist and how they map to npm releases is its own small maze.) For a server, prebuilt, version-pinned images are the bias worth having: reproducible machines beat artisanal ones when something breaks at 2am and you need the same bits on a fresh box in minutes. The mechanics of volumes, env files, and compose live in the Docker guide.
Choose by the person you are this month
Trying OpenClaw on a laptop: npm. Running it seriously on a server: prebuilt pinned image (or npm on the host if containers aren’t your world: it’s a fine, supported server path too). Contributing, debugging something upstream, or carrying a patch: source, with eyes open about the update treadmill. And whichever you pick, the trust step comes first: install from the real sources, pin what you can, and let the project’s own publishing do the compiling.