Show HN: OpenClawMachines —— 将 OpenClaw 扩展至企业级应用
Show HN: OpenClawMachines – Extending OpenClaw to the Enterprise

原始链接: https://github.com/mathaix/OpenClawMachines

OpenClaw Machines 是一个开源、自托管的平台,旨在通过安全的硬件隔离沙箱运行 AI 智能体。与基于容器的解决方案不同,它使用 **Firecracker 微型虚拟机(microVM)**——每个微型虚拟机都有独立的客户内核和 KVM 边界——从而能够在您自己的基础设施上安全地执行不受信任或由智能体生成的代码。 **主要功能包括:** * **基础设施主权:** 在您自己的裸机服务器或云主机上运行控制平面和工作节点。通过利用自有硬件和本地 GPU 运行的模型,相比按 Token 或按智能体计费的托管服务,可显著提高成本效率。 * **稳健的架构:** 系统使用由 Cloudflare 支持的数据平面进行安全路由,隧道直接终止于微型虚拟机内部,确保不暴露任何宿主机端口。 * **集成生态系统:** 该平台内置支持浏览器自动化(Chromium 虚拟机)、实时终端、原生 MCP 工作空间集成(GitHub、Google 等)以及可观测性工具。 * **可扩展性:** 单台裸机服务器可在资源允许的范围内托管任意数量的隔离智能体,为 AI 开发提供一种固定成本的“微型云”。 OpenClaw Machines 采用 **Apache-2.0 许可证**发布,非常适合寻求专业级隔离、安全性和多智能体工作流成本控制的用户。

相关文章

原文

Run as many isolated OpenClaw agents as you need, on hardware you own.

License: Apache-2.0 CI Stars

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.

Click the screenshot to watch the 43-second demo on YouTube. This is a linked image, not an embedded player.

OpenClaw Machines demo: an agent calling a workspace MCP tool

The demo covers host onboarding, agent spin-up, the running Firecracker VM terminal, workspace MCP integrations, and an agent tool call end to end.

An OpenClaw machine running in a Firecracker microVM

  • 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.

If you run OpenClaw today, you have a few options:

  1. Local hardware — run it on your own laptop or desktop.
  2. A VPS (e.g. Hostinger, DigitalOcean) — rent a virtual server and run it there.
  3. 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.

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.

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.

  1. Control plane (Go backend) — the brain. Accounts, machines, hosts, and config; the API the UI/CLI call; placement and lifecycle orchestration.
  2. Hosts + worker agents — your Linux boxes. Enroll a host with an install script; its worker agent boots and stops Firecracker microVMs when told to.
  3. Machines — one isolated microVM per agent. Inside: the OpenClaw agent, a web chat gateway, and a live terminal.
  4. Browser VMs — separate microVMs running headful Chromium with a live view, driven by the agent over CDP for browser automation.
  5. 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.
  6. 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.

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:

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.

  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.
  2. Cloudflare + a dedicated host — the production-shaped deployment: domain, tunnels, edge auth, and an enrolled cloud or bare-metal host.
  3. The full workflow — create and use machines (chat, terminal, browser VMs), lifecycle, backups, runtime upgrades.

See CONTRIBUTING.md and the code of conduct.

Apache-2.0

联系我们 contact @ memedata.com