Dora NodaA serious competitor just conceded the two things that matter most about AI agents and infrastructure. First, agents deploy now — not in a roadmap slide, but as the expected interface, with Qovery running a live webinar on September 24 titled "Heroku to AWS in one command, with an agent doing the work." Second, the product is not the connection between the agent and the infrastructure. It is the governance around it. As CEO Romaric Philogene put it in Qovery's June 24 infrastructure-MCP writeup: the hard part is not access, it is governance.
That sentence is worth sitting with, because it validates both halves of the self-hosted agent-ops playbook at once. If agents are going to deploy, provision, and spin up environments through one protocol, then RBAC, budget limits, and a full audit trail stop being enterprise checklist items and become the minimum viable product — scoped credentials and spend ceilings as first-class tool properties, not documentation warnings. And if agent-driven migration is the 2026 expectation, the interesting question is no longer whether an agent does your migration. It is where the agent lands you.
Governance, not access: the three-item checklist
Qovery's argument starts from an honest observation: giving an agent power is trivially easy. Hand it an admin cloud token and it can do anything. That is also, in the post's words, how you get "a $500M surprise bill or a security incident" — and the post is explicit that this is not hypothetical.
A naive MCP setup runs the agent on a developer's machine with that developer's personal credentials. That works for one person experimenting. It collapses the moment you have multiple agents, multiple people, and a production environment.
The fix is three properties, enforced on every operation:
| Property | What it means | What breaks without it |
|---|---|---|
| RBAC | The platform team defines who — and which agent — can do what, where. The agent operates strictly inside those boundaries. | Any prompt can touch production. One hallucinated command has the blast radius of your admin credentials. |
| Budget and policy controls | Per-environment cost caps, auto-cleanup, allowed regions. The agent cannot exceed them. | A runaway agent provisions GPU instances over a weekend and you find out from the invoice. |
| Full audit trail | Every agent-initiated action is logged and attributed: who prompted it, what the agent did, what changed, when. Exportable to your SIEM. | An incident with no answer to "who did what" — undebuggable, unauditable, uncertifiable. |
This is the difference between a demo and a platform, and it is notable that the framing comes from a vendor rather than a skeptic. Speed is easy. Governance is the hard part — and it is what lets you actually let agents loose in production. The checklist also matches the emerging industry consensus: 2026 MCP security guidance converges on the same controls — RBAC tied to your identity provider, least-privilege per-tool scoping, ephemeral credentials for server-to-upstream calls, and a structured, queryable log of every agent action.
MCP server vs raw API vs CLI vs raw credentials
The writeup's most useful artifact is its explicit comparison of the interfaces an agent can use to touch infrastructure. It is worth reproducing in full, because most teams only ever evaluate two of the four rows:
| Approach | Agent-friendly? | Governed? | Best for |
|---|---|---|---|
| Raw cloud credentials | Yes | No — full blast radius | Never, in production |
| Hand-written CLI scripts | Partially — brittle, per-tool | Only what you script | Single-tool automation |
| REST API directly | Partially — agent must learn each endpoint | If the API enforces it | Custom integrations |
| MCP server | Yes — one protocol, self-describing tools | Yes, when built for it | Multi-agent, multi-tool, production |
Three things stand out. First, the MCP server wins on two independent axes at once: it is self-describing, so the agent discovers available tools automatically instead of needing per-endpoint prompting, and it is standardized, so one protocol serves Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and the twenty-plus other agents Qovery names. No custom integration code per agent.
Second, the governance column carries the real verdict: policy must be enforced server-side, at the boundary — never trusted to the agent. An MCP server that merely forwards the agent's intent to an admin credential is row one with extra steps. The protocol only earns the "production" label when the server itself holds the RBAC check, the budget check, and the audit write.
Third, notice what the table implies for API design generally. "REST API directly" is marked governed only if the API enforces it — which is exactly the standard a self-hosted platform's own API has to meet before any agent talks to it. The agent interface is only as safe as the enforcement behind it, whatever protocol it speaks.
Blueprints: policy that ships with the deploy
A month after the MCP writeup, Philogene published the follow-through: Qovery Blueprints, which carry access rules (who can deploy a blueprint) and cost rules (time to live, auto start and stop) as part of the deployment itself — not as a policy someone has to remember to enforce. The platform already knows who is requesting what, on which environment, on which cloud, so the guardrails ride along with the artifact instead of living in a wiki page.
This is the concrete worked example the "governance, not access" thesis needed. Consider what it replaces: the classic platform-team dilemma of hand-building every database request versus handing out raw infrastructure access. Blueprints split the difference by making the safe path the pre-approved path — an agent or developer can self-serve anything a blueprint allows, and nothing it does not, with cost expiry built into the grant. A preview environment that auto-stops after idle hours cannot become a forgotten $400-a-month line item, because the TTL was never a separate step to forget.
The transferable lesson for any deploy-from-chat roadmap is architectural: governance properties belong in the tool definition, not the tool documentation. A spend ceiling the agent is asked to respect is a suggestion. A spend ceiling the server enforces before executing the tool call is a control. Teams building self-hosted agent interfaces should steal this shape wholesale — scoped credentials minted per tool invocation, budget checks evaluated server-side, every call attributed — because it is the only shape that survives contact with a production incident review.
Agent-driven migration is table stakes — the question is where you land
The September 24 webinar makes the second concession explicit. "Heroku to AWS in one command, with an agent doing the work" is a talk plus live migration aimed at engineers still on Heroku who want their own AWS account without giving up their workflow. The pitch assumes something that would have sounded absurd two years ago: of course an agent does the migration. The demo is not that it can — it is watching it happen live.
There is already a case study behind the claim. Qovery's published DevOps AI Migration Agent work describes migrating 37 Heroku applications to AWS in under two hours: the agent connects to the Heroku account in read-only mode, fetches every app's configuration including environment variables and build settings, converts them via Claude into Terraform configurations for Qovery's provider, and the team reviews and executes. The migration agent itself is open source. Read-only source access, generated infrastructure-as-code, human review before apply — that pipeline shape is exactly right, and it is now the baseline every migration story will be measured against.
So grant the premise: the agent does the migration in one command. The question that decides your next three years of bills is where it lands you.
Qovery is a BYOC platform — it runs inside your own AWS, GCP, Azure, or Scaleway account, or on your existing Kubernetes cluster — and its Business tier starts at $2,999 a month billed annually for up to 20 users and 3 clusters, per the company's own pricing writing, with your cloud bill separate and staying in your name. That is a defensible trade: committed-use discounts keep applying, there is no PaaS markup on compute, and the platform fee buys governed self-service.
But the destination is still a meter. Every gigabyte, every GPU hour, every gigabyte-hour of provisioned database storage resumes ticking the moment the migration confetti settles — on AWS list prices, in an account the agent filled for you in an afternoon.
Contrast that with the portable version of the same story: the agent speaks a Render-compatible API, and the landing zone is flat-cost machines you own. Same one-command agent UX, same governed tool calls — different bill. A Hetzner box does not know or care that an agent provisioned it; the twelfth deploy costs what the first cost, which is nothing beyond the machine. When the migration is free and instant, the only cost that compounds is the destination's meter, which makes "where does the agent put my app" the highest-leverage question in the whole demo.
What this validates for self-hosted deploy-from-chat
Strip out the vendor specifics and Qovery's summer of writing hands every self-hosted team a three-point build checklist, validated by a funded competitor rather than invented in a vacuum:
- Scoped credentials per tool invocation. The agent never holds ambient admin power. Each tool call carries exactly the permission it needs, minted for that call, the way Blueprints bind access rules to the deployment instead of the user.
- Spend ceilings enforced server-side. Cost caps, TTLs, and auto-stop are evaluated by the platform before execution, not requested of the agent in a system prompt. If the check lives anywhere the agent can talk its way around, it is documentation.
- An attributed audit log. Who prompted it, what the agent did, what changed, when — recorded by the server, exportable to your SIEM. The log is what turns "the agent did it" from an incident-review shrug into a queryable fact.
None of this requires a venture-backed platform to implement. It requires treating the agent as what it is: the most powerful and least predictable operator your infrastructure has ever had — one that deserves narrower credentials, harder spending limits, and better logging than any human you would hire. Qovery landing on "governance, not access" is the market telling self-hosters their instincts were right. The teams that build the governed version first, on machines they own, get the one-command agent UX and the flat bill. Everyone else gets the demo and the meter.
Qovery's MCP writeup and the September 24 live-migration webinar are worth reading in full — a competitor thinking clearly about agent governance sharpens everyone's roadmap. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agents as first-class operators. Star the repo on GitHub or deploy your first app today.
