Agents & MCP
Let AI coding agents deploy your Go and Rust apps
Hand the deploy to Claude Code or Codex without handing over the keys. Phelix ships a built-in MCP server that exposes the same build and deploy pipeline as the CLI, but an agent can only propose a plan and request its apply, and nothing runs until a human approves that exact plan.
Released Phelix hosts: Linux and macOS. Builds Go and Rust with your host toolchain.
Two deliberate steps, never one
An agent describes a deploy as an immutable plan, then asks to apply it. Those are two separate calls, by design.
phelix_plan_create only describes and persists a content-addressed plan: it never executes. phelix_plan_apply runs that plan, and only after it passes the full validation, authorization, and idempotency pipeline. There is no single-step deploy or rollback tool. The adapter is a transport only: no new engine, no embedded AI, no network listener. See the MCP adapter guide.
Denied by default
An unconfigured host refuses agent applies outright. You opt in, per host, and keep approval in the loop.
The MCP server authorizes as a distinct, unauthenticated local caller: actor type mcp, never the CLI. On the default legacy_local posture, reads and plan-create work but phelix_plan_apply is denied. To let an agent execute, the operator writes an enforced policy that allows the mcp caller, ideally with require_approval.
Approvals bind the plan id and its content hash, so an approval can never authorize a different plan, and a plan whose content changed no longer matches. Approve and revoke are human CLI actions, never MCP tools. The full model is in execution authorization.
Claude Code, Codex, or any MCP client
Local stdio, no network listener. Point your client at the phelix binary and it launches the server for you.
The server speaks MCP over JSON-RPC on stdio and inherits the launching user's OS permissions, the same trust boundary as running phelix yourself. Add it to Claude Code with one command, or to Codex with a short config.toml block. Every tool returns the same versioned machine envelope the CLI does, with secrets redacted.
Setup for both clients, the full tool list, and the result contract are in the MCP adapter guide.
The agent proposes; you authorize
Every unit of agent work is tracked, and nothing deploys that a human did not sign off.
Agent execution sessions record one unit of work (create, checkpoint, complete or fail) and reuse the exact CLI logic. They are tracking only: linking a plan to a session never authorizes it, and phelix_plan_apply remains the single execution path behind the unchanged authorization boundary. The model is in agent execution sessions.
Watch the same flow play out on the homepage MCP section, or weigh it against the alternative in letting an agent deploy: Phelix vs raw SSH.
Questions about agent deploys
The short version of the boundary, for the questions people ask first.
- Can an AI agent deploy to production on its own?
- No. On a host with no authorization configured, Phelix denies agent apply by default. To let an agent apply at all, the operator opts in with an enforced policy, and the recommended setup requires a human to approve each plan before it runs.
- Which agents and clients work with Phelix?
- Any MCP-compatible client over local stdio. Phelix is verified with Claude Code and Codex; you point the client at the phelix binary running mcp serve --stdio. The server opens no network port.
- What can an agent actually do over MCP?
- Read context and inspect state, create an immutable, content-addressed plan, and request its apply. There is no single-step deploy, no shell, and no filesystem tool: rebuild and rollback happen only through an approved plan, on the same pipeline the CLI uses.
One binary between git push and production.
Install the CLI, verify the host, and follow the quick start to build your first application.