GitHub - mathaix/OpenClawMachines: Manage OpenClaw in your team (Enterprise) by providing it compute infrastructure, tool integration, Authentication and security primitives
Pangram verdict · v3.3
We believe that this document is a mix of AI-generated, AI-assisted, and human-written content
AI likelihood · overall
MixedArticle text · 1,480 words · 6 segments analyzed
OpenClaw Machines Run as many isolated OpenClaw agents as you need, on hardware you own.
OpenClaw Machines is an open-source platform for running OpenClaw in secure AI sandboxes on your own infrastructure. A control plane orchestrates your hosts, and each agent runs in its own Firecracker microVM on them — hardware-isolated, safe for untrusted and agent-generated code. A Cloudflare data plane is the front door: every machine gets its own subdomain behind edge auth, reached through a tunnel that terminates inside the VM — no host port is exposed for user-to-VM traffic. The current control plane still needs private or firewall-restricted access to each agent's authenticated control API on 9090. See it running at openclawmachines.com. The Apache-2.0 public core ships every piece of that stack:
a minimal control plane — Go API, Postgres-backed accounts, machines, and hosts; placement, machine lifecycle, host enrollment, backups, and durable workflows; the host agent (ocm-agent) — boots, supervises, and reaps Firecracker microVMs on your enrolled Linux boxes, managing bridge/TAP networking and rootfs staging; a per-host LLM proxy (LiteLLM) — one place for model keys and BYO-key support, with per-machine usage tracking across providers (or your own locally served models); the OpenClaw runtime — the in-VM pieces: auth proxy, web-chat gateway, live terminal, and the artifact-driven runtime staging/upgrade flow; the browser runtime — paired Chromium browser VMs with CDP routing and a watchable live view; workspace integrations / native MCP — GitHub, Google Workspace, OpenAPI, GraphQL, and remote-MCP tools connected once per workspace and exposed to machines through the OCM MCP facade; and the build pipelines that assemble it all — every component's build command, the GCS artifact bucket layout, host provisioning scripts, and the release lanes.
The ocm CLI lives in the separate mathaix/ocm-cli Apache-2.0 repository. Video link Click the screenshot to watch the 43-second demo on YouTube. This is a linked image, not an embedded player.
The demo covers host onboarding, agent spin-up, the running Firecracker VM terminal, workspace MCP integrations, and an agent tool call end to end.
Why OpenClaw Machines
Security. Real isolation, not containers: one Firecracker microVM per agent, with its own guest kernel behind a KVM hardware boundary — and auth enforced at the edge and again inside every VM. Cost. One flat server cost: rent a single bare-metal box and run as many hardware-isolated agents as it fits — see how the options compare. The same architecture cuts token spend too: route agents to open-source models running on your own GPU hardware instead of paying per-token APIs. Sovereignty. Your hardware, your data, your keys. Run the control plane and workers on machines you own, and route model traffic through the per-host LLM proxy to any provider — or to models served on your own GPUs. Open source. Apache-2.0 public core and companion ocm CLI, permissively licensed for adoption, embedding, and contribution. Enterprise. Multi-user accounts and teams, admin-gated host management, encrypted per-machine secrets, and capacity/placement policies across your fleet. Ecosystem. Browser VMs for web automation, live terminal and web chat, per-VM routing, workspace-scoped native MCP integrations, backups/snapshots, agent memory, and observability with OpenTelemetry/Opik tracing and per-machine usage tracking.
How the options compare If you run OpenClaw today, you have a few options:
Local hardware — run it on your own laptop or desktop. A VPS (e.g. Hostinger, DigitalOcean) — rent a virtual server and run it there. A managed service (e.g. KiloClaw) — spin up a hosted OpenClaw instance and pay per instance.
OpenClaw Machines is the fourth option: rent one bare-metal server (OVHcloud, Hetzner, …), point OpenClaw Machines at it, and spin up as many hardware-isolated OpenClaw instances as the box will hold. One agent or fifty — the cost stays one flat server.
Feature Local hardware VPS (Hostinger) Managed (KiloClaw)
Setup effort Low Medium Lowest Medium (provision + enroll host)
Per-agent isolation Process-level Shared-kernel / container Per instance (managed) Hardware — Firecracker microVM
Run many agents Limited by your box Limited by VPS size Yes — but pay for each Yes — as many as the server fits
Multi-user / teams No Manual Varies Yes — built-in accounts & teams
Cost model Your own hardware Pay per VPS Pay per instance Pay per server (flat)
Cost at scale Doesn't scale Rises with size Highest (linear per agent) Lowest per agent
Hardware control Full (but limited) Virtualized, shared None Full — dedicated bare metal
Data & keys stay yours Yes Mostly No (their infra) Yes — your hardware
Backups / snapshots Manual Provider snapshots Managed Built-in
Ops / maintenance You You None You (self-hosted control plane)
In short: the managed route is easiest but priced per agent; local and VPS are cheap to start but don't isolate or scale well. OpenClaw Machines trades a little more setup for the best economics and isolation once you're running more than a couple of agents — one server, many hardware-isolated agents, all yours. How it works OpenClaw Machines turns your own Linux servers into a pool of secure, on-demand sandboxes. Each sandbox is a real Firecracker microVM (its own kernel, hardware-isolated via KVM) that runs one AI agent. The platform is the control plane that creates those VMs, keeps track of them, routes traffic to them, and tears them down — so you can run many untrusted agents safely on infrastructure you own. Think: a mini-cloud for AI agents, that you self-host.
Control plane (Go backend) — the brain. Accounts, machines, hosts, and config; the API the UI/CLI call; placement and lifecycle orchestration. Hosts + worker agents — your Linux boxes.
Enroll a host with an install script; its worker agent boots and stops Firecracker microVMs when told to. Machines — one isolated microVM per agent. Inside: the OpenClaw agent, a web chat gateway, and a live terminal. Browser VMs — separate microVMs running headful Chromium with a live view, driven by the agent over CDP for browser automation. Routing / data plane — every running VM gets its own subdomain and a Cloudflare Tunnel that terminates inside the VM, with auth enforced at the edge and again in-VM. Workspace integrations (native MCP) — connect external tools once per workspace (GitHub, Google Workspace, or any OpenAPI / GraphQL / remote-MCP endpoint); the control plane exposes them to each machine's agent through a single built-in MCP server, so the agent discovers and calls them with ocm.search_tools / ocm.call_tool instead of per-integration wiring.
flowchart TB U["you — browser / ocm CLI"] --> EDGE["Cloudflare edge<br/>Access auth · Worker route lookup (KV)"] EDGE -->|dashboard / API| CP["Control plane (Go)<br/>accounts · machines · hosts<br/>placement · lifecycle · backups"] CP --- DB[("Postgres")] CP -->|enroll · heartbeat · boot/stop :9090| H1["Host 1 — your Linux box<br/>ocm-agent · LLM proxy · CDP proxy"] CP -->|…| HN["Host N"] EDGE -->|per-VM tunnel, terminates inside the VM| VM1 subgraph H1X["Host 1's microVMs"]
VM1["Machine — Firecracker microVM<br/>OpenClaw agent · web chat · terminal<br/>authproxy + cloudflared inside"] BVM["Browser VM<br/>headful Chromium · live view"] VM1 -->|CDP| BVM end H1 --- H1X
Loading
The full design — data plane, routing, tunnels, lifecycle, config, and the build/release flow — is in docs/architecture.md, and the five-layer stack (React UI → Cloudflare edge → Go control plane → host agents → Firecracker sandboxes) is in docs/tech-stack.md. Requirements OpenClaw Machines runs Firecracker microVMs, which require KVM. You need a KVM-enabled Linux host: bare metal, or a cloud VM with nested virtualization enabled. It does not run on macOS, Windows/WSL, or a standard cloud VM without nested virtualization. Check your host: make preflight Getting started The Getting Started guide is three stages, each ending with something working:
Using a coding agent? Point it at docs/getting-started.md and ask it to follow the guide from Stage 1.
Local evaluation — the full stack + a real Firecracker machine on one KVM-capable Linux box. No Cloudflare or public domain is required; use an existing KVM host or the optional GCP provisioning example. Cloudflare + a dedicated host — the production-shaped deployment: domain, tunnels, edge auth, and an enrolled cloud or bare-metal host. The full workflow — create and use machines (chat, terminal, browser VMs), lifecycle, backups, runtime upgrades.
Project docs
Getting Started — the three-stage guide above User guide — using a machine day-to-day (model, chat, terminal, browser VM, files, logs, traces, backups) Workspace integrations / native MCP — connect GitHub, Google Workspace, OpenAPI, GraphQL, and remote-MCP tools once per workspace Architecture — data plane, routing, tunnels, lifecycle, workspace integrations / native MCP Tech stack — the five layers,
client to sandbox Local and BYO-host setup Control plane deployment profiles Self-hosted control plane prerequisites LLM operator runbook Public docs inventory Contributing · Security policy · Code of conduct ocm CLI project
Community & support
GitHub Discussions — questions, ideas, show & tell Issues — bugs and feature requests Roadmap — the open-source readiness tracker: what's done, what's next Found a vulnerability? See the security policy.
Contributing See CONTRIBUTING.md and the code of conduct. License Apache-2.0