DEV Community: Adnan Sattar

NemoClaw for the Enterprise: Installing NemoClaw and Bootstrapping the Sandbox (Part 2)

Adnan Sattar — Fri, 08 May 2026 10:21:02 +0000

The substrate is ready. Now we move the agent into its cell and try not to bulldoze it on the way in.

In Part 1 we turned a fresh VPS into something an AI agent can safely live on; rootless user, Tailscale mesh, UFW, no public attack surface. That was the safe house. Empty.

This article puts the tenant inside.

The stack you're about to install is layered in a way that confuses people the first time they meet it, and the most expensive failure mode, running one perfectly innocent-looking command on the wrong day, quietly nukes everything you set up. So we're going to slow down on the mental model, install carefully, and treat the bootstrap as a one-shot operation. Because that's exactly what it is.

By the end of this guide you'll have:

The NemoClaw CLI installed and authenticated against an inference provider
A running NemoClaw sandbox (k3s + OpenShell + OpenClaw, all the way down)
A working nemoclaw connect shell into the sandboxed agent
The OpenClaw dashboard reachable from your laptop over Tailscale
A clear mental model of which command lives at which layer and which command will silently destroy your state if you run it twice

No Matrix yet. No skills, no policies.

Just a clean install with the failure modes labelled.

The Agent Cell

What You're Building

Here's the updated architecture, picking up where Part 1 left off:

┌────────────────────────────────────────────────────────────────────┐
│ Your Tailnet (Private)                                             │
│                                                                    │
│  [Your Laptop] ───SSH/HTTPS───▶ VPS (openclaw user)                │
│                                  │                                 │
│                                  │ Docker engine                   │
│                                  ▼                                 │
│                  ┌────────────────────────┐                        │
│                  │ openshell-cluster-     │                        │
│                  │ nemoclaw (Docker ctr)  │                        │
│                  │                        │                        │
│                  │ ┌────────────────────┐ │                        │
│                  │ │ k3s (single-node)  │ │                        │
│                  │ │                    │ │                        │
│                  │ │ ┌────────────────┐ │ │                        │
│                  │ │ │ NemoClaw       │ │ │                        │
│                  │ │ │ sandbox pod    │ │ │                        │
│                  │ │ │                │ │ │                        │
│                  │ │ │ OpenClaw ──────┼─┼─┼──▶ inference API       │
│                  │ │ │ agent          │ │ │                        │
│                  │ │ └────────────────┘ │ │                        │
│                  │ └────────────────────┘ │                        │
│                  └────────────────────────┘                        │
└────────────────────────────────────────────────────────────────────┘

Architecture

Four layers, top to bottom: the Docker engine on your VPS, a single Docker container running a self-contained k3s cluster (openshell-cluster-nemoclaw), a Kubernetes pod inside that cluster running the OpenShell sandbox, and inside that pod the OpenClaw agent itself.

This sounds like overkill for a single-VPS deployment. It isn't.

The k3s layer is what gives you cheap, repeatable sandbox lifecycle create, destroy, reset, snapshot without dragging Docker plumbing into agent execution. The OpenShell sandbox is what enforces the network and filesystem policies we'll write in Part 4. And the OpenClaw agent on top is just the workload.

The 60-Second Mental Model

Three commands, three layers. Internalise this before you type anything:

nemoclaw … — runs on the host. The orchestrator. Knows about Docker, k3s, and the sandbox lifecycle.
openshell … — runs on the host. Talks directly to the gateway and lets you manage policies, providers, port forwards. Lower-level than nemoclaw.
openclaw … — runs inside the sandbox. Manages plugins, skills, sessions. The agent's own CLI.

If you ever find yourself typing openclaw plugins install on the host, you're at the wrong layer. If you find yourself typing nemoclaw onboard twice, stop reading and go make coffee, we'll get to that one in a minute.

60-Second Mental Model

Step 1: Install the NemoClaw CLI

NemoClaw ships as an npm package. From your openclaw user on the VPS:

npm install -g nemoclaw

If npm complains about permissions, you skipped a step in Part 1. npm install -g should not need sudo if your user owns its npm prefix. Fix that before continuing rather than papering over it with sudo, which will create root-owned files in places you'll regret later.

Verify the install:

nemoclaw -h

You should see the help banner showing version 0.1.x or newer, with sections for Sandbox Management, Policy Presets, Services, and Troubleshooting. If the version reads v0.0.x, upgrade. There are real lifecycle bugs in the early-zero releases that bit several of us during early-2026 deployments.

Step 2: Pick an Inference Provider

NemoClaw is provider-agnostic but nudges you toward NVIDIA's Nemotron family. In practice, the cleanest path for a fresh deployment is OpenRouter:

Single API key, dozens of models behind it
Per-token billing, no commitments
Direct access to nvidia/nemotron-3-super-120b-a12b, which is what NemoClaw is tuned around
If you later want to swap to Anthropic or OpenAI, it's a one-line change

If you're an enterprise with a direct NVIDIA NIM contract, point at your NIM endpoint instead. The flow is identical. onboard will ask which provider you want and what credentials to use.

Step 3: Onboard (and Why You'll Only Do This Once)

This is the section where I get to be slightly insufferable about a warning, because it has cost more than one of my evenings.

nemoclaw onboard is the bootstrap command. It does five things in one shot: configures your inference provider, generates the gateway's mTLS certificates, pulls the OpenShell container images, brings up the k3s cluster inside Docker, and creates the sandbox pod with default policies attached.

It is a create-from-scratch command. Not idempotent. Not a "rerun to update" command.

Hard rule. Never run nemoclaw onboard against an existing sandbox. It will recreate everything from zero: your provider config, your policies, your sessions, your installed skills, your Matrix tokens (Part 3), all of it. There is no confirmation prompt that adequately captures how destructive this is.

If you need to change a policy, use nemoclaw <name> policy-add or openshell policy set. If you need to change a provider, use openshell provider create and openshell inference set. Treat onboard like mkfs: useful exactly once.

OK. With that out of the way, run it:

nemoclaw onboard

The CLI walks you through:

Sandbox name — accept the default (nemoclaw-sandbox) unless you have a reason. The companion commands all default to it, and overriding the name buys you nothing but typing.
Inference provider — pick openrouter (or nvidia, anthropic, openai per your choice in Step 2).
Model — for OpenRouter + Nemotron: nvidia/nemotron-3-super-120b-a12b. NemoClaw will validate it exists by issuing a tiny test completion before continuing.
API key — paste it. It gets written to ~/.nemoclaw/credentials.json with mode 600.

The CLI then hands off to OpenShell to bootstrap the gateway and sandbox. Don't kill the terminal. This takes anywhere from two to seven minutes depending on your VPS network.

Kill Switch

Step 4: Watch the Bootstrap

While onboard runs, what's actually happening:

Docker pulls the OpenShell gateway image and starts the openshell-cluster-nemoclaw container.
Inside that container, k3s comes up as a single-node cluster.
OpenShell deploys its gateway pod into the cluster and waits for it to report healthy.
NemoClaw applies the default network policy preset and creates the sandbox pod (nemoclaw-sandbox) in the openshell namespace.
The sandbox pod pulls its OpenClaw image and starts the agent.

If you want to follow along live, open a second SSH session to the VPS and tail the relevant logs:

# Container-level: is k3s healthy?
docker logs -f openshell-cluster-nemoclaw

# Sandbox-level: is the agent coming up?
nemoclaw nemoclaw-sandbox logs --follow

The second command will fail until the sandbox pod exists, which is fine. Retry it once onboard reports the sandbox is created.

When onboard finishes, you'll see something like:

✓ Gateway running at https://127.0.0.1:8080
✓ Sandbox 'nemoclaw-sandbox' is healthy
✓ Default policies applied

Bootstrap

Step 5: Verify the Gateway and Recognise the False Alarm

Sanity-check the gateway:

nemoclaw status
openshell status

Both should show the gateway as running and the sandbox as healthy.

A wart worth knowing: on a slow VPS, nemoclaw connect immediately after onboard will sometimes greet you with:

Gateway process started but is not responding

This is almost always a timing race condition, not a real failure. OpenShell's health check fires before the gateway has finished initialising mTLS. Wait thirty seconds, retry, and it's there. If it's still failing after a minute, then break out the diagnostics:

openshell doctor check
openshell doctor logs --lines 200

doctor check validates that Docker, k3s, and the gateway are all in expected states. doctor logs pulls the gateway container's stdout. Between them, you'll see the actual cause of any genuine failure.

Step 6: Connect to the Sandbox

The moment of truth:

nemoclaw nemoclaw-sandbox connect

The first connection negotiates an SSH session over the gateway's mTLS tunnel and drops you into a shell inside the sandbox pod. The prompt changes; the hostname changes; you're now executing commands inside an isolated environment whose filesystem and network access are governed by OpenShell policies.

Inside the sandbox, run the obvious sanity checks:

whoami
pwd # /sandbox
ls -la
openclaw --version

You'll find yourself as a non-root user inside /sandbox, with the OpenClaw binary on your PATH and a bare home directory. This is intentional. The sandbox starts almost empty by design; skills, plugins, and credentials get layered in deliberately rather than inherited from the host.

Try poking at the network from inside:

curl -s -o /dev/null -w "%{http_code}\n" https://google.com

You'll likely get a connection-refused or DNS failure, depending on the default policy. That's the policy engine working as advertised. Part 4 covers how to write policies that grant the agent exactly the network access it needs and nothing more.

Type exit to drop back to the host. The sandbox keeps running.

End to End Workflow

Step 7: Reach the OpenClaw Dashboard

OpenClaw exposes a web UI for chatting with the agent and managing sessions. NemoClaw maps it to 127.0.0.1:18789 on the VPS. From the host it's local-only by design. There's no public listener, and there shouldn't be.

To reach it from your laptop, use your Tailscale-resolved hostname:

http://<your-vps-tailscale-hostname>:18789

If you enabled MagicDNS in Part 1, that's something like http://openclaw-staging:18789. From any device on your tailnet, the dashboard loads. From anywhere else on the internet, the connection won't even establish. The port isn't exposed past localhost, and the firewall would drop it anyway.

The first time you load the dashboard it'll ask for a gateway auth token. That brings us to the one operational wart you should know about now, before it surprises you in production.

Reach the OpenClaw Dashboard

A Known Wart: The Gateway Doesn't Survive Host Reboots Cleanly

If you reboot the VPS, lose network on the host long enough for the gateway to give up, or restart Docker, the gateway process drops and the dashboard refuses your existing session. The sandbox pod is fine. The agent state is fine. The OpenClaw container in k3s is fine. It's just that the gateway's auth token gets rotated on restart and the dashboard doesn't pick up the new one automatically.

The recovery is mechanical: pull the new token out of the sandbox config and paste it into the dashboard.

docker exec openshell-cluster-nemoclaw \
  kubectl exec -n openshell nemoclaw-sandbox -- \
  python3 -c "import json; print(json.load(open('/sandbox/.openclaw/openclaw.json'))['gateway']['auth']['token'])"

That command is a worked example of the four-layer mental model: Docker → k3s → sandbox pod → file inside the pod. Read it left to right and you'll see each exec peeling off one layer.

Copy the printed token, paste it into the dashboard's auth prompt, and you're back. Keep this command in a paste-buffer somewhere; you will need it more than once.

A proper systemd-based autostart that watches for network changes and refreshes the dashboard auth automatically is doable, and it's on the roadmap for a later article in this series. For now, the manual recovery is twenty seconds and worth the explicitness. It forces you to notice when the gateway has restarted, which on a security-sensitive deployment is information you actually want.

Verification Checklist

Before moving on:

nemoclaw status shows the sandbox healthy and the gateway running
nemoclaw nemoclaw-sandbox connect drops you into a /sandbox shell
From inside the sandbox, openclaw --version returns a version string
From your laptop, http://<vps-tailscale-host>:18789 loads the OpenClaw dashboard
From anywhere not on your tailnet, the dashboard is unreachable
openshell doctor check reports green across the board
~/.nemoclaw/credentials.json exists with mode 600

If any of those fail, fix them before Part 3. Matrix layered on top of a flaky bootstrap will produce confusing failures that look like Matrix problems and aren't.

Where You Are Now

You have a four-layer agent stack running on a hardened VPS that has no public attack surface. The agent is alive, sandboxed, reachable from your laptop over Tailscale, and gated behind mTLS. It can't yet be talked to over a real chat protocol, can't reach external APIs beyond what the default policy allows, and has no skills installed. That's deliberate. We're laying down each capability one article at a time, and verifying it works before piling the next one on top.

Private AI Agent Layer Stack

The thing worth pausing on: this is already a defensible deployment. Even with no extra hardening, an attacker who somehow compromised your VPS would still have to escape the rootless openclaw user, then escape the sandbox container, then escape the k3s namespace isolation, before they could touch the host kernel. Each layer is breakable in theory. Stacking them is what makes the practical attack vanishingly expensive.

Defense in Depth

What's Next

Part 3. Matrix as the Control Channel. The default OpenClaw control surface is the dashboard you just loaded. That's fine for development. For a deployment where the messages flowing into the agent are, by definition, high-privilege instructions, you want the channel itself to be end-to-end encrypted and authenticated. Telegram doesn't cut it. Matrix does, but the install path has a few sharp edges around OIDC migration and device key conflicts that I'm going to walk through in detail, because the docs don't, and the failure modes are genuinely confusing the first time you hit them.

Part 4. Policy Engineering. OpenShell's policy engine is the actual reason to run NemoClaw rather than vanilla OpenClaw. We'll write per-domain network policies, set up filesystem allowlists, and walk through the live-update flow with openshell policy set --wait.

Part 5. Skills, Plugins, and Model Switching. ClawHub, the docker-cp-then-kubectl-cp pattern for getting skills into the sandbox safely, and how to flip between Nemotron and Claude Sonnet without a restart.

I'm collecting deployment war stories for Part 3's appendix. If this broke in a way I didn't cover, wrong CLI version, weird VPS provider, a doctor check red I haven't seen, drop the error in the comments. The Matrix article gets sharper for every one of these I see.

NemoClaw for the Enterprise: A Zero-Trust Setup for OpenClaw (Part 1)

Adnan Sattar — Fri, 17 Apr 2026 12:24:59 +0000

How to give your AI agent a safe house: full shell access, without becoming a liability to your security team.

An AI agent with shell access is one prompt injection away from a very bad day. It can read your files, touch your network, run commands, and if the box it's sitting on is exposed to the public internet invite the rest of the world in with it.

This is the first article in a series on running OpenClaw via NemoClaw in OpenShell sandbox. Before we touch agents, policies, or skills, we need to build the house they live in. That means a hardened VPS, no public attack surface, and a clear blast radius if something goes sideways.

By the end of this guide you'll have:

A fresh VPS running as a non-root user
Passwordless SSH with password login fully disabled
A Tailscale mesh that makes the box invisible to the public internet
A UFW firewall that drops anything not coming over Tailscale
Docker, Node.js, and uv installed and ready for OpenClaw

No agent yet. Just a safe house. Parts 2 and 3 will cover the NemoClaw install, Matrix E2EE messaging, and policy engineering.

NemoClaw for the Enterprise: A Zero-Trust Setup for OpenClaw

Why This Matters (the 30-second version)

Why A Zero-Trust Setup Matters

OpenClaw is powerful because it has broad access to the system it runs on. Shell, files, network. It can do almost anything a human operator can do. That's the feature. It's also the threat model.

A single crafted message coming through a public channel (Telegram, Discord, email) can, in the worst case, convince an unguarded agent to run commands on your behalf that you'd never consent to. The defense isn't one thing; it's layers:

Rootless execution : if something escapes, it's confined to a restricted user, not root
Zero-trust networking : the machine has no public attack surface at all
Passwordless SSH : brute-force attacks become mathematically hopeless
Strict firewall : anything not coming over the Tailscale interface is dropped
E2EE communication (covered in Part 2): the control channel can't be snooped

Each layer is cheap to set up. Skipping any one of them punches a hole that the others can't fully cover. Defense-in-depth only works when it's actually, you know, in depth.

What You're Building (architecture at a glance)

Here's the shape of what the stack looks like after this guide:

┌────────────────────────────────────────────────────────────────┐
│ Your Tailnet (Private)                                         │
│                                                                │
│ [Your Laptop] ───SSH───▶ [VPS: openclaw user]                  │
│                          │                                     │
│                          ├─ UFW (deny by default)              │
│                          ├─ tailscale0 (allowed)               │
│                          └─ OpenClaw Running in Sandbox        │
│                                                                │
└────────────────────────────────────────────────────────────────┘
             ▲
             │ (public internet never reaches here)
             ▼
        ╳ Port 22 closed ╳ Port 80/443 closed ╳

The server has no listening ports exposed to the public internet. Your laptop reaches it only through the Tailscale mesh, which is authenticated with your Tailscale identity, not a password. The openclaw user that owns the agent has sudo but not root shell access, so any escape is already one privilege short.

Mitigated Risks By Zero Trust Setup

Zero Trust Architecture

Prerequisites

Before you start, have these lined up:

Hardware: A VPS with at least 4 vCPU, 8 GB RAM, 50 GB SSD. OpenClaw will run on less, but NemoClaw pulls container images and runs a k3s cluster, so undersized boxes will bite you later.

OS: Ubuntu 24.04 LTS (recommended) or Debian 12. This guide assumes Ubuntu 24.04.

Virtualization: KVM. OpenVZ and similar shared-kernel setups don't play well with Docker. Hostinger, DigitalOcean, Linode, and Vultr all use KVM by default.

Accounts: Tailscale (free tier is fine).

Local tools: An SSH client (macOS/Linux have one built in; Windows users can use OpenSSH via PowerShell or WSL) and a Tailscale client on whatever machine you'll connect from.

One non-negotiable: don't host an unhardened OpenClaw instance on your primary workstation or any box with sensitive local data. If something goes wrong, you want the blast contained to a cheap VPS you can nuke and rebuild, not your daily driver.

Step 1: Provision and Update the VPS

Spin up an Ubuntu 24.04 instance with your provider of choice. Pick a region close to you for lower latency. Set a strong initial root password. You'll use it exactly once.

SSH in as root:

ssh root@YOUR_VPS_IP

Update the system and enable unattended security upgrades:

apt update && apt upgrade -y
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Install the packages you'll need over the rest of the guide:

apt install -y \
  ca-certificates \
  curl \
  gnupg \
  lsb-release \
  build-essential \
  git \
  unzip \
  jq

That's it for the root session. Everything else runs as an unprivileged user.

Step 2: Create a Rootless User

Root is a loaded gun. Running OpenClaw as root means any exploit (a bad skill, a prompt injection that slips past guardrails, a malicious package) gets full control of the box. Instead, we'll create a dedicated user with sudo rights for setup, but no root shell, so the default blast radius is limited.

Still as root on the VPS:

adduser --gecos "" openclaw
usermod -aG sudo openclaw

The --gecos "" flag skips the interactive "Full Name / Room Number" prompts. You'll be asked for a password. Set one, but you won't need it often because we're about to switch to SSH keys.

Step 3: Set Up Passwordless SSH

Password logins are a liability. Every Ubuntu box on the public internet is getting hammered with login attempts right now; yours is no exception. SSH keys are mathematically impossible to brute-force, and they're faster to use anyway.

On your local machine (not the VPS), generate an ED25519 key pair if you don't already have one:

ssh-keygen -t ed25519 -C "openclaw"

Accept the default path (~/.ssh/id_ed25519) or give it a custom name. A passphrase is optional but recommended.

Copy the public key to the VPS:

ssh-copy-id -i ~/.ssh/id_ed25519.pub openclaw@YOUR_VPS_IP

You'll be prompted for the openclaw user's password (the one you set in Step 2). This is the last time you'll need it.

Verify the key works:

ssh openclaw@YOUR_VPS_IP

You should land directly at a shell without being asked for a password. Don't skip this verification step. The next section disables password login entirely, and if the key doesn't work, you'll lock yourself out of the server.

SSH Only Access in Zero Trust Setup

Step 4: Disable Password Login

Critical: If your SSH key doesn't already work, fix that first. This step makes key-based auth the only way in. Get it wrong and your only recourse is the VPS provider's web console.

Once you've confirmed keys work, SSH in as the openclaw user and edit the SSH daemon config:

sudo nano /etc/ssh/sshd_config

Find and set the following values (uncomment them if they're prefixed with #):

PasswordAuthentication no
PermitRootLogin no
ChallengeResponseAuthentication no
UsePAM no

Save and exit (Ctrl+O, Enter, Ctrl+X in nano).

Restart SSH:

sudo systemctl restart ssh

Don't close your current SSH session yet. Open a new terminal and try to connect. If it works, you're good. If it doesn't, you still have the original session open to fix sshd_config. Only after you've confirmed a fresh connection works should you close the original.

Password-based attacks now hit a wall regardless of how weak the user's password is. This single change blocks the vast majority of automated SSH bot traffic.

Step 5: Install Core Dependencies

OpenClaw, NemoClaw and Openshell need a handful of runtimes:

Node.js 22+ for the CLI, Docker for the execution substrate, uv for Python package management, and Git because everything needs Git.

Here's the mental model worth internalizing before you run these commands:

OpenShell is the control plane. It orchestrates sandboxes.
Docker is the execution substrate. Containers are where agents actually run.
OpenClaw is the workload, the agent itself.

You're installing substrate and plumbing now. Workload comes in Part 2.

Node.js 22

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node -v # should print v22.x.x

Docker

Add Docker's official GPG key and repository:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install the Docker stack:

sudo apt update
sudo apt install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

Enable and start Docker, then add your user to the docker group so you don't need sudo for every command:

sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker $USER
newgrp docker

Validate:

docker info
docker run hello-world
docker compose version

If hello-world pulls and prints its banner, Docker is good.

uv (Python package manager)

uv is Astral's Rust-based replacement for pip and venv. It's dramatically faster and NemoClaw uses it under the hood:

curl -Ls https://astral.sh/uv/install.sh | bash
source ~/.bashrc
uv --version

If uv --version fails because it's not on your PATH, add it:

export PATH="$HOME/.local/bin:$PATH"
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

Sanity Check

Before moving on, verify the whole stack:

node -v # v22.x.x
git --version # any recent version
docker info # no errors
docker compose version
uv --version
curl -I https://google.com # outbound network works

If all five commands produce sensible output, your substrate is ready.

Step 6: Go Invisible with Tailscale

Here's where the architecture pays off. Right now, your VPS has a public IP with SSH (port 22) open to the entire internet. Even with password auth disabled, that's an attack surface. Zero-days in OpenSSH aren't hypothetical, and port scanners catalog your server within minutes of provisioning.

WireGuard Invisible Mode

Tailscale replaces that public exposure with a private WireGuard-based mesh network (a "tailnet"). Your devices (laptop, phone, VPS) get private IPs in the 100.x.x.x range, and they talk to each other directly over encrypted tunnels. The rest of the internet doesn't even know your VPS exists.

Install Tailscale on the VPS:

curl -fsSL https://tailscale.com/install.sh | sh

Bring the node online with SSH-over-Tailscale enabled:

sudo tailscale up --ssh

The CLI will print an authentication URL. Open it in your browser, log into Tailscale, and approve the device.

Install the Tailscale client on your local machine too (via tailscale.com/download) and log into the same account. Your laptop and VPS are now on the same tailnet.

In the Tailscale admin console, enable MagicDNS. It lets you SSH to your box by hostname (ssh openclaw@your-tailscale-hostname) instead of memorizing a 100.x.x.x IP.

The --ssh flag is worth understanding. It routes SSH through Tailscale's identity layer, which means even your SSH keys become a belt-and-suspenders backup rather than the primary auth mechanism. Tailscale handles the identity check at the network layer.

Step 7: Lock Down the Firewall

Tailscale gets you invisible, but belt-and-suspenders. We still want UFW to refuse anything that didn't come in over the tailscale0 interface. If Tailscale ever hiccups or gets misconfigured, the firewall is the last line of defense.

Install UFW:

sudo apt install -y ufw

Set deny-by-default for inbound, allow-by-default for outbound:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Allow all traffic on the Tailscale interface:

sudo ufw allow in on tailscale0

Allow SSH on the public interface as a temporary safety net. Once you've confirmed Tailscale SSH works end-to-end, you'll remove this:

sudo ufw allow OpenSSH
sudo ufw enable

Lock Down Firewall

UFW will warn that enabling may disrupt existing SSH connections. Since we explicitly allowed OpenSSH, you're fine. Type y.

Verify:

sudo ufw status verbose

You should see a short list of rules: Tailscale allowed on its interface, OpenSSH allowed on public, everything else denied.

Removing the Public SSH Safety Net

Once you've confirmed you can SSH in over Tailscale (ssh openclaw@your-tailscale-hostname), close the public SSH port entirely:

sudo ufw delete allow OpenSSH
sudo ufw reload

At this point, running a port scan against your VPS's public IP from anywhere on the internet returns nothing. The box is effectively invisible. The only way in is through your tailnet, authenticated with your Tailscale identity.

Where You Are Now

If you made it this far, the result is:

A VPS running Ubuntu 24.04 with automatic security updates
A non-root openclaw user with sudo rights
Passwordless SSH with password auth completely disabled
Tailscale mesh with MagicDNS, making the server reachable only from your tailnet
UFW dropping everything not coming over tailscale0
Docker, Node.js 22, Git, and uv installed and working

You haven't installed OpenClaw yet. That's deliberate. Everything up to this point is infrastructure that would be worth doing even if you were never going to run an AI agent. It's just good server hygiene. Now it's going to serve as the substrate for something that genuinely needs these protections.

Quick Verification Checklist

Before moving on, confirm:

ssh openclaw@your-tailscale-host works from your laptop
ssh openclaw@PUBLIC_IP from a device not on your tailnet fails to connect
sudo ufw status shows deny-by-default with tailscale0 allowed
grep -E "^(PasswordAuthentication|PermitRootLogin)" /etc/ssh/sshd_config shows both set to no
docker run hello-world succeeds as the openclaw user (no sudo)
node -v, uv --version, git --version all return versions

If any of these fail, fix them before installing OpenClaw. The security posture only holds if every layer is actually in place.

The NemoClaw Series Roadmap

What's Next

Part 2 & Part 3. Installing NemoClaw and Wiring Up Matrix E2EE: We'll install the NemoClaw CLI, bootstrap the sandbox, and replace Telegram with Matrix as the control channel. Matrix gives us end-to-end encryption out of the box, which matters because the messages flowing through it are, by definition, high-privilege instructions to an AI agent.

Part 4. Policy Engineering and Semantic Guardrails: OpenShell's network policy engine lets you declare exactly which domains the agent can reach. We'll write policies that implement least-privilege at the network layer, and build out an AGENTS.md that acts as the agent's operating manual. The behavioral equivalent of a firewall.

The short version: security for AI agents isn't a single feature. It's a stack. We've just laid the foundation.

If you found this useful, clap, follow, and drop a comment with what you'd like covered in the follow-ups. Production deployment horror stories especially welcome. They're the best teachers.