Dora NodaAWS says its new deploy-on-aws agent plugin turns "hours of reading documentation, comparing services, and writing infrastructure code" into "less than 10 minutes." That's a real, useful claim — and also a tell. Ten minutes is still five separate steps, three separate MCP servers, and a mandatory confirmation gate before anything actually ships. The interesting question isn't whether that's faster than doing it by hand. It's why deploying an app to AWS needs five steps at all, and what happens to that count on a platform that never had four of the problems those steps exist to solve.
What deploy-on-aws actually does
AWS Labs published deploy-on-aws on February 17, 2026, as the flagship plugin in its open-source awslabs/agent-plugins repo (Apache-2.0), installable straight into Claude Code and Cursor the same day Cursor shipped its own plugin-marketplace support. Point an agent at a repo and tell it to deploy, and it runs a fixed five-step workflow:
- Analyze the codebase for frameworks, databases, and dependencies.
- Recommend AWS services to run it on, with rationale.
- Estimate monthly cost using real-time pricing data.
- Generate infrastructure-as-code — CDK or CloudFormation.
- Deploy, only after the developer explicitly confirms.
Three purpose-built MCP servers do the heavy lifting behind those steps: an AWS Knowledge server for documentation and architectural best practice, an AWS Pricing server for live cost data, and an AWS IaC server for CDK/CloudFormation generation guidance. AWS's own before/after example — "hours of manual service comparison and IaC-writing" collapsing to "under 10 minutes" — is the headline the plugin shipped to earn.
That's a legitimate engineering win. It's also a workflow built for a very specific kind of hard problem: picking the right shape out of AWS's own catalog of roughly 200 services. Take that ambiguity away, and most of the five steps stop being steps at all.
Why "recommend" is a real, hard step on AWS
To see why, look at what the recommend step actually has to adjudicate for something as ordinary as a small Node/Express API with a Postgres database. AWS Lambda charges per millisecond of execution and scales to zero, but a Lambda function backing a REST API needs API Gateway in front of it and cold starts to reason about. App Runner is fully managed, container-in-container-out, billed per second of provisioned vCPU/memory — the closest thing AWS has to "just run my Dockerfile," but with less control over networking than Fargate. Fargate gives you real ECS task definitions and VPC placement, at the cost of writing and maintaining those task definitions yourself. None of those three is wrong. Picking between them — and then deciding whether the database is RDS, Aurora Serverless, or something else — is the actual, non-trivial judgment call the analyze-and-recommend steps exist to make, repeated fresh for every repo, because the menu never gets smaller.
Which steps actually depend on not knowing the answer yet
Map each step against a git-push platform that only ever has one deploy shape — a repo goes in, an HTTPS service on owned hardware comes out — and the picture changes fast:
| AWS step | Ambiguity it exists to resolve | Exists on a fixed-shape PaaS? | Verdict |
|---|---|---|---|
| Analyze | Which of dozens of AWS compute/storage/networking primitives fits this repo? | No — the target is always "a container running this repo," never a choice between EC2, Lambda, Fargate, App Runner, or a dozen other options | Collapses to zero |
| Recommend | Given the analysis, which specific services, and why? | No — there's no catalog to choose from, so there's nothing to recommend | Collapses to zero |
| Estimate | What will this specific service combination cost, computed against live pricing across however many line items got recommended? | Narrows, doesn't vanish — one plan has one price; a tenant can read it off a pricing page instead of running a multi-service cost model | Shrinks to a lookup |
| Generate | Turn the recommended services into CDK or CloudFormation the developer now owns and has to maintain | No — there's no IaC to generate because there's no per-deploy infrastructure topology to describe; the platform's control plane already is the infrastructure definition | Collapses to zero |
| Deploy | Actually provision it and make it reachable | Yes — provisioning compute, wiring a route, issuing a certificate, and confirming health is real, non-optional work on every platform, including this one | Stays hard |
Three of five steps exist only because AWS is a menu, not a platform with an opinion. A git-push PaaS's whole pitch is refusing to be a menu — "deploy this" has exactly one answer before the agent even starts working, so there's no analysis to run and no recommendation to justify. The Node/Express-and-Postgres example above never happens: there's no App Runner vs. Fargate vs. Lambda call to make, because the platform only ever runs one kind of thing — a container built from the repo, on a node the fleet already owns.
The estimate step follows the same logic without fully vanishing. On AWS, "estimate" means composing a price across whatever combination of compute, database, and networking services the recommend step just picked — a small pricing model with several moving parts, recomputed fresh every time. On a platform with one plan structure, there's nothing to compose: the number is whatever the chosen instance plan costs per month, full stop. It's a lookup, not a model — smaller work, not zero work. Only the last step — actually standing up the service — carries over as genuinely hard, on any platform, agent-driven or not.
The one step that doesn't collapse — and bex doesn't have it either
That's worth being honest about, because it cuts against a convenient version of this argument. bex's own MCP server has been live for months — thirteen tools, covering service lifecycle, scaling, log queries, metrics, and Postgres management — and every one of those thirteen tools operates on a service that already exists. There is no deploy tool. Standing up a brand-new service from a git repo through the MCP surface is explicitly marked "🔜 planned" on bex's own roadmap, gated on wiring push-to-deploy/wake-on-request from git hosting and getting in-cluster builds working end to end, so a build-from-git image is actually pullable by cluster nodes without a human kicking off the pipeline by hand first.
So the honest comparison isn't "AWS needs five steps, bex needs zero." It's "AWS needs five steps because the ambiguity is real at hyperscaler scale, and a fixed-shape platform gets four of those five steps for free by construction — but the fifth one, the actual deploy, is exactly as unsolved on the platform not doing four steps of scaffolding around it, and being younger about it is not the same as being finished." A single deploy shape removes the decision. It doesn't remove the work.
What the "recommend" step is actually for
There's a second reason those four steps exist beyond genuine technical ambiguity, and analyst Mitch Ashley at Futurum named it directly: the recommend step is also the moment a hyperscaler gets to shape a developer's default service choice at exactly the point they're committing infrastructure. Every plugin that provisions a specific, sticky AWS service — deploy-on-aws today, aws-transform and databases-on-aws already sitting in the same plugin repo — extends the switching-cost window a little further past that moment. Ashley's framing was blunt: a vendor building plugin depth without plugin breadth is building "a richer honeypot," and plugin-driven deployments risk skipping the procurement and governance review a manually-chosen AWS service would have gone through.
AWS's own response to that critique, three months later, tells you the five steps were never actually in question. In May 2026, AWS shipped Agent Toolkit for AWS as the designated successor to agent-plugins — adding IAM condition keys that distinguish an agent's actions from a human's in policy, plus CloudWatch and CloudTrail visibility into what an agent actually did. That's a real, needed fix for a real gap. It's also a fix that wraps more governance around the same five-step scaffold, not a rebuild that asks whether steps 1, 2, and 4 needed to exist at all. They still do, because for AWS the point is choice — a bigger menu is the product. A platform that never had a menu to steer someone through doesn't need a governance layer around the recommend step, because there's no recommend step for a hyperscaler's incentives to lean on in the first place.
Ten minutes is a real number, for a problem you don't have to have
None of this makes deploy-on-aws a bad tool — for the job it's actually solving, five steps and three MCP servers is a reasonable shape, and going from hours to minutes for a genuinely ambiguous decision is worth shipping. But "an agent can deploy your app now" is doing a lot of work to paper over how much of that ten minutes is AWS agentically re-deriving a decision a fixed-shape platform never has to ask in the first place. The honest scorecard is three steps gone, one step shrunk to a lookup, and one step — the actual deploy — that's real everywhere, bex included, and worth building rather than claiming.
bex is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP server that already skips the steps a fixed-shape platform never needed. Star the repo on GitHub or point an agent at /mcp today.
