clawops

# clawops

[![npm version](https://img.shields.io/npm/v/@clawops/cli)](https://www.npmjs.com/package/@clawops/cli)
[![npm downloads](https://img.shields.io/npm/dm/@clawops/cli)](https://www.npmjs.com/package/@clawops/cli)

MCP-native infrastructure ops for OpenClaw — with read-only mode, destructive-action confirmation, and audit logs built in.

**clawops** is a CLI and [MCP](https://modelcontextprotocol.io/) server for deploying and operating
self-hosted [OpenClaw](https://github.com/openclaw/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.

```bash
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 subset
```

**Common 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.

---

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

```bash
clawops bug              # open a pre-filled issue in the browser
clawops bug --json       # print the issue URL for scripting
```

**Cloud 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 Vault `roleDefinitionId` that broke Key Vault RBAC entirely.
- **AWS:** Bedrock startup script now uses the IMDSv2 PUT→GET token flow (a plain `curl` to IMDS
  returned 401, so the region always fell back to `us-east-1`); replaced
  `AmazonBedrockFullAccess` with a least-privilege inline policy.
- **AWS (⚠️ migration impact):** migrated from inline Security Group ingress/egress arrays to
  individual `SecurityGroupIngressRule`/`SecurityGroupEgressRule` resources so CIDR changes no
  longer replace the whole Security Group. **Existing AWS stacks have their Security Group
  replaced on the first `clawops up` after this upgrade** — see
  `docs/decisions/0009-aws-sg-rule-resources.md` for the import-based mitigation.
- **All providers:** `accessMode=auto` egress-IP detection now returns a `Result` and 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.

```bash
clawops mcp wire                   # wire the default stack
clawops mcp wire --stack prod      # target a named stack
clawops mcp wire --force           # bypass gateway version check
```

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

```bash
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 CI
```

**`clawops_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 `pulumi` binary 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.md`](docs/limitations.md) for 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`](docs/support-matrix.md).

---

## Quick Start

```bash
npm install -g @clawops/cli
clawops setup
```

`clawops 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-stack
```

**Prerequisites:** 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