DocksyClaude & MCP
Docksy is built to be operated by Claude. A first-party MCP server and a Claude Code plugin let Claude deploy, read live metrics, diagnose problems and fix them, always with your consent.
No AI inside Docksy. Docksy never calls an LLM and never sends your data anywhere. diagnose is deterministic and returns evidence. Claude, running on your machine with your account, does the reasoning.
1. Create an API token
In Docksy: Settings → API tokens → New token. Pick a scope:
- full: Claude can deploy, restart, roll back, and so on.
- read: Claude can look at everything and change nothing. A great way to start.
The token (dsk_…) is shown once. The Claude page (/claude) in your Docksy dashboard shows ready-to-paste snippets that include it.
$ export DOCKSY_URL="https://docksy.example.com" $ export DOCKSY_TOKEN="dsk_..."
Add these to ~/.zshrc or ~/.bashrc so every session has them.
2. Install the Claude Code plugin (recommended)
# inside Claude Code
/plugin marketplace add osmanyousaaf/docksy
/plugin install docksy@docksy
Restart Claude Code (or run /reload-plugins), then check that /mcp lists docksy as connected. The plugin bundles:
| Type | Name | What it does |
|---|---|---|
| MCP server | docksy | All the tools below, via npx -y @crovenai/docksy-mcp |
| Command | /docksy:deploy [app] | Deploy, watch the build, verify the URL |
| Command | /docksy:status [target] | Fleet health at a glance |
| Command | /docksy:diagnose [target] | Root-cause a slow, failing or down server or app |
| Command | /docksy:logs <app> | Logs with errors highlighted and explained |
| Command | /docksy:rollback <app> | Zero-downtime rollback to a previous good deploy |
| Skill | docksy-deploy | Detect the stack → Dockerfile → create → deploy → watch → verify |
| Skill | docksy-diagnose | Evidence-first diagnosis, fixes only with consent |
| Skill | docksy-incident | Triage → mitigate → root cause → postmortem |
| Skill | docksy-setup-server | Add and provision a VPS |
| Skill | docksy-add-database | One-click database plus verified daily backups |
| Skill | docksy-dockerize | Write a production Dockerfile for your repo |
| Agent | docksy-sre | An SRE subagent for investigations |
| Hook | PreToolUse | Always asks before delete_app, delete_server, restore_backup |
Skills trigger on their own when they're relevant. Just talk to Claude.
Or: MCP server only
For Claude Code without the plugin:
$ claude mcp add docksy --env DOCKSY_URL=https://docksy.example.com --env DOCKSY_TOKEN=dsk_... -- npx -y @crovenai/docksy-mcp
For Claude Desktop, or any MCP client that uses a JSON config:
{
"mcpServers": {
"docksy": {
"command": "npx",
"args": ["-y", "@crovenai/docksy-mcp"],
"env": { "DOCKSY_URL": "https://docksy.example.com", "DOCKSY_TOKEN": "dsk_..." }
}
}
}
With the Docksy CLI installed, docksy mcp runs the same server in-process using your CLI login. For clients that prefer HTTP, docksy-mcp --http serves streamable HTTP on 127.0.0.1 only.
Tool reference
Read (always safe)
| Tool | Purpose |
|---|---|
get_fleet_overview | All servers, apps and firing alerts at a glance |
list_servers | Servers with status and liveness |
get_server | One server: specs, agent, provisioning state |
get_server_metrics | CPU/memory/disk/network over a range, with ASCII sparklines and current/avg/max |
list_containers | Containers on a server, with CPU/memory and restarts |
list_apps | Apps, optionally filtered by server |
get_app | One app: source, build, domains, status |
list_deployments | Recent deployments for an app |
get_deployment_logs | The build/deploy log of a deployment |
get_app_logs | Runtime container logs (tail) |
diagnose | Deterministic health report for a server or app: findings, evidence, suggested fix tools |
list_alerts | Firing or resolved alerts |
list_alert_rules | Alert rules, including the defaults |
list_uptime_checks | Uptime checks with 24h uptime and latency |
list_templates | One-click templates (databases and services) |
list_backups | Backup jobs and their recent runs |
Write (Claude asks before using these)
| Tool | Purpose |
|---|---|
create_app | Create an app from a repo, an image or a template |
update_app | Change domains, port, branch, healthcheck, auto-deploy… |
deploy_app | Start a zero-downtime deployment |
rollback_app | Redeploy a previous successful image |
restart_app · stop_app · start_app | Container lifecycle |
set_env_vars | Set or replace environment variables |
create_server | Register a server |
provision_server | Install Docker, the proxy and the agent |
create_alert_rule | Add an alert rule |
ack_alert | Acknowledge a firing alert |
create_uptime_check | Monitor a URL |
create_backup | Schedule backups for a database app |
run_backup | Run a backup now |
Destructive (require confirm: true)
| Tool | Purpose |
|---|---|
delete_app | Remove an app and its containers (volumes kept unless asked) |
delete_server | Remove a server from Docksy (refused while it still has apps) |
restore_backup | Overwrite a database from a backup run |
Also provided: resources docksy://overview and docksy://servers/{id}/metrics, and prompts diagnose_server, deploy_new_app and incident_response.
Safety model
- Token scope: a read token can't change anything, server-side.
- Read-only mode:
DOCKSY_READONLY=1hides every write tool from Claude. - Destructive guard: the three destructive tools refuse to run without
confirm: true. - Plugin hook: a
PreToolUsehook returns"ask"for those tools, so you always see a permission prompt labelled[plugin:docksy], even in auto mode. - Audit trail: every write is recorded in Docksy's activity log under the token's name.
Things to ask
deploy this repo to my prod server why is prod-1 at 95% memory? the api is returning 502s, help roll back web to yesterday's version add postgres for the api with verified daily backups set up my new hetzner box at 203.0.113.7 dockerize this repo alert me on slack when disk goes over 80% write a postmortem for this morning's outage