# ClawManager: Kubernetes-Native Control Plane for AI Agent Instance Management

> A Go and TypeScript application that provisions managed AI agent runtimes on Kubernetes, governs model access through a built-in AI gateway, and enforces security policy across OpenClaw, Hermes, OpenCode, and DeepSeek Harness runtimes.

**Yuan-lab-LLM/ClawManager** — A Kubernetes-native control plane for AI agent instance management, with governed AI access, runtime orchestration, and reusable resources across multiple agent runtimes.

- Repository: https://github.com/Yuan-lab-LLM/ClawManager
- Website: https://yuan-lab-llm.github.io/ClawManager/
- Stars: 1,898 · Forks: 157
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/yuan-lab-llm-clawmanager

## What Problem ClawManager Addresses

Running AI agent instances for multiple users on Kubernetes involves repetitive work: provisioning agent runtimes, injecting model API credentials, configuring storage and networking, managing team access, and monitoring what agents are doing. Doing this manually for each new instance or user does not scale, and adding governance requirements (rate limits, model access control, audit logging) to bare Kubernetes deployments requires custom tooling.

ClawManager provides a control plane that handles these operations as a product. Platform teams can provision agent instances from a browser-based UI, administrators see all running instances and can dispatch commands to them, and security policies apply uniformly across all runtimes without per-deployment configuration.

The project targets three audiences named in the README: platform teams running AI agent instances for multiple users, operators who need runtime visibility and desired-state control, and builders who want governed AI access and reusable resource injection rather than manual per-instance setup.

## Four Supported Runtimes and How Provisioning Works

ClawManager currently supports four managed runtimes. OpenClaw provides Lite and Pro workspaces with native conversations, tools, and scheduled tasks. Hermes provides Lite and Pro workspaces with a persistent .hermes home directory. OpenCode provides coding workspaces with terminal and desktop access. DeepSeek Harness provides Lite pooled and Pro desktop workspaces with isolated browser access.

Lite instances use shared runtime pools, reducing resource cost for lighter workloads. Pro instances run in dedicated desktop deployments for stronger isolation. The README notes that as of 2026-06-14, rollout support was added for both modes.

Provisioning and lifecycle operations are asynchronous. The Northbound API, documented in docs/northbound-api-guide.md, exposes owner-scoped portal access for managing OpenClaw, Hermes, OpenCode, and DeepSeek Harness instances. The README from 2026-09-02 describes the addition of async lifecycle operations and protected Share Link management to that API.

A Skill Hub delivers skills to OpenClaw, Hermes, and OpenCode runtimes. Skills can be scanned for policy compliance. The skill scanning workflow was added on 2026-04-08.

## Getting Started with Docker Deployment

ClawManager is deployed as a Docker image. The Dockerfile shows a multi-stage build: a Node builder for the Hermes desktop web component, a Node builder for the frontend, and a Go builder for the backend. The final image is based on nginx:1.27-alpine and includes the nginx-module-njs package for JavaScript-based access token verification. The backend Go build produces two binaries: clawreef-server and clawreef-northbound-gateway.

The deployments directory contains Kubernetes manifests. The examples directory provides a Python Northbound API client with its own requirements file, an environment variable template (northbound.env.example), and a test client. To use the Python client, copy the environment template, fill in your credentials, install the requirements, and run the client script against a running ClawManager instance.

Two shell scripts at the repository root handle infrastructure setup: generate_northbound_certificates.sh generates the TLS certificates required for the Northbound API, and fix_northbound_gateway.sh handles a known gateway configuration migration step. Both must be run before the Northbound API is usable.

The README does not document a step-by-step local non-Kubernetes deployment path. The product is designed for Kubernetes from the start, and the deployment manifests in the deployments directory are the intended starting point for any production setup. The TLS expiry checking script at scripts/ci/check-tls-expiry.mjs can be run independently to verify certificate validity.

## AI Gateway, Security Platform, and Team Workspaces

The AI Gateway sits between agent runtimes and upstream LLM providers. It injects model credentials, enforces rate limits, tracks token costs per session, and logs requests for audit. As of 2026-03-26, the AI Gateway documentation covers model governance, audit and trace, cost accounting, and risk control.

The Security Protection Platform (secplane), added on 2026-07-07, provides a dedicated security console. It covers four defense layers: runtime defense (input and output surface monitoring, asset tamper-proofing, human approval workflows), host hardening and container isolation, outbound trusted-endpoint governance, and policy governance with kill-switch and circuit-breaker support. Full-chain audit and collaboration governance are also included. The console has full i18n support for five languages.

Team workspaces, added as an MVP on 2026-05-18, allow one-click team creation with OpenClaw member orchestration, Redis Team Bus injection, shared storage, member status tracking, and task dispatch. By 2026-08-18, teams were expanded with eight read-only built-in templates, natural-language custom team templates, live Execution Kanban, shared artifacts, and member-session visibility.

LDAP enterprise authentication was added on 2026-09-01, enabling integration with existing corporate identity providers.

## Limitations and Kubernetes Requirement

ClawManager requires Kubernetes as its deployment target. The Dockerfile builds a container intended to run in a Kubernetes cluster, and the deployments directory contains Kubernetes-specific manifests. There is no documented path for running ClawManager on bare metal or in a simple Docker Compose environment without Kubernetes.

The README describes the product as a control plane for running AI agent instances for multiple users. Single-user or single-agent deployments gain little from this overhead. The product is justified when managing five or more concurrent agent instances with different users, access policies, and team memberships.

The Northbound API uses a certificate-based authentication scheme that requires manual certificate generation. The generate_northbound_certificates.sh script handles this, but certificate rotation and expiry management are not documented.

The four supported runtimes (OpenClaw, Hermes, OpenCode, DeepSeek Harness) are specific products. Teams using other agent frameworks not in this list cannot use ClawManager's provisioning and governance features for those runtimes.

## How ClawManager Differs from Plain Kubernetes Deployments

Running AI agents directly on Kubernetes means writing Deployment manifests, Secrets for API keys, Services for networking, and custom RBAC rules for access control. There is no built-in concept of AI Gateway rate limiting, model cost accounting, or agent Skill Hub in vanilla Kubernetes. Each new user or agent instance requires manual manifest creation and secret rotation.

ClawManager adds a product layer on top of Kubernetes: a web UI for provisioning and monitoring, an AI Gateway that governs model access across all agents, a Skill Hub for distributing reusable capabilities, team workspace management, and a dedicated security console. Administrators do not need to write Kubernetes YAML to provision a new agent instance; they use the ClawManager interface, which translates their intent into Kubernetes operations.

The Security Protection Platform in ClawManager, added in July 2026, provides capabilities that vanilla Kubernetes does not: input and output surface monitoring for running agents, asset tamper-proofing, human approval workflows for sensitive operations, and a kill-switch mechanism. These features require both the application-level platform and the underlying Kubernetes infrastructure working in combination.

For teams that already have strong Kubernetes expertise and prefer to manage everything at the manifest level, the abstraction layer adds overhead without proportional benefit. For teams that need to scale agent operations to many users without building custom tooling for governance, audit, and skill management, ClawManager provides that tooling as a product rather than a collection of ad-hoc scripts.

## Release History and License

ClawManager releases daily builds with date-based version numbers. Version v2026.9.18 was released on 2026-09-18. The last push to the main branch was on 2026-09-27. The development pace shown in the What's New section of the README is high, with significant feature additions every one to two weeks throughout 2026.

The license is MIT. The README documents a WeChat community group and a Discord server at discord.gg/9RwgbGJD5R for community support.

The backend is written in Go, compiled to clawreef-server and clawreef-northbound-gateway binaries. The frontend is built with Node and bundled into the same Docker image. The Hermes desktop web component is a separate Node build included in the multi-stage Dockerfile.

## Conclusion

ClawManager fits platform teams that run AI agent instances for multiple users on Kubernetes and need a unified control plane for provisioning, governance, and security rather than managing raw Kubernetes deployments directly. The MIT license permits commercial use. Because ClawManager requires Kubernetes as its deployment target, it is not practical for single-developer setups or teams running agents on bare Linux servers without a Kubernetes cluster. The last push was on 2026-09-27. Before deploying, verify that your Kubernetes environment supports the access token verification mechanism used in the Nginx configuration, which relies on the nginx-module-njs package.

## FAQ

### Which AI agent runtimes does ClawManager currently support?

ClawManager supports four runtimes: OpenClaw (Lite and Pro), Hermes (Lite and Pro), OpenCode, and DeepSeek Harness (Lite and Pro). Each provides a different workspace environment with different capabilities and isolation levels.

### Does ClawManager require a cloud provider or can it run on-premise?

ClawManager requires Kubernetes as its deployment target. It can run on any Kubernetes cluster, whether hosted on a cloud provider or on on-premise hardware. The README does not document a non-Kubernetes deployment path.

### How does the AI Gateway in ClawManager govern model access?

The AI Gateway injects model credentials into agent requests, enforces rate limits, tracks token costs per session, and logs requests for audit. As of the March 2026 documentation update, it covers model governance, audit and trace, cost accounting, and risk control.

## Sources

- [License: MIT](https://github.com/Yuan-lab-LLM/ClawManager/blob/main/LICENSE)
- [Project website](https://yuan-lab-llm.github.io/ClawManager/)
- [README](https://github.com/Yuan-lab-LLM/ClawManager/blob/main/README.md)
- [Releases](https://github.com/Yuan-lab-LLM/ClawManager/releases)
- [Yuan-lab-LLM/ClawManager on GitHub](https://github.com/Yuan-lab-LLM/ClawManager)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yuan-lab-llm-clawmanager