Comparison
Letting an AI agent deploy: Phelix vs raw SSH
The fastest way to let a coding agent deploy is to hand it an SSH key and a shell. It is also the way with no plan, no approval, and no limit. Phelix gives the agent a bounded, plan-bound, approval-gated path to the same deploy instead.
Released Phelix hosts: Linux and macOS. Builds Go and Rust with your host toolchain.
Where each fits
Both let an agent ship. They differ in what the agent can do when it does.
Reach for raw SSH or shell when you want maximum flexibility and trust the agent (and its whole prompt path) with full access to the host: it can run anything, in any order, with no setup. That flexibility is exactly the risk: a wrong or injected command executes immediately, with no plan to review and nothing to approve.
Reach for Phelix when you want an agent to deploy without granting a shell. The agent proposes an immutable plan and requests its apply; execution is denied by default and, once enabled, still waits for a human to approve that exact plan. Start with letting AI agents deploy.
This compares two approaches, not a specific SSH product; your own setup may add guardrails. Phelix behavior reflects the MCP adapter as of September 2026. Verify current behavior before you decide.
Side by side
A neutral comparison for letting an agent deploy.
| Capability | Phelix | Raw SSH / shell |
|---|---|---|
| Access scope | A fixed set of plan and inspect tools over local stdio | Whatever the shell can do as that user |
| How actions happen | Two steps: create an immutable, content-addressed plan, then apply it | Arbitrary commands, executed immediately |
| Approval | Plan-bound human approval, bound to the plan id and content hash | None; the agent acts directly |
| Default posture | Apply denied by default (legacy_local); opt-in per host | Full access the moment credentials are shared |
| Caller identity | Unauthenticated local "mcp" actor, never the CLI's trust | Your SSH user, with your privileges |
| Audit trail | Versioned machine envelope with operation ids; secrets redacted | Shell history at best |
| Rollback | Native rollback to a retained version, as a plan | Whatever the agent scripted |
| Blast radius | Bounded to Phelix operations; no shell or filesystem tools | Full host access |
What the boundary buys you
The parts a shell leaves to trust.
Over MCP, an agent gets a fixed set of read and plan tools: no shell, no filesystem, no single-step deploy. A change is a content-addressed plan, and applying it clears the same fail-closed execution-authorization boundary as the CLI, with approvals bound to the plan's id and hash. Every call returns a versioned envelope with secrets redacted, so you get an audit trail instead of shell history.
Where raw SSH still fits
Full access has its place.
For one-off operations outside Phelix's deploy pipeline (ad hoc debugging, host administration, anything that is not a build, deploy, or rollback), a shell is the right tool, and Phelix does not try to replace it. The point is not to ban SSH; it is to stop making a shell the only way an agent can deploy.
One binary between git push and production.
Install the CLI, verify the host, and follow the quick start to build your first application.