OpenClaw with Ansible

For people who want a server rather than a laptop, the docs offer openclaw-ansible, an automated installer with what they call a security-first architecture, and the repository is the source of truth with the docs page as overview. Here is what it needs, what it installs, the post-install steps that still need a human, the four-layer security model and the one command that verifies it, the manual path, and how updates work afterwards.

What you need and what you get

• Debian 11 or newer or Ubuntu 20.04 or newer, root or sudo, an internet connection, and Ansible 2.14 or newer, which the quick-start script installs for you.
• Firewall-first security, UFW plus Docker isolation, with only SSH and Tailscale reachable; Tailscale for remote access without exposing services; Docker for isolated sandbox containers with localhost-only bindings; a hardened systemd service that starts on boot; and a one-command setup.
• What gets installed, in order: Tailscale, UFW, Docker CE with Compose, Node.js and pnpm at a Node version OpenClaw accepts, with 26 recommended, OpenClaw itself installed host-based rather than containerised, and the systemd service.
• The Gateway runs directly on the host; Docker is there because it is the default agent sandbox backend, and sandboxing itself is optional.

Only port 22 (SSH) should be open. Gateway and Docker stay locked down.

After the playbook

Switch to the openclaw user, run the onboarding wizard the post-install script guides you through, log in to your channels with the channel login command, the docs naming WhatsApp, Telegram, Discord and Signal, verify with the service status and the live journal, and join your Tailscale mesh. The Gateway restart command records managed restart intent; for a system-scope service you follow the exact systemctl command it prints. Channel login fails when you are not the openclaw user, which is the first thing the troubleshooting list checks.

The four layers

• The firewall exposes only SSH and the Tailscale UDP port; the VPN makes the Gateway reachable only through the mesh, which is why the troubleshooting entry for a blocked connection says to join Tailscale first, SSH being always allowed.
• Docker isolation uses the user iptables chain so containers cannot expose ports externally, and systemd hardening runs the service with no new privileges, a private temp directory and an unprivileged user.
• Verify from outside with a full port scan of the server: only port 22 should be open. Docker is for agent sandboxes, isolated tool execution, not for running the Gateway.

OpenClaw and Tailscale covers the VPN layer on its own, and OpenClaw sandboxing explained the Docker layer the playbook prepares.

Manual path and updates

Without the quick-start script: install Ansible and git, clone the repository, install the collections, then run the wrapper, or run the playbook with the become password and the setup script afterwards. The installer sets OpenClaw up for manual updates through the standard flow, and re-running the playbook after configuration changes is idempotent and safe to repeat. When the service will not start, read the last hundred journal lines, check the permissions of the install directory, and try a manual Gateway run as the openclaw user; when the sandbox misbehaves, check that Docker runs and that the sandbox image exists, building it from a source checkout if it is missing. OpenClaw on a VPS is the same server without the automation, and OpenClaw on Docker the containerised Gateway the page contrasts with.

On Diali

Diali runs the hosted version of that posture: an isolated instance per assistant, reachable only through our edge, updates applied by us, and nothing to install. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary.

• One command, a firewall, a VPN, a hardened service.
• The Gateway is on the host; Docker is for sandboxes.
• Only port 22 should answer a scan.