Deploying OpenClaw with Kata Containers: Hardware-Isolated AI on Your Own Server

OpenClaw is a personal AI assistant with a multi-channel gateway — think of it as a self-hosted AI hub that connects to your tools, documents, and workflows. Running it on your own infrastructure keeps your data private. Running it inside Kata Containers adds hardware-level isolation, ensuring that even if the AI workload is compromised, it cannot escape to your host system.

This guide covers two ways to get started — pick whichever fits your workflow.

Why Kata Containers for AI Workloads?

AI assistants like OpenClaw process sensitive data: your documents, API keys, conversation history, and workspace files. Standard Docker containers (runc) share the host kernel — a container escape exploit could expose everything on the host.

Kata Containers solve this by running each container inside a lightweight virtual machine:

	runc (standard)	Kata
Kernel	Shared with host	Dedicated guest kernel
Isolation	Linux namespaces + cgroups	Hardware VM boundary (VT-x/EPT)
Escape impact	Full host access	Contained in VM
OCI compatible	Yes	Yes

For AI workloads that handle private data, the security trade-off is compelling: you get a hardware isolation boundary that's orders of magnitude harder to bypass than namespace-based containers.

Bare-metal requirement: read this first

Kata Containers need direct /dev/kvm access on the host. That means bare-metal servers only. Every Hetzner Cloud VM type — CX, CPX, CCX, and CAX — runs on a hypervisor that does not expose /dev/kvm to the guest, and Hetzner's own FAQ confirms nested virtualisation is not supported on Cloud servers. On Hetzner you need a Robot bare-metal server. Same rule applies elsewhere: any provider that puts you inside a VM cannot run Kata. Providers where Kata works: Hetzner Robot, OVH bare metal, Scaleway Dedibox, self-owned hardware.

Path A: Deploy via TryDirect (Easiest)

The fastest way to run OpenClaw with Kata — no Terraform, no Ansible, no infrastructure to manage. TryDirect handles the deployment flow for you, but Kata still requires a host with real /dev/kvm access.

1. Create a TryDirect account

Sign up at try.direct. If you're bringing your own infrastructure, make sure the target host is a bare-metal server (see the section above).

2. Create your stack

From the dashboard, select OpenClaw from the app catalog. Choose Kata Containers as the runtime.

3. Deploy

Click Deploy. TryDirect handles everything:

Targets infrastructure with real KVM access
Installs Docker and Kata Containers
Generates the compose file with runtime: kata
Deploys OpenClaw with hardware isolation

You get a running OpenClaw instance with Kata isolation in minutes, accessible via the URL shown in your dashboard.

4. Manage

Use the TryDirect dashboard or the Stacker CLI:

stacker status                     # container health
stacker logs --service openclaw    # view logs
stacker agent status               # verify runtime: kata

That's it. If you don't need full control over the infrastructure, TryDirect is the recommended path. Read on only if you prefer to self-host.

Path B: Self-Hosted Setup (Full Control)

If you'd rather manage your own servers, you can provision and configure everything yourself using the bare-metal guidance and Ansible files included in the Stacker repository.

What you need

A bare-metal server — Hetzner Robot or any provider that exposes /dev/kvm directly to your host OS
Ansible installed locally
The Stacker CLI installed

Hetzner users: you need a Hetzner Robot bare-metal server, not a Hetzner Cloud VM. All Hetzner Cloud VM families — CCX, CX, CPX, and CAX — run on a hypervisor that does not expose /dev/kvm to the guest. See the Hetzner KVM Guide for a valid bare-metal setup flow.

Step 1: Provision a Hetzner Robot bare-metal server

Order and install the server first:

Order an x86_64 dedicated server in the Hetzner Robot portal.
Install Ubuntu 22.04 LTS (or another supported Linux distribution).
Add your SSH key and boot the server.
SSH into the host and verify that KVM is actually present:

ssh root@<server-ip>
ls -la /dev/kvm
lsmod | grep kvm
egrep -c '(vmx|svm)' /proc/cpuinfo

If /dev/kvm is missing, stop there — that host cannot run Kata Containers.

Step 2: Configure with Ansible

Once the bare-metal server is online, use the Ansible playbook at docs/kata/ansible/kata-setup.yml:

cd stacker/docs/kata/ansible

ansible-playbook -i <server-ip>, kata-setup.yml \
  --private-key ~/.ssh/id_rsa \
  --user root

The playbook:

Validates KVM access (/dev/kvm)
Installs Kata Containers from the official APT repository
Merges the kata runtime into Docker's daemon.json
Restarts Docker and runs a smoke test (docker run --rm --runtime kata hello-world)

Step 3: Initialize your OpenClaw stack

mkdir openclaw-stack && cd openclaw-stack

# Initialize a stacker project
stacker init

# Add OpenClaw from the service catalog
stacker service add openclaw

This generates a stacker.yml with OpenClaw configured:

name: openclaw-stack
app:
  type: custom

services:
  - name: openclaw
    image: ghcr.io/openclaw/openclaw:2026.3.1
    ports:
      - "18789:18789"
    environment:
      OPENCLAW_GATEWAY_BIND: lan
    volumes:
      - openclaw_config:/home/node/.openclaw
      - openclaw_workspace:/home/node/.openclaw/workspace

The image is pinned to 2026.3.1 for reproducibility. Substitute a later tag once you've tested it.

Step 4: Deploy with Kata isolation

stacker deploy --runtime kata

That's it. Stacker will:

Validate the runtime value (kata is accepted, unknown values are rejected)
Check capabilities — verify the target agent supports Kata
Generate the compose file with runtime: kata on each service
Deploy via Docker Compose on the target server

Each OpenClaw container now runs inside its own lightweight VM with a dedicated kernel.

Step 5: Verify the deployment

# Check container status
stacker status

# View logs
stacker logs --service openclaw --follow

# Verify Kata runtime is active
stacker agent status
# Look for "runtime": "kata" in the deployment details

On the server, you can also verify directly:

ssh root@<server-ip>
docker inspect openclaw | grep -i runtime
# Expected: "Runtime": "kata"

Why this matters for OpenClaw specifically

OpenClaw processes and stores:

Your conversations with AI models
API keys for LLM providers (OpenAI, Anthropic, etc.)
Workspace files that may contain proprietary code or documents
Gateway configurations that bridge multiple communication channels

With standard runc, a vulnerability in OpenClaw's Node.js runtime, a dependency supply-chain attack, or a malicious prompt injection that achieves code execution would have direct access to the host filesystem and network.

With Kata, that exploit is trapped inside a VM:

It sees a minimal guest kernel, not your host
It cannot access host files outside its mounted volumes
It cannot inspect other containers or host processes
Network access is mediated through a virtual NIC

Advanced: mixed runtime stacks

Not every service in your stack needs Kata. You can run security-sensitive services (like OpenClaw) with Kata while keeping supporting services (like databases) on standard runc:

services:
  - name: openclaw
    image: ghcr.io/openclaw/openclaw:2026.3.1
    runtime: kata          # Hardware-isolated
    ports:
      - "18789:18789"
    environment:
      OPENCLAW_GATEWAY_BIND: lan
    volumes:
      - openclaw_config:/home/node/.openclaw
      - openclaw_workspace:/home/node/.openclaw/workspace

  - name: postgres
    image: postgres:16
    # runtime: runc (default) — database stays on runc for performance
    environment:
      POSTGRES_DB: openclaw
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data

This gives you the best of both worlds: hardware isolation where it matters, native performance where it doesn't.

Kata fallback behavior

If you request --runtime kata but the agent detects that Kata is unavailable (e.g., /dev/kvm missing after a host migration), the agent will:

Log a kata_fallback warning
Fall back to runc
Report the fallback in the deployment result

Stacker surfaces this warning in CLI output:

Warning: Kata runtime unavailable on target host, fell back to runc.
  Reason: /dev/kvm not accessible

This ensures your deployment succeeds even if Kata becomes temporarily unavailable, while keeping you informed about the security downgrade.

Summary

Path	What you do	What's handled for you
TryDirect	Sign up, pick OpenClaw + Kata, click Deploy	KVM-capable infrastructure, Docker, Kata, DNS
Self-hosted	Provision Robot bare metal, run `kata-setup.yml`, then `stacker deploy --runtime kata`	Compose generation, runtime injection

Running OpenClaw inside Kata Containers gives you:

Privacy: your AI data stays on your server, not in a cloud SaaS
Isolation: hardware-enforced VM boundary around each container
Simplicity: one flag (--runtime kata) — everything else is standard Docker
Compatibility: standard OCI images, no rebuilds required

For more details, see the Kata Containers documentation, Hetzner KVM Guide, and Network Constraints.