HomeGet Started

Self-host your own governance control plane

Free to deploy. You own the data. Run doctor, connect your first agent, and inspect the first decision record.

Expected evidence after deploy

npm run doctor or dashclaw doctor exits 0 or names the blocker. Your first governed action appears in /decisions, held work appears in /approvals, and /api/setup/live-proof can capture setup evidence without exposing secrets.

Cloud (recommended)

Vercel + Neon free tiers. Accessible from any device with managed HTTPS.

Local

Docker + localhost. Good for development or if you want everything on your machine.

Verify

Confirm your deployment is healthy

Doctor diagnoses database, configuration, auth, deployment, SDK reachability, governance staleness, data hygiene, shape drift, and write-path health. Its synthetic, isolated canary writes exercise configured paths and confirm that heartbeats, action records, and guard audit rows land during that run. It reports by default; pass --fix to apply safe repairs. Run it as the first thing after your instance comes up.

The live host canary covers the outside-in half: an hourly GitHub Actions cron probes your deployed hosts as a real unauthenticated client (pages render, trial mint stays fail-closed, OAuth discovery and the MCP handshake answer their contracts) and files its verdict to your instance; failures render on /setup#live-canary and raise a posture finding.

Operator (on the host)

npm run doctor

Filesystem-level fixes. Can write missing env vars to .env (always backed up first), run pending DB migrations, generate NEXTAUTH_SECRET/ENCRYPTION_KEY, fix CORS, and seed a default policy.

npm run doctor
Anyone with an API key

dashclaw doctor

Same engine, invoked via GET /api/doctor + POST /api/doctor/fix. No filesystem access. Add --json for CI, --no-fix to diagnose only.

npm install -g @dashclaw/cli
dashclaw doctor

Exit codes: 0 healthy, 1 warnings, failures, or unreachable.

Approve from anywhere

Resolve pending actions without opening the dashboard

DashClaw can expose dashboard, CLI, mobile PWA, and optional Telegram approval surfaces against the same /api/approvals/:id endpoint. Pick whichever your on-call workflow supports. waitForApproval observes the same server-side decision from each surface.

Mobile PWA

/approve

Phone-first approval surface. Add to your home screen and incoming approvals appear with the triggering policy, risk score, and one-tap Allow / Deny.

https://<your-instance>/approve
Telegram bot (optional)

Inline Approve / Reject

Pending actions push to an admin chat with inline buttons. If Telegram is unreachable, DashClaw warn-logs and approvals stay available via the other surfaces; it is purely additive.

dashclaw install telegram

Dashboard (/approvals) and CLI (dashclaw approve) are always on. Mobile PWA ships by default; Telegram is opt-in via TELEGRAM_BOT_TOKEN.

What you just deployed

Your DashClaw instance ships the core guard, policy, approval, and decision-recording surface without requiring an LLM API key. Optional integrations need their own configuration.

Governance

  • Decision audit trail with recorded action traces
  • Behavior guard -- no-code policy decisions, mechanically enforced through installed hooks, OpenClaw, and bounded invocation helpers
  • Policy pack gallery on /policies/packs -- curated packs for spend, outbound communications, unattended runs, infrastructure, fleets, and more, each previewable against recorded action history before installation
  • Human-in-the-loop approval gates with expiry (a lapsed approval can never release work)
  • Preflight plan authorization -- an agent submits its plan, you review one card with per-step verdicts, approved steps become single-use act-bound grants
  • Plan attestation -- the plan's authority is pinned by a content hash at submission, and an unattended run checks at start-up that its pinned plan is still approved, unexpired and unrevoked before it spends its first model call, failing closed if it drifted
  • Plan deviation events -- submitted governed actions are compared with the live approved plan; recorded departures can trigger your explicit per-kind policy choice
  • Scoped delegation constraints -- cap a spawned subagent's risk, action types, paths, and depth; attenuation only tightens
  • Role constraints -- a named authority bundle per agent role (allowed action types, risk ceiling, path scope); submitted actions outside the role escalate to your inbox
  • Containment verdicts -- a file-scoped edit or a Postgres statement can proceed reversibly instead of freezing: staged in an isolated worktree or an ephemeral Neon branch, you promote or discard the evidence on your own time
  • Approval flood guard with bulk resolution
  • Plain-English approvals -- pending items lead with the declared purpose and show the canonical redacted act that the approval binds
  • One judgment queue on /policies -- tuning, tightening, loosening, and calibration proposals with ratify/dismiss/undo in one click
  • Calibrated interruption controller on /policies#calibration (Tuning) -- set a target false-interruption rate, hold it with a distribution-free bound; shadow first, then relief mode stops it asking about the things you keep approving (never past your own riskiest approval, and one deny takes the band back)
  • External decision provider -- plug one outside decision engine into the guard; its verdict joins stricter-wins (its deny is absolute, its allow never loosens), with an explicit fail-closed posture when it is unreachable and an optional action-type scope for domain-specific providers
  • Guard degradation observability (deadline fallbacks surfaced, never silent)
  • Prompt injection scanning

Observability

  • Real-time SSE event stream
  • Token usage and per-action cost attached when clients report them
  • Risk signal monitoring (autonomy spikes, repeated failures, assumption drift, stale actions)
  • Coverage truth -- record-vs-recorded tool-use coverage with an explicit "no evidence" state, plus close_source outcome provenance
  • Fleet attribution -- multi-agent fan-outs joined from persisted lineage evidence
  • Risk composition ledger -- recorded guard scores include an itemized risk_breakdown when available
  • Session retros -- evidence-based end-of-session defensibility review

Audit & Evidence

  • Replayable audit trail with explicit receipt and signature status (Ed25519 receipts, JWKS export)
  • Evidence packaging (guard decisions + action records)
  • Tamper-evident receipts for the recorded content and verdict where receipts are issued

Security

  • Verified agent identity when JWKS / JWT verification succeeds, reported separately from payload-signature status
  • Per-harness composed identities (parent:sub) with fleet grouping
  • agent_defense rollup on recorded action details where supporting evidence is available
  • Secret redaction for recognized sensitive values and patterns on supported paths
  • Assumption tracking with one-click invalidation and drift reports
  • Content scanning for sensitive data

Platform

  • Multi-tenant org isolation
  • HMAC-signed webhooks
  • Full activity audit log
  • Docker + Vercel + any Node.js host

The core runtime is MIT licensed, self-hosted, and does not require an external AI provider. Optional semantic analysis and outside decision providers require their own services.

Alternative: Local Setup

Run locally with Docker

The installer generates secrets, writes .env.local, installs dependencies, and prints the API key your agents should use.

Windows (PowerShell)
./install-windows.bat
Mac / Linux (bash)
bash ./install-mac.sh

When it finishes, open http://localhost:3000.

6

Optional: require signed agent payloads

To require cryptographic payload signatures, set ENFORCE_AGENT_SIGNATURES=true on the dashboard host. The Python SDK's create_pairing_from_private_jwk() helper generates a keypair and registers the public key via POST /api/pairings; an admin then approves the pairing before signed actions are accepted. DashClaw reports this payload-signature status separately from JWT/JWKS identity verification.