The Protocol Is Free, the Control Plane Isn't: What Qovery's MCP-for-Infra Play Shares — and Keeps

Qovery wants your AI agent to deploy through its control plane. Its 2026 pitch — "Build with Claude Code, Deploy with Qovery" — splits the agent surface in two: an agent Skill that turns code into a running deployment, and an MCP server that manages everything after. The agent never pastes YAML into a dashboard. It calls tools, and the control plane enforces the rules.

That split is now a product category, not one vendor's feature. Coolify v4 ships an MCP server, Devopness sells "one MCP" for AI DevOps, and Openship compares MCP surfaces the way comparison pages used to compare git-push support. So the interesting question is no longer "does your PaaS have an MCP server?" It is: when the agent acts through a hosted vendor plane versus a self-hosted PaaS's own MCP server on machines you own, which parts of the story are open-protocol wins both sides share — and which are moat only one side keeps? The answer fits in one table, right here, before the marketing has a chance to blur it.

The rest of this post earns that table: what Qovery's two surfaces concretely do, the category evidence that this is bigger than one vendor, why each row lands where it does, what a self-hosted PaaS must actually build to match it, and when each side wins.

What "Build with Claude Code, Deploy with Qovery" concretely is​

Start with the mechanics, because the docs are unusually explicit about where each tool starts and stops. Qovery's MCP server is for managing existing infrastructure. To deploy a new application from a codebase with an agent, you install the Qovery Agent Skill instead.

The two complement each other by design: the skill deploys, the MCP server manages. That division is the single most important detail in the whole pitch, and it is worth understanding why the line falls there.

Deploying from code is a prompting problem. The agent needs repo context, framework detection, Dockerfile generation, environment wiring, and a first-push sequence — a guided workflow, not a tool call. The skill packages that workflow: one install command (curl -fsSL https://skill.qovery.com/install.sh | bash), eight skills following the Agent Skills open standard, which is why one install covers Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and 30+ other tools without per-client work.

Managing running infrastructure is a governance problem instead: restart this, scale that, read these logs, change that variable — discrete verbs over live state, each needing permission checks and an audit entry. That is what the MCP server exposes, one governed endpoint away.

Authentication follows the same governed shape. An agent connects with its own API token — or OAuth where the client supports it — and inherits the permissions of the role that token was issued under. Every MCP tool call and API operation lands in the console audit trail against the token that made it, which is what turns "an agent did something" from a mystery into an answerable question.

And when the MCP server is not available, Qovery's own skills degrade gracefully through documented fallback tiers: MCP tool first, then the qovery CLI command, then raw REST against the API. Three doors into the same governed building, in priority order.

Note what Qovery refuses to call this: a sandbox. A sandbox solves code execution — a safe place to run code. Qovery frames its product as orchestration: databases, networking, secrets, CI/CD, environments, and monitoring behind one API.

Agents need the full stack addressable, not just an isolated runtime. Strip the marketing and the claim is architectural: the unit the agent operates is the environment, and the control plane is the only thing standing between the agent's intent and your cloud bill.

It is a category now, not a feature​

Qovery is the most complete expression of MCP-for-infra, but the category shipped on multiple fronts in 2026, which is what makes the protocol-vs-moat question general rather than vendor-specific.

Coolify v4's headline differentiator is its MCP server for AI-driven deploys, riding a project with 55,000+ GitHub stars and 280+ supported services. Dokploy is the cautionary tale inside the same comparison: an official MCP server that mirrored every API endpoint as a tool — hundreds of tools burning tens of thousands of context tokens before the first question — against community rivals covering the same API with a dozen curated verbs. The lesson the whole category absorbed at once: vocabulary must be designed, not mirrored.

Devopness pitches "any cloud and any stack, one MCP" — deterministic API, opinionated, fully configurable, no cloud credentials in AI chats. Openship's migration guide now carries an MCP row the way older guides carried a git-push row, comparing read-only versus full-API versus write-plus-reauth surfaces across Coolify, Dokploy, Dokku, and itself. And behind all of them sits the hosted-engine end of the spectrum: runtimes that vault per-user OAuth and expose thousands of pre-built tools, where the catalog and the credential handling are the product.

Five vendors shipping the same shape in one year is a category forming. The protocol did that — MCP gave every platform the same tool-calling standard and the same 30+ clients on day one. What the protocol did not do is give anyone the governed thing behind the tools. That part each vendor still builds, and bills, itself.

Protocol wins versus moat, row by row​

Walk the table from the top and each row's verdict has a concrete reason.

Deploy-new and manage-existing are protocol wins at the interface, moats underneath. The Agent Skills open standard means Qovery writes the deploy workflow once and every client runs it; MCP means the manage verbs work identically from Claude Code or Cursor or Codex. A self-hosted PaaS gets that same interop free by speaking the same standards. But the standard carries the call, not the capability: "deploy my app" still bottoms out in Qovery's API on one side and your platform's API on the other. Interop is shared. The deploy path is owned, by whoever built it.

Auth is a split row. Transports are standard — Streamable HTTP, OAuth discovery, token headers — and any server can implement them. The permission model is not. Qovery's version (token inherits role RBAC, budgets enforced at the boundary, policy-as-code on upper tiers) is control-plane software with years of enterprise requirements baked in. The self-hosted answer (OAuth 2.1 with per-tool scopes like read / write / sensitive, so "list services" and "rewrite production env vars" are different grants) is equally real engineering, just owned by you. Nobody's protocol compliance grants them the other's governance.

Audit is pure moat. "Every call logged against the token" sounds like a checkbox until you need 30-day retention, per-agent attribution across a Jira-triggered environment that no longer exists, and an export your auditor accepts. The log is only as credible as the plane that writes it, and the plane that writes it is the thing you rent or run.

Cost shape is where the moat meters. Qovery's BYOC model is honest about the split — your account, your bill, Qovery sits above the infrastructure and never owns it — and agents genuinely don't consume seats. But agents consume deployment minutes and environments, which are namespace-scoped and metered while alive. An owned fleet has no such meters: environments are namespaces you create, deploy minutes are CPU time on hardware you bought. When agents initiate more infrastructure operations than humans, the metered surface is the platform cost. (Last month's cost teardown did the two-invoice math line by line — $299 to $2,099 of control-plane fee over identical hardware — so I won't redo it here; the shape is what matters for this argument.)

Who operates the plane is the moat stated plainly. Qovery Engine — the Rust deployment-orchestration layer over Terraform, Helm, and kubectl — is open source. The control plane, UI, RBAC, policy, audit, and the agent layer are proprietary SaaS, and the self-hosted control plane is an Enterprise option. That is a coherent business: the engine proves the provisioning is real Kubernetes work, while the governance is the rented product. The self-hosted wager inverts it: the control plane is the open-source product you run, and Cluster API plus GitOps is the operational price.

What a self-hosted PaaS must build to match it​

The honest reading of the table is that "add an MCP server" is maybe twenty percent of the work. The protocol hands you clients and transports. Everything a team actually evaluates — the reason Qovery can charge a platform fee — is the governed API underneath. Concretely, matching the hosted surface means building five things, in this order:

1. A governed deploy API first. The MCP tools and the skill are projections of an API that already knows how to provision environments, wire secrets, and roll back. Without it, tools are ungoverned verbs.
2. A permission model with per-agent identity. Tokens that inherit roles at minimum; scoped OAuth (read versus write versus sensitive) if you want least privilege instead of ambient authority. The homelab failure mode — one god-token the agent wields in full — is where every self-hosted MCP starts and must grow past.
3. An audit trail written by the plane. Per-call, per-token, retained, exportable. Agents multiply the number of actors; attribution is the feature.
4. Machine-readable state as context, not just verbs. An agent deciding whether to redeploy needs current deploy state, recent logs, and service health as readable context — MCP resources over the same authenticated session, under the same scopes. A deploy tool without readable state is a loaded verb with no nouns.
5. Environment lifecycle as a primitive. Namespaces the agent can create, preview, and destroy, with auto-stop and cost visibility. This is the unit the agent operates; if creating an environment is a ticket to a human, the agent story ends there.

What you do not need to rebuild is client interop. Speak MCP and the Agent Skills standard and Claude Code, Cursor, and Codex connect to your plane the same week they connected to Qovery's. That is the protocol win doing exactly what open standards are for: the clients are commoditized, so the competition moves to the governed thing behind them — which is precisely where owning your plane pays.

When each side wins​

Three cases each, conditioned on the variables that actually decide it: team size, ops appetite, and whether the fleet already exists.

Hosted MCP-for-infra wins when:

• The team has no fleet ops appetite. Two to six people, no platform engineer, no desire to manage Cluster API upgrades or Postgres HA. The honest comparison is not "platform fee versus free" but "platform fee versus the engineer you would have hired anyway" — and the fee wins for months or years.
• Multi-cloud or portable posture is needed this quarter. One API across AWS, GCP, Azure, Scaleway, and existing clusters today beats a portable-by-design fleet whose second provider is an integration you own. Roadmaps don't deploy apps.
• The governance surface is the requirement. Audit retention an auditor accepts, an SLA, policy-as-code, solution-engineer onboarding, a support channel from day one. If compliance or a launch date names these explicitly, renting them is cheaper than building them under deadline.

The self-hosted MCP server wins when:

• The fleet already exists. Hardware you bought, a cloud bill you already hold. Every month of platform fee on top is margin on an interface to infrastructure that's already yours — the interface a team touches daily is the last thing to rent.
• Agent velocity is high and rising. Agents don't consume seats but do consume deployment minutes and environments on a metered plane. When agents initiate more operations than humans, an unmetered namespace-per-environment model stops being an ideology and starts being arithmetic.
• Sovereignty is non-negotiable. Data plane, control plane, audit log, and credentials on metal you own, air-gapped if needed. BYOC keeps your data in your account but the governance — and the audit trail that proves it — in someone else's SaaS. Some teams can't sign that split.

The one-sentence test​

Qovery deserves credit for making its split legible: open engine, rented governance, honest BYOC copy, and an agent surface with documented tiers instead of a demo. MCP-for-infra as a category is better for its existence — the skill-deploys/MCP-manages division is now the shape to beat, and every self-hosted PaaS should steal it.

The test that resolves hosted versus self-hosted is equally simple: does your agent call an API you own? If the governed verbs, the permission model, the audit log, and the meters all live in infrastructure you already paid for, the protocol gives you the clients free and there is nothing left to rent. If they don't — no fleet, no ops appetite, a deadline — rent the plane that has them, ship, and revisit when the agent operations outnumber the human ones. At that point the deploy path your agents live on deserves to be yours.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents deploy through a Render-compatible API and an MCP server, not a second invoice. Star the repo on GitHub or deploy your first app today.