OpenClaw Secure Setup: The Professional Dev's VPS Playbook

OpenClaw secure setup is mostly a question of order: deploy a clean VPS, create a non-root user, close the firewall, put access behind Tailscale with the gateway bound to localhost, and only then connect models, email, GitHub, and real work. This is the numbered do-this-then-this playbook professional developers follow, distilled from how devs like Tech with Tim run OpenClaw in production and from published hardening writeups, so nothing sensitive touches the agent before the layer beneath it is locked down.

Why Setup Order Matters

A secure OpenClaw install is built network-first: the box is locked down before the agent runs, and the agent runs before it gets access to anything real. Most reported OpenClaw incidents trace back to inverted order, such as a gateway exposed on a public port while the owner was still wiring up channels, or a personal Gmail connected on day one, before any prompt-injection filter existed.

We already cover the individual controls in depth elsewhere on Remote OpenClaw, including the 3-tier hardening model and a 60-second exposure check. This post answers a different question: in what sequence do you apply them, so that at no point does the agent have more access than the layer beneath it can contain?

The 9-Step Playbook at a Glance

The full OpenClaw secure setup sequence is 9 steps, numbered 0 to 8, and each step exists to protect the one after it. The table below is the whole playbook; the rest of the post explains each row.

Step 0: Start From a Clean VPS

OpenClaw should run on a dedicated server that contains nothing you would mind losing, not on your laptop next to your browser sessions, SSH keys, and password manager. A clean VPS gives the agent its own filesystem, its own network identity, and a hard boundary you can wipe and rebuild in minutes.

The fastest route is the one-click OpenClaw template on a Hostinger VPS, which provisions the official Docker image with a firewall, DDoS protection, and weekly backups included. As of July 2026 the KVM 2 plan (2 vCPU, 8 GB RAM) is $8.79/mo at up to 70% off, which is the spec we recommend in our Hostinger plan comparison. If you prefer to build from a raw box instead, grab a plain Hostinger VPS and follow our manual deployment guide.

Step 1: Create a Non-Root User and Lock Down SSH

OpenClaw must not run as root, and neither should you once the box exists. A compromised agent process running as root owns the entire server; the same process under an unprivileged user can be contained, audited, and killed.

Before installing anything else, create the user, copy your SSH key, and turn off password login:

adduser claw
usermod -aG docker claw
rsync --archive --chown=claw:claw ~/.ssh /home/claw
# in /etc/ssh/sshd_config:
#   PasswordAuthentication no
#   PermitRootLogin no
systemctl restart ssh

Every later step assumes commands run as this user. Do not give the agent sudo, a rule the practical secure-setup guide by Sre Chakra Yeddula calls non-negotiable even for single-user tier-1 deployments.

Step 2: Close the Firewall Before the Agent Runs

The firewall goes up before OpenClaw starts, with a default-deny policy on incoming traffic and an allowance only for SSH. On Ubuntu, UFW makes this three commands:

ufw default deny incoming
ufw allow OpenSSH
ufw enable

Notice what is missing: no rule for port 18789 or whatever port your gateway uses. That is deliberate. The gateway will never be reachable from the public internet, because step 3 gives you a private path to it instead.

Step 3: Tailscale and a Localhost-Only Gateway

The OpenClaw gateway should listen on 127.0.0.1 only, and you should reach it through a Tailscale VPN rather than an open port. Tailscale builds an encrypted WireGuard mesh between your devices, so the admin dashboard is available from your laptop and phone while remaining invisible to the rest of the internet.

In Docker terms, the load-bearing line is the port binding:

# docker-compose.yml: bind to loopback, never 0.0.0.0
ports:
  - "127.0.0.1:18789:18789"

Two extra notes from production use. First, install Tailscale on the VPS and your own devices, then verify the gateway is unreachable from a network outside the tailnet before moving on. Second, OpenClaw rewrites its own openclaw.json on startup and during doctor or wizard runs, and it can silently drop custom settings such as allowlists; keep a known-good golden copy of the config and a small cron that restores it on drift, a trick documented in the Medium guide above. The full access pattern, including MagicDNS and serving HTTPS over the tailnet, is in our OpenClaw + Tailscale guide.

Step 4: Set Up the Dual-Model Cost Stack

An always-on agent priced purely on metered API tokens is a financial risk before it is a security one: heavy 24/7 use of a frontier model like Claude Opus through the API can climb into the thousands of dollars per month, which is why professional setups run a dual-model stack instead. The pattern is simple: a flat-rate coding subscription you already pay for becomes the day-to-day brain, and the strong metered model is reserved for planning passes where its judgment actually earns the tokens.

Concretely: authenticate your subscription plan as the default model, configure the strong API model as a secondary the agent escalates to for plan-mode or architecture questions, and set hard spend limits at the provider so a runaway loop hits a ceiling instead of your card. Our API costs and budgeting guide covers the numbers, and this cost-reduction guide covers what to do when the bill still creeps.

Step 5: A Separate Email Account With Forwarding Filters

The agent gets its own email address, and your real inbox forwards only allowlisted senders to it; the agent never reads raw public mail. Email is the single largest prompt-injection surface an agent has, because any stranger can put instructions in front of your model just by writing to you.

The forwarding-filter pattern neutralizes most of that. Create a fresh address used by nothing else, then add filters in your primary inbox that forward only the specific senders the agent needs: your calendar notifications, your invoicing tool, your newsletter platform. A malicious email to your public address never reaches the agent, and a malicious email sent directly to the agent's address arrives with no history, no contacts, and no linked accounts to exploit. Run the same logic for any inbound channel; our pre-connection checklist applies it to WhatsApp, Telegram, and calendar scopes.

Step 6: A Separate GitHub Account for the Agent

The agent gets its own GitHub account, invited only to the repositories it works on, never your personal account with its org memberships and admin rights. This gives you three things at once: least privilege, one-click revocation, and a clean audit trail where every commit and API call by the agent is attributable to the agent.

Use fine-grained personal access tokens scoped to specific repositories with the minimum permissions, name each token after the workflow that uses it, and store them as environment variables rather than in config files that get committed or rewritten. If the agent misbehaves or a token leaks, you revoke one machine account and your own identity is untouched.

Step 7: Monitoring Before Real Work

Observability comes before delegation: stand up a monitoring dashboard while the agent still has nothing important to do. Professional operators watch four things at minimum: active sessions, token spend per day, cron job outcomes, and gateway auth events, because each one is an early alarm for a different failure (a hijacked session, a runaway loop, silent breakage, and intrusion attempts respectively).

Our OpenClaw monitoring dashboard guide walks through the build. The order argument is the important part: if the dashboard exists first, day one of real work produces a baseline, and anomalies on day thirty are visible instead of invisible.

Step 8: Run Work Through a Kanban With a Heartbeat

The last step of an OpenClaw secure setup is operational, not technical: route the agent's work through a kanban board and let a heartbeat cron advance it. Instead of firing instructions into a chat and scrolling for results, you add cards to a queue; every heartbeat, the agent picks up the next card, moves it through in-progress to review, and leaves its evidence on the card.

This matters for security because review becomes structural. Nothing ships from the review column until you look at it, which is exactly the human-in-the-loop control that chat-driven agent use quietly loses. The same pattern powers Hermes-style setups too; see our agent kanban guide for board layouts that work.

Limitations and When Not to Bother

This playbook is calibrated for a solo professional running one always-on agent with real account access, and it is overkill below that bar. If you are just evaluating OpenClaw with no connected accounts and no secrets on the box, the one-click template plus steps 1 to 3 are enough to experiment safely.

It is also not sufficient above that bar. Multi-user and team deployments need tool-level restrictions between agents, secret isolation so one agent cannot read another's environment variables, and compliance controls this post does not cover; start with the 3-tier hardening guide for that tier-2 and tier-3 detail. And no ordering discipline fixes a fundamentally over-permissioned agent: if you give it your real email password instead of a filtered forward, steps 0 to 4 cannot save you.

Related Guides

• Harden OpenClaw: 3-Tier Security for Self-Hosted Deployments
• OpenClaw + Tailscale: The Right Way to Access Your Agent
• How to Secure OpenClaw Before Connecting Real Accounts
• OpenClaw Monitoring Dashboard: Track Agent Health