Skip to content

Agents

Let an AI agent run your infrastructure

Nixploy speaks MCP. Point Claude Code, Cursor or Codex at your panel and it can deploy, read the logs, work out why something broke and roll it back — without you opening a terminal.

  • MCP tools

    42 annotated

  • Auth

    Scoped API keys

  • Dispatch

    The panel's routers

  • Trail

    Every mutation audited

01

Deploy

One prompt. Three tool calls. A URL with a certificate.

mcp · deploy

youDeploy the api service to staging and put it on a domain.

› list_projectsacme · staging, production

› deploy_and_wait#d9f3 · build 48s · rollout 11s · 1/1 tasks · done

› add_domainapi-staging.acme.dev · certificate issued

agentDeployed 4f2a9c1 to staging in 59 s. One replica healthy. https://api-staging.acme.dev is live with a Let's Encrypt certificate.

02

Diagnose

The events, the logs and the resolved environment, read before anything is written — and the write waits for a yes.

mcp · diagnose

youapi-staging is returning 500s. What happened?

› get_service_eventsrestart ×4 · task_failed exit 1 · deploy_finished 6m ago

› get_service_logsError: connect ECONNREFUSED — DATABASE_URL undefined

› get_resolved_env12 variables · DATABASE_URL not set at any level

agentThe deploy six minutes ago dropped DATABASE_URL — it was set on the old environment, not the project. The container has restarted four times. Want me to set it from the staging database and redeploy?

youYes.

› set_envDATABASE_URL written (encrypted)

› deploy_and_wait#e104 · done · 1/1 tasks · healthy

03

Roll back

The failure explained in its own step, the pinned images listed, the previous build serving again.

mcp · roll back

youThe last deploy broke production. Fix it.

› explain_last_failurefailingStep: converge — new tasks never became healthy

› list_rollback_points3 points · newest: 4f2a9c1, 2h ago, green

› rollback_deploymentrolled back to 4f2a9c1 · 1/1 tasks · healthy

agentRolled back to 4f2a9c1. The failing deploy never converged — its health check timed out on /ready. Production is serving the previous build again.

Why this is safe to hand an agent

The MCP tools are not a second API. Every one of them dispatches through the same tRPC routers the panel uses, so the organization scope, the capability checks and the audit trail apply identically — an agent holding a read-only API key cannot deploy, and every mutation it makes is a row in the audit log with the key that made it.

Annotated tools

All 42 carry readOnlyHint, destructiveHint and idempotentHint, declared by hand with a test that fails the build on a missing entry — so an agent knows what is safe to call while it is still looking around.

Scoped keys

An API key is read, deploy, write or full, intersected with its owner's own capabilities, bound to one organization, and expiring by default.

One call, not a polling loop

deploy_and_wait blocks for the real outcome; explain_last_failure and get_service_runtime_summary answer in one round trip what would otherwise be five.

It reads the docs too

/llms.txt, /agents.md and a .md twin of every docs page, so an agent can look something up instead of guessing.

Connect it

Install Nixploy, mint an API key in Settings → Profile, and copy the config the MCP setup card renders for your client — it already has your instance's own address filled in.

Full reference in the MCP guide; the REST surface behind it is at the API catalog.

install.sh
curl -fsSL https://raw.githubusercontent.com/bablilayoub/nixploy/main/install.sh | sudo bash
claude_desktop_config.json
1{ 2 "mcpServers": { 3 "nixploy": { 4 "type": "http", 5 "url": "https://panel.example.com/api/mcp", 6 "headers": { "x-api-key": "nxp_…" } 7 } 8 } 9}

Rent the box. Keep the rest.

One command, three services, and the first account is yours.