clawops
Allows selecting Amazon Bedrock as the LLM provider for the OpenClaw instance, supporting models available through Bedrock.
Adds Discord as a chat integration, allowing the OpenClaw gateway to interact via Discord bots.
Allows selecting Ollama as a local LLM provider for the OpenClaw instance.
Allows selecting OpenAI's models as the LLM provider for the OpenClaw instance.
Adds Slack as a chat integration, allowing the OpenClaw gateway to interact via Slack apps.
Adds Telegram as a chat integration, allowing the OpenClaw gateway to interact via Telegram bots.
Adds WhatsApp as a chat integration, allowing the OpenClaw gateway to interact via WhatsApp bots.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@clawopsdeploy a new OpenClaw stack on AWS"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
clawops
MCP-native infrastructure ops for OpenClaw — with read-only mode, destructive-action confirmation, and audit logs built in.
clawops is a CLI and MCP server for deploying and operating self-hosted OpenClaw instances. Provision on AWS, GCP, Azure, or any Linux VM — then manage day-to-day operations from the terminal, or let Claude Code and Cursor drive them through typed MCP tools with explicit safety controls.
What's new in v1.7.0
clawops harden — run an idempotent set of server-hardening modules against a deployed
stack over SSH. Each module has a read-only check() and an apply() step; check() runs first
and apply() is skipped when the box is already compliant. Sentinel files under
/etc/clawops/hardening/ record what has been applied.
clawops harden --list # show available modules
clawops harden --stack prod --dry-run # preview changes, apply nothing
clawops harden --stack prod # apply the default module set
clawops harden --stack prod --options ssh,ufw # apply a specific subsetCommon modules (all providers), ON by default: ssh (hardens sshd_config, guards against
lockout by verifying authorized_keys is non-empty before restarting sshd), ufw (deny-all
incoming, allow SSH + gateway 18789), fail2ban (SSH jail: 5 failures → 10-minute ban),
unattended-upgrades (security-only auto updates), and docker-socket (verify
/var/run/docker.sock is root:docker 660). Opt-in: auditd, lynis (CIS Level 1 scan →
~/.clawops/reports/), sysctl.
AWS modules (check-only, ON by default): aws-sg-audit (warns on 0.0.0.0/0 ingress on
unexpected ports) and aws-ssm-check (verifies AmazonSSMManagedInstanceCore for emergency SSM
shell access). Opt-in: aws-flow-logs, aws-guardduty.
clawops setup now presents a multi-select hardening step after deploy (skippable with
--no-harden), and clawops doctor --stack <name> gains a Hardening section showing which
modules are applied, missing, or drifted.
Related MCP server: Infraveil MCP server
What's new in v1.6.0
clawops bug — open a pre-filled GitHub issue with system context (version, Node, OS,
provider, stack count, SSH key presence) populated automatically. --json emits the URL without
prompting or opening a browser, suitable for scripting. clawops doctor now prints a clawops bug
hint in its footer when it exits with an error.
clawops bug # open a pre-filled issue in the browser
clawops bug --json # print the issue URL for scriptingCloud deploy bug fixes (AWS, GCP, Azure). This release fixes 10 bugs found in a deploy audit, several deploy-blocking:
Azure: updated deprecated image reference
UbuntuServer/22.04-LTS→0001-com-ubuntu-server-jammy/22_04-lts-gen2— every Azure deployment was broken; and fixed a malformed Key VaultroleDefinitionIdthat broke Key Vault RBAC entirely.AWS: Bedrock startup script now uses the IMDSv2 PUT→GET token flow (a plain
curlto IMDS returned 401, so the region always fell back tous-east-1); replacedAmazonBedrockFullAccesswith a least-privilege inline policy.AWS (⚠️ migration impact): migrated from inline Security Group ingress/egress arrays to individual
SecurityGroupIngressRule/SecurityGroupEgressRuleresources so CIDR changes no longer replace the whole Security Group. Existing AWS stacks have their Security Group replaced on the firstclawops upafter this upgrade — seedocs/decisions/0009-aws-sg-rule-resources.mdfor the import-based mitigation.All providers:
accessMode=autoegress-IP detection now returns aResultand throws a clear error on failure instead of silently producing a VM with zero ingress rules.
What's new in v1.5.0
clawops mcp wire — wire the OpenClaw gateway's own AI as an MCP client of clawops.
Once wired, in-conversation commands like "check if my stack is healthy" or "show me the last 20
log lines" invoke the real clawops CLI rather than having the gateway AI guess.
clawops mcp wire # wire the default stack
clawops mcp wire --stack prod # target a named stack
clawops mcp wire --force # bypass gateway version checkVersion-gated: requires OpenClaw ≥ 2026.4 on the gateway side. If the version is older, the command surfaces a clear upgrade prompt and exits cleanly.
The clawops setup wizard now also asks at the end of a successful deploy:
"Should the OpenClaw gateway's AI also be able to manage this stack?" — accepting wires the
client automatically over the same SSH session.
What's new in v1.4.0
clawops monitor — live dashboard for any deployed stack. Shows gateway health, container
status, CPU/memory, disk usage, and a rolling log tail. Refreshes on an interval with [r],
toggles logs with [l], and quits with [q].
Run without --stack to get an interactive stack picker first — probes all registered stacks
in parallel, shows only running ones by default, and lets you toggle to a full list ([a]) where
not-deployed stacks can be deleted from the registry with [d]. Press [s] inside the dashboard
to go back to the picker.
clawops monitor # interactive stack selection → dashboard
clawops monitor --stack prod # jump straight to a named stack
clawops monitor --stack prod | cat # one-shot snapshot for CIclawops_monitor MCP tool — same snapshot as a single structured JSON call, so Claude Code
and Cursor can check stack health without opening a terminal.
clawops stacks delete guard — now blocks deletion of a still-deployed stack and requires
--force to remove from the registry without tearing down cloud resources first.
Who this is for
OpenClaw users who want the simplest path to self-hosting across cloud or local VMs, with reliable deploy, status checks, logs, backups, and upgrades in a single CLI.
Claude Code / Cursor / MCP users looking for a real-world reference implementation of safe infrastructure operations through MCP — typed tool schemas, read-only mode, destructive-action confirmation, and audit logs.
Self-hosted AI and local-first developers who want to run their own AI assistant without committing to Kubernetes, a managed SaaS platform, or a single cloud provider.
What clawops does
Provisions and tears down OpenClaw infrastructure on AWS, GCP, Azure, and local VMs using the Pulumi Automation API (embedded — no
pulumibinary required).Manages day-to-day operations: status, logs, SSH, tunnels, config, agents, gateway, backups.
Exposes every operation as a typed MCP tool so AI agents can drive ops safely.
Enforces a plan → review → apply discipline for cloud deployments.
Emits JSON output everywhere (
--json) for scripting and automation.Never stores cloud credentials — reads them from your environment's existing CLI profiles.
What clawops does not do
No high availability or clustering. Optimized for single-node deployments.
No Kubernetes. It deploys to VMs, not container orchestration platforms.
No OpenClaw skill/agent authoring. clawops manages infrastructure; what runs on it is up to you and OpenClaw.
No TLS or domain automation (yet). Bring your own reverse proxy or see
docs/limitations.mdfor the manual path.No credential storage. Cloud credentials must be configured in your environment before using clawops. They are never written to
~/.clawops/config.json.No native Windows. WSL2 is fully supported; see
docs/support-matrix.md.
Quick Start
npm install -g @clawops/cli
clawops setupclawops setup is an interactive wizard that gets OpenClaw running in about 2 minutes. It
handles everything in one flow — no config files to write by hand, no commands to memorize.
What the wizard does
Step 1 — Choose a deployment target
Pick an existing server you can SSH into (Linux or macOS), or a new cloud VM on AWS, GCP, or Azure. Cloud deployments walk you through authenticating with the provider CLI if you aren't already signed in.
Step 2 — Pick an LLM provider
Choose from Anthropic, OpenAI, Amazon Bedrock, Ollama, or others. The wizard prompts for your
API key and saves it locally (in ~/.clawops/secrets/, chmod 600) — it is never sent anywhere
except to OpenClaw on the target host when the config is applied.
Step 3 — Add chat integrations (optional)
Select any combination of Discord, Telegram, Slack, WhatsApp, or Teams. The wizard collects each integration's bot token the same way as the API key — paste it in, reference an env var, or point to a file.
Step 4 — Wire your AI editor
Select which AI apps should have access to clawops — Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, and Zed are all supported. The wizard writes an MCP server entry into each app's config file using the absolute binary path so the app can launch it independently.
Step 5 — Deploy
The wizard bootstraps OpenClaw on the target host over SSH (installs Docker, pulls the image, starts the container), applies your LLM and integration config, generates a gateway auth token, and prints a direct dashboard URL:
✔ All done! OpenClaw is running.
ℹ Open dashboard: http://192.168.1.50:18789?token=<your-token>
ℹ Token saved to ~/.clawops/secrets/GATEWAY_TOKEN_my-stackPrerequisites: Node.js ≥ 22, an SSH key, and either an SSH-reachable Linux/macOS host or a
cloud account with CLI credentials configured (aws configure, gcloud auth login, or az login).
For a full narrated walkthrough with example output, see docs/demo-script.md.
Manual setup — existing server
If you prefer step-by-step control, or are adding clawops to an already-running deployment:
npm install -g @clawops/cli
clawops doctor # verify environment
clawops init --provider local --host 192.168.1.50 --user ubuntu --key-path ~/.ssh/id_ed25519
clawops up # installs Docker + OpenClaw over SSH
clawops statusSee docs/examples/local-vm.md for SSH prerequisites, firewall
setup, and troubleshooting.
Manual setup — cloud (AWS)
npm install -g @clawops/cli
# Requires AWS credentials in your environment (AWS_PROFILE or ~/.aws/credentials)
clawops init --provider aws
# Edit ~/.clawops/config.json — set stateUrl to your S3 bucket
clawops plan --provider aws --stack default --out /tmp/plan.json
clawops apply /tmp/plan.jsonConnect an AI editor
The setup wizard handles this automatically (Step 4). To wire or re-wire editors at any time:
clawops mcp installThis opens the same interactive checkbox used in the wizard — select Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, or Zed and clawops writes the MCP entry into each app's config using the correct absolute binary path.
To add the entry manually instead, paste this into your editor's MCP config:
{
"mcpServers": {
"clawops": {
"command": "/path/to/clawops",
"args": ["mcp", "serve", "--read-only"]
}
}
}Replace /path/to/clawops with the output of which clawops. Config file locations:
App | Path |
Claude Desktop (macOS) |
|
Claude Desktop (Linux) |
|
Claude Code |
|
Cursor |
|
Windsurf |
|
VS Code (macOS) |
|
VS Code (Linux) |
|
Zed |
|
Start with --read-only — it enables status, logs, config reads, and diagnostics while
blocking mutations. Remove it only after reviewing
docs/security/mcp-safety.md.
Destructive tools (clawops_destroy, clawops_up, clawops_config_set, etc.) require explicit
confirmation before executing — they will never run silently.
For HTTP mode setup see docs/mcp/.
Day-to-day operations
clawops status # Stack outputs: IP, gateway URL, SSH info
clawops logs -f # Tail OpenClaw logs over SSH
clawops ssh # Interactive SSH session
clawops ssh --command "docker ps"
clawops config get maxAgents
clawops config set maxAgents 8
clawops tunnel # Port-forward gateway UI to localhost
clawops destroy --yes # Destroy cloud-provider stack
clawops down --yes # Destroy local-provider stackCommands
Command | Description |
| First-run wizard — guided LLM, integrations, and deploy-plan generation |
| Register a stack in |
| Provision or update stack ( |
| Destroy local-provider stack (requires |
| Destroy cloud-provider stack with confirmation prompt ( |
| Show stack outputs: IP, gateway URL, region, provisioned time |
| Generate a deploy-plan JSON artifact (dry-run safe) |
| Apply a previously reviewed plan file ( |
| Interactive SSH session or run a remote command |
| Stream OpenClaw logs ( |
| Local port-forward to gateway UI over SSH |
| Get/set remote OpenClaw config values ( |
| List or restart OpenClaw agents |
| Restart the OpenClaw gateway service |
| Create or restore an OpenClaw state backup |
| List named stacks and their state |
| Check Node version, config, SSH key, provider credentials, and Pulumi home |
| Manage secrets: |
| Live dashboard: gateway health, container stats, log tail, stack picker |
| Start the embedded MCP server (stdio or HTTP) |
| Interactively wire clawops into AI editors |
| Wire the gateway's AI as an MCP client of clawops |
| List all commands and global flags |
| Apply security hardening to a deployed stack (SSH, UFW, fail2ban, unattended-upgrades, Docker socket; AWS: SG audit, SSM check, Flow Logs, GuardDuty) |
| Open a pre-filled GitHub issue with system context from |
Full flag reference: clawops <command> --help
Plan → Apply workflow
For non-local providers, clawops enforces a review-before-apply discipline:
# 1. Generate a plan — runs `pulumi preview` internally, produces JSON
clawops plan --provider aws --region us-east-1 --out /tmp/plan.json
# 2. Review plan.json — the `diff` field shows projected changes at plan-generation time
cat /tmp/plan.json | jq .diff
# 3. Apply — reads and validates the plan file, then runs `pulumi up`
clawops apply /tmp/plan.json
# Without --yes, apply prompts: "Continue? (y/N)"
clawops apply /tmp/plan.json --yes # skip prompt in automationThe plan JSON conforms to spec/deploy-plan.schema.json (AJV-validated) and captures reviewed
intent: provider, region, instance type, CIDR ranges, and OpenClaw version. apply re-runs
pulumi up using those parameters against the current live state — it does not replay a locked
execution artifact. Review and apply in the same session to minimize drift risk.
See docs/plan-apply.md for full semantics, drift guidance, and the safe CI pattern.
MCP server
clawops ships an embedded MCP server. Claude Code, Cursor, and any MCP-compatible agent can drive deployments without leaving the chat interface.
Wire your editor
clawops mcp install # interactive checkbox — writes config for selected appsThe wizard resolves the absolute binary path automatically so app launchers can find clawops
without inheriting your shell's PATH. See Connect an AI editor above
for manual config paths.
Wire the gateway AI
The OpenClaw gateway runs its own AI agent. Once wired, that agent can call clawops directly instead of guessing at infrastructure state:
clawops mcp wire --stack prod # write MCP client entry into gateway config + restartRequires OpenClaw ≥ 2026.4 on the gateway. The clawops setup wizard offers this step
automatically after a successful deploy.
Stdio mode (Claude Code / Cursor / VS Code)
Start the server manually or confirm your config is correct:
clawops mcp serve --read-only # safe for first evaluation
clawops mcp serve # full mode — enables provisioning, config write, ssh execHTTP mode (remote / multi-client)
clawops mcp serve --http 3333 --bind 127.0.0.1
# MCP HTTP server listening on 127.0.0.1:3333Do not bind to a non-loopback address without additional authentication controls in front of it.
Available tools
Tool | Toolset | Description |
| read | Show stack outputs |
| read | Tail OpenClaw logs |
| read | Read a remote config value |
| read | List running agents |
| read | Poll a long-running task |
| admin | List all stacks and their state |
| cli | Provision or update a stack |
| cli | Generate a deploy plan |
| cli | Apply a plan file |
| cli | Run a command over SSH |
| cli | Write a remote config value |
| cli | Destroy a stack (elicits confirmation) |
| workflow | End-to-end deploy: plan → confirm → apply → status |
read toolset tools are available in --read-only mode. All other toolsets require full mode.
Destructive tools require explicit confirmation (elicitation) unless yes: true is passed.
See docs/security/tool-risk-matrix.md for the full risk
classification of every tool.
Configuration
Config lives at ~/.clawops/config.json (override with $CLAWOPS_HOME).
{
"version": 1,
"defaults": {
"provider": "aws",
"stack": "default"
},
"stacks": {
"default": {
"provider": "aws",
"region": "us-east-1",
"stateUrl": "s3://my-clawops-state"
}
},
"ssh": {
"keyPath": "~/.clawops/id_ed25519",
"knownHostsPath": "~/.clawops/known_hosts"
}
}Cloud credentials are never stored in config — clawops reads them from the environment:
Provider | Credential source |
AWS |
|
GCP |
|
Azure |
|
Local | SSH host + key configured in |
Known limitations
See docs/limitations.md for the full list. Key points:
Single-node deployments only — not a high-availability or clustering platform.
clawops applyis not an immutable plan execution — seedocs/plan-apply.md.No TLS/domain automation in the current release.
MCP tools execute privileged operations — use
--read-onlyfor first evaluation.
Architecture
clawops
├── src/cli/ citty-based commands (one file per verb)
├── src/config/ ~/.clawops/config.json management
├── src/providers/ Cloud adapters (AWS, GCP, Azure, local)
│ ├── aws/ Pulumi inline program + ProviderAdapter
│ ├── gcp/
│ ├── azure/
│ └── local/ SSH bootstrap (no Pulumi)
├── src/pulumi/ Pulumi Automation API wrapper + output helpers
├── src/transport/ SSH client (ssh2) + connection pool + tunnels
├── src/mcp/ MCP server, tool handlers, progress tracking
├── src/plan/ Maker plan generation, AJV validation, apply
├── src/output/ ASCII table, spinner, JSON, human-readable output
├── src/errors/ Typed error hierarchy with exit codes
└── spec/ Machine-readable ground truth (JSON Schema, YAML)Key design decisions:
Pulumi Automation API (embedded): no
pulumibinary required; Pulumi home is sandboxed to~/.clawops/.pulumi; stack programs are inline TypeScript closuresState in cloud blob storage: GCS (
gs://), S3 (s3://), Azure Blob — no local state files, nopulumi.yamlSSH via
ssh2: never shells out to/usr/bin/ssh; TOFU host verification against~/.clawops/known_hosts; connection pool with 5-min idle TTLPlan → apply discipline: every non-local deployment goes through
generatePlan()→ review →applyPlan(); destructive changes always require human review of the plan JSONMCP-first: every CLI operation has a typed MCP tool; schemas generated from
spec/mcp-tools.yaml; all destructive tools use elicitation
See docs/architecture.md for a full narrative, and docs/decisions/ for ADRs.
Cloud provider stacks
Each cloud provider is an inline Pulumi program that creates the resources below. All three share the same outputs (publicIp, gatewayUrl, sshHost, sshPort, sshUser) consumed by the SSH and config-overlay layers.
AWS
flowchart LR
subgraph NET["Networking"]
VPC["VPC (10.0.0.0/16)"]
IGW[Internet Gateway]
SUBNET["Subnet (10.0.1.0/24)"]
RT[Route Table]
SG["Security Group (ports 22, 18789)"]
end
subgraph IAM["IAM"]
ROLE[IAM Role]
SSM[SSM Policy Attachment]
BED["Bedrock Policy Attachment (optional)"]
IP[Instance Profile]
end
subgraph COMPUTE["Compute"]
KP[EC2 Key Pair]
EC2["EC2 Instance (Ubuntu 22.04, IMDSv2)"]
EIP[Elastic IP]
endGCP
flowchart LR
subgraph NET["Networking"]
NW[VPC Network]
SN["Subnetwork (10.0.0.0/24)"]
FW1["Firewall: SSH port 22 (conditional)"]
FW2["Firewall: Gateway port 18789 (conditional)"]
ADDR[Static External IP]
end
subgraph COMPUTE["Compute"]
VM["Compute Instance (Debian 12, 20 GB)"]
endAzure
flowchart LR
RG[Resource Group]
subgraph NET["Networking"]
VNET["Virtual Network (10.0.0.0/16)"]
SUBNET["Subnet (10.0.1.0/24)"]
NSG["Network Security Group (ports 22, 18789)"]
PIP["Public IP Address (Static)"]
NIC[Network Interface]
end
subgraph COMPUTE["Compute"]
VM["VM (Ubuntu 22.04, managed identity)"]
end
subgraph KV["Key Vault (optional)"]
VAULT["Key Vault (RBAC, name max 24 chars)"]
RA["Role Assignment (Secrets User)"]
SECRET["Secret: gateway-token"]
endDevelopment
Setup
git clone https://github.com/dfridkin/clawops.git
cd clawops
# Node 22+ required; use nvm: nvm use
pnpm install
pnpm dev doctor # verify toolchainScripts
pnpm dev # run CLI from src/ via tsx
pnpm build # tsup → dist/
pnpm test # vitest (493 tests, ~3s)
pnpm test:changed # vitest --changed (fast edit loop)
pnpm test:integration # Docker-based SSH integration tests
pnpm typecheck # tsc --noEmit
pnpm lint # eslint src/ tests/ scripts/ (--max-warnings=0)
pnpm gen:schemas # regenerate src/providers/types.ts + src/mcp/tools/_generated.ts
pnpm gen:schemas --check # CI guard: committed generated files match spec
pnpm changeset # record a release note before mergingProject layout
Path | Purpose |
| Machine-readable ground truth: JSON Schema, YAML. Treat as source of truth. |
| Full technical specification (milestones, rules, schemas) |
| 25 normative rules (R1–R25) referenced throughout the codebase |
| Narrative system overview |
| Plan/apply semantics, drift guidance, CI pattern |
| CI integration guide: OIDC, env vars, plan → apply in CI |
| MCP safety model, tool risk matrix, redaction, audit logs |
| Per-provider capability matrix |
| Architecture Decision Records |
| Invokable procedures: |
| Path-scoped lint rules loaded by Claude Code |
Code generation
Two files are generated from spec/ and must not be hand-edited:
src/providers/types.ts—ProviderAdapterinterface fromspec/providers.schema.jsonsrc/mcp/tools/_generated.ts— Zod schemas and type exports fromspec/mcp-tools.yaml
Run pnpm gen:schemas after modifying either spec file. CI enforces this with --check.
Adding a provider
Use the /add-provider skill in Claude Code, or follow src/providers/CLAUDE.md. Every adapter must satisfy ProviderAdapter in src/providers/types.ts — do not relax the schema to fit the adapter.
Adding an MCP tool
Use the /mcp-tool skill. The skill adds the tool to spec/mcp-tools.yaml, runs pnpm gen:schemas, creates the handler in src/mcp/tools/<toolset>/<name>.ts, and wires it into the registry. All four annotation hints (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) are required on every tool.
Conventional commits
feat(scope): description
fix(scope): description
docs / refactor / chore / test / perf / ciUse pnpm changeset to record a release note before merging a feat or fix.
Milestones
Milestone | Status | What ships |
M0 — Scaffold | ✅ | Tooling, CI, stubs, generated types |
M1 — GCP MVP | ✅ |
|
M2 — Remote Mgmt | ✅ |
|
M3 — AWS + Azure | ✅ | AWS EC2 + Azure VM adapters; |
M4 — Local VM | ✅ | Local adapter (SSH bootstrap, no Pulumi); |
M5 — MCP Layer | ✅ |
|
M6 — Plan/Apply | ✅ |
|
M7 — v1.0 Polish | ✅ | Full |
See docs/roadmap.md for the public roadmap and upcoming work.
License
MPL-2.0 — see LICENSE.
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dfridkin/clawops'
If you have feedback or need assistance with the MCP directory API, please join our Discord server