Ansible

Automated fleet provisioning with security-first architecture: UFW firewall, Tailscale VPN, Docker sandbox, systemd hardening.

The Ansible deployment is the security-first approach to running OpenClaw on production servers. Unlike other methods that leave security as an exercise for the reader, openclaw-ansible implements a 4-layer defense model out of the box: UFW firewall (only SSH and Tailscale ports exposed), Tailscale VPN (gateway accessible only through your mesh network), Docker isolation (agent sandboxes in throwaway containers), and systemd hardening (NoNewPrivileges, PrivateTmp, unprivileged user). The installation is a single curl command that bootstraps Ansible on the target server, then runs the playbook. It installs Tailscale for secure remote access, UFW with restrictive rules, Docker CE for agent sandboxing, Node.js 24 (or 22.16+ LTS), pnpm, and OpenClaw itself. The gateway runs directly on the host (not containerized) — Docker is used only for agent sandbox isolation. A dedicated `openclaw` system user is created with minimal privileges and systemd service hardening. After installation, you switch to the openclaw user, run the onboarding wizard to configure your model provider and messaging channels, and connect to Tailscale to join your VPN mesh. The nmap verification step should show only port 22 (SSH) open to the public internet — all other services including the gateway are locked behind Tailscale. This is the recommended method for anyone deploying OpenClaw on a VPS that's exposed to the internet. The community has repeatedly flagged self-hosted OpenClaw deployments as security risks when basic hardening isn't done — Docker port exposure bypassing firewalls, gateway tokens exposed without HTTPS, unrestricted agent tool access. The Ansible playbook addresses all of these by default, making it the safest production deployment path available. For fleet provisioning, the playbook can target multiple servers. The architecture is designed so you can deploy identical, hardened OpenClaw instances across a fleet of VPS instances with a single command.

Tags: ansible, automated, hardened, firewall, tailscale

Use Cases

  • Production VPS deployment with enterprise-grade security hardening from day one
  • Deploying OpenClaw on a freshly provisioned cloud server (Hetzner, DigitalOcean, Linode) with all security configured automatically
  • Fleet provisioning — identical, hardened OpenClaw instances across multiple servers
  • Organizations that require documented security architecture for compliance or audit purposes
  • Self-hosters who want Tailscale VPN integration for secure remote access without exposing ports

Tips

  • Run nmap -p- YOUR_SERVER_IP after install to verify only SSH is externally accessible — this confirms the 4-layer security is working
  • Set up Tailscale before running the Ansible installer so you can immediately access the gateway after deploy
  • Use the openclaw user (sudo -i -u openclaw) for all OpenClaw operations — never run the gateway as root
  • Check systemctl status openclaw and journalctl -u openclaw -f for gateway health and logs
  • For fleet deployments, customize the Ansible inventory to target multiple servers at once
  • The third-party openclaw-hardened-ansible repo extends the official playbook with additional hardening measures
  • Keep your VPS OS updated separately — the Ansible playbook handles OpenClaw setup but not ongoing OS patching

Known Issues & Gotchas

  • Only supports Debian 11+ and Ubuntu 20.04+ — other Linux distros require manual adaptation of the playbook
  • Requires root/sudo on the target server — the playbook creates system users, installs packages, and configures firewall rules
  • Tailscale requires a Tailscale account and auth key — you'll need to set this up before or during install
  • The gateway runs on the host, not in Docker — Docker is only for agent sandboxes. Don't confuse this with a full Docker deployment
  • After install, you must connect to Tailscale to access the gateway remotely — it's not accessible via the public IP
  • The DOCKER-USER iptables chain is configured to block external access to Docker ports — this is intentional security hardening
  • Some VPS providers' default firewall rules may conflict with UFW — check your provider's dashboard

Alternatives

  • Docker
  • Installer Script
  • Hetzner/DigitalOcean VPS guides
  • openclaw-hardened-ansible (community)

Community Feedback

For option A (self-host), the minimum viable secure setup is: UFW firewall with only 22 and 443 open, nginx reverse proxy with Let's Encrypt SSL. The Ansible playbook does most of this for you.

— Reddit r/selfhosted

Top 5 OpenClaw skills for safety & security: Openclaw Ansible deploys a fully sandboxed agent infrastructure.

— LinkedIn

Self-hosting OpenClaw is a security minefield. SSL, reverse proxy, auth, port management. The Ansible playbook handles the hard parts but you still need to understand what it's doing.

— Reddit r/selfhosted

A practical guide to securing your AI assistant — the Ansible approach is defense-in-depth from the start, not bolted on after.

— Medium

Frequently Asked Questions

Why does the gateway run on the host instead of in Docker?

Running the gateway directly on the host avoids the Docker daemon attack surface. Docker is used only for agent sandboxing — isolating tool execution in throwaway containers. This separation gives you the security benefits of containerized execution without the risks of running a root daemon for the gateway itself.

Do I need to know Ansible to use this?

No. The install.sh script bootstraps Ansible automatically and runs the playbook for you. It's a one-command install. Understanding Ansible helps if you want to customize the deployment, but it's not required for the default setup.

How do I access the Control UI after Ansible deployment?

The gateway is only accessible via Tailscale. Connect to your Tailscale network, then access http://[tailscale-ip]:18789/ in your browser. The public IP won't work — that's the security model working as intended.

What does the 4-layer security model protect against?

Layer 1 (UFW) blocks all ports except SSH and Tailscale. Layer 2 (Tailscale) ensures the gateway is only accessible via VPN. Layer 3 (Docker DOCKER-USER chain) prevents containers from exposing ports externally. Layer 4 (systemd hardening) restricts the gateway process with NoNewPrivileges, PrivateTmp, and an unprivileged user.

Can I use this without Tailscale?

The playbook installs Tailscale by default, but you can modify it to use a different VPN or skip VPN entirely. However, without a VPN layer, you'd need to expose the gateway port publicly and add your own authentication — which defeats the security-first purpose.

How do I update OpenClaw after Ansible deployment?

Switch to the openclaw user (sudo -i -u openclaw), run npm install -g openclaw@latest, then sudo systemctl restart openclaw. The Ansible playbook is for initial provisioning — updates are done through npm.

Does this work on ARM servers?

The playbook is tested on x86_64 Debian/Ubuntu. ARM support (e.g., Oracle Cloud A1) may work but isn't officially tested. For ARM deployments, the manual install or Raspberry Pi guide is more reliable.