Dora NodaHeroku has been in sustaining mode since February, and every vendor with a migration story is now racing to own your exit. The most telling pitch lands on September 24, when Qovery runs a live webinar promising "Heroku to AWS in one command, with an agent doing the work." An agent drives a real migration end to end while two humans narrate what it provisions underneath — including, the agenda promises, where it needs a human and where it doesn't.
That framing is the whole story of infrastructure in 2026: the migration itself is becoming a commodity an agent can execute, so the durable decision is no longer how you move but which meter you land on. The webinar's own agenda promises all four of the usual escapes from Heroku — and the structure of the exit industry says every one of them lands on metered cloud infrastructure. None of them lands on hardware you own.
TL;DR verdict box. What the agent automates well: inventorying your Heroku estate, translating configs and buildpacks into Terraform, executing the provisioning checklist, and running verification probes. What still needs a human: data-cutover timing, rollback authority, and the bill on the other side. And that bill, for a typical small-team workload (a few web/worker dynos plus managed Postgres and Redis), looks roughly like this per month: stay on Heroku ~$215, move to AWS behind an agent-driven platform ~$700–1,300 (metered primitives plus a $299+/mo control plane), or self-host the same containers on a flat-rate dedicated box ~€100–200 with no per-dyno meter. The rest of this post is the evidence behind each number.
The one-command pitch, decoded
Qovery's September 24 session — 60 minutes, talk plus live migration with Q&A throughout, led by CEO Romaric Philogene and Staff Cloud Architect Guillaume Da Silva — is aimed at "engineers and engineering leads still on Heroku who want their own AWS account without giving up the workflow they have today." The pitch starts from an honest diagnosis: moving off Heroku is rarely a technical problem. Heroku gives you a way of working — push, review app, add-on, rollback — while AWS gives you primitives. Teams budget for moving the workloads, then lose what the webinar page calls "six weeks rebuilding the workflow around them."
The agent-driven playbook collapses those six weeks into five steps, and Qovery's version is unusually inspectable because the core of it is open source. The qovery-migration-ai-agent repository shows the runbook an agent executes:
- Read-only inventory. The agent connects to the Heroku API in read-only mode and fetches every app's configuration: dyno formation, environment variables, buildpacks, add-ons, and domains.
- Config translation. An LLM (Claude via AWS Bedrock in Qovery's implementation) converts Heroku concepts into target-native equivalents — buildpacks to container builds, add-ons to managed services or operators, dyno sizes to CPU/RAM requests.
- Terraform generation. The translated config becomes versioned infrastructure-as-code (Qovery Terraform provider configurations), so the migration output is reviewable, repeatable, and not a black box.
- Provisioning on your own account. The agent applies the plan against your own AWS account — VPC, EKS cluster, databases — so you hold the cloud bill and the keys, not the vendor.
- Deploy and verify. Apps deploy to the new target, and verification probes confirm each service answers before DNS or traffic moves.
This is not vaporware: Qovery published a case study of its DevOps AI Migration Agent moving 37 apps from Heroku to AWS in under 2 hours, starting from a read-only scan of all 37 Heroku apps and ending in generated Terraform. The "one command" framing compresses real work into a slogan — though the CLI does expose a literal migrate --from heroku --to aws verb — but the underlying runbook is real, and it is the same runbook every agent-driven migration vendor converges on. Inventory, translate, generate, provision, verify. The differentiator is never the five steps; it is what the agent is governed by while running them (Qovery routes agent operations through RBAC, budgets, and audit logging via its MCP server for infrastructure) and which destination the vendor is paid to land you on.
What the agent does well vs what still needs a human
The most honest segment of the webinar agenda is the last one: "Where a human is still required: the decisions you should not hand to an agent." Credit where due — a vendor promising one-command migration that dedicates stage time to what the command cannot decide is telling the truth about the technology. Here is that table, generalized beyond any one vendor:
| The agent does well | Still needs a human |
|---|---|
| Inventorying dynos, add-ons, env vars, and build settings via read-only API scans | Data-cutover timing — when the primary database actually moves, how long replication lags, and what "done" means for a stateful cutover |
| Translating Heroku configs into Terraform / Kubernetes manifests mechanically | Rollback authority — who can declare the migration failed at 2am and send traffic back, and what the rollback runbook is |
| Executing the provisioning checklist without skipping steps | DNS and traffic-shift calls — canary percentages, TTL games, and the moment of no return |
| Running verification probes (health checks, smoke tests, parity diffs) after deploy | The bill on the other side — approving a metered architecture whose monthly cost nobody has paid yet |
| Porting environment variables and build settings verbatim | Secrets rotation and compliance sign-off — what crossed a trust boundary during the move |
Notice the pattern: the agent is excellent at everything deterministic and reversible — reading, translating, generating, checking. Humans keep everything irreversible or judgment-shaped — cutting over a primary database, owning a rollback, signing a new cost structure. The webinar's "four usual escapes" framing promises to walk through what each exit buys and breaks; whatever the four turn out to be, the honest version of that slide always has the same bottom row, which is the next section.
The bill on the other side
Nobody applauds during a live migration demo and then asks about month thirteen. So let's do the math the webinar won't center, for a typical small-team workload: two web dynos plus one worker, a standard managed Postgres, and a small managed Redis. All figures are list-price order-of-magnitude as of mid-2026 — verify current pricing before budgeting — but the shape of the comparison is stable.
Option A: stay on Heroku. A Standard-2X dyno (1 GB RAM) lists at $50/month; three of them cost $150. Add Standard-0 Postgres at roughly $50/month and a small Redis at roughly $15–30/month. Total: roughly $215–230/month. Scale from one dyno to five and the compute line alone runs $50 to $250 before data; step up to Performance-M ($250/month per dyno) and a five-dyno fleet crosses $1,250/month for compute alone. Heroku's meter is simple and famously steep at the top end — which is exactly why the exit industry exists.
Option B: AWS via an agent-driven platform. The metered primitives for the same workload look roughly like this: EKS control plane ~$73/month, two general-purpose nodes ~$140/month, RDS Postgres (db.t3.medium class) ~$60–70/month, ElastiCache ~$30/month, plus load balancer, NAT, and data transfer ~$40–60/month. That is ~$350–450/month in AWS charges before the platform layer. Then the control plane: Qovery's entry tier lists at $299/month per managed cluster, with Team at $899/month.
Total: roughly $700–1,300/month depending on tier — two to six times the Heroku bill it replaces, in exchange for your own AWS account, Kubernetes-native primitives, and a governed agent interface (MCP server, deploy skills, audit trails) for everything after the migration. The migration is one command; the meter is forever.
Option C: self-host on owned hardware. The same containerized workload fits comfortably on one Hetzner-class dedicated box (8 cores, 64 GB RAM, NVMe) at roughly €50–100/month — Hetzner adjusted list prices in June 2026, so treat this as order-of-magnitude — with Postgres and Redis self-operated on the same machine or a second box. Total: roughly €100–200/month flat, with no per-dyno, per-vCPU-hour, or per-gigabyte-transferred meter. Scaling from one dyno-equivalent to five changes nothing on the invoice until you outgrow the box.
| Stay on Heroku | AWS via agent platform | Self-hosted dedicated | |
|---|---|---|---|
| Typical workload (3 dynos + Postgres + Redis) | ~$215/mo | ~$700–1,300/mo | ~€100–200/mo |
| At 5 dyno-equivalents | ~$330+/mo (Standard-2X) | ~$800–1,500/mo | ~€100–200/mo (same box) |
| At Performance-M class | ~$1,500+/mo | ~$1,000–2,000/mo | new box, still flat |
| What scales the bill | dyno count × tier | metered primitives + platform tier | adding a whole box |
Sensitivity check: the AWS-agent path only wins on cost if your workload is bursty enough that autoscaling-to-near-zero beats a flat box, or if you genuinely need hyperscaler-only services. The self-hosted path only wins if someone operates the fleet — which is the real objection, and the subject of the next section. Neither caveat fits in a webinar chat window, which is why the bill deserves its own table rather than a footnote.
The exit no webinar sells
Here is the structural observation the September 24 pitch accidentally proves: every vendor's one-command exit lands on metered infrastructure, because vendors get paid on meters — a percentage of cloud spend, a per-cluster platform fee, or both. Nobody sells a webinar ticket, a platform tier, or a professional-services package whose punchline is "and then your infrastructure bill drops to one flat box." The self-hosted off-ramp — same app, Hetzner boxes, no per-dyno meter — is the migration path nobody meters, so nobody markets it.
That does not make it free. Self-hosting earns its flat bill by moving work, not eliminating it. Concretely, the off-ramp requires a git-push PaaS running on infrastructure you own:
- Declarative fleet lifecycle — Cluster API (or equivalent) provisioning and reconciling your machines, so adding a second box is a manifest change, not a weekend.
- The Heroku workflow, rebuilt — git-push deploys, preview environments, one-command rollbacks, TLS and custom domains, log aggregation.
- Data services as operators — Postgres and Redis run by mature Kubernetes operators with backups, failover, and point-in-time recovery you have actually tested.
- An agent interface with guardrails — the same governed deploy/observe tooling the webinar world sells (MCP server, RBAC, audit logs), but pointed at your own fleet instead of someone's meter.
The when-to-choose checklist is short. Self-host when your workload is steady-state web/worker/container shapes, your team can own (or buy support for) one small fleet, and your Heroku or AWS bill already exceeds a few hundred dollars a month with no hyperscaler-only dependency justifying it. Stay metered when you need autoscaling to zero, regulated-region coverage you cannot staff, or managed services (ML platforms, global edge, compliance regimes) whose operational cost genuinely exceeds their meter. Most teams reading a Heroku-exit webinar are squarely in the first camp and being sold the second camp's answer.
The migration is table stakes; the meter is the decision
Step back and the September 24 webinar is a milestone worth marking: migration playbooks — inventory, translate, generate, provision, verify — are becoming agent-executed commodities with open-source reference implementations and published case studies. Within a year, "one command, the agent does the work" will be table stakes for every exit vendor, and arguing about whose agent writes better Terraform will feel like arguing about whose installer has a nicer progress bar.
What will not commoditize is the destination. An agent can move your workloads in an afternoon; only you can decide which meter they land on for the next three years. Qovery's webinar deserves credit for putting "decisions you should not hand to an agent" on the agenda — and the biggest such decision is the bill on the other side. Before you register, price all three exits for your actual dyno formation, including month thirteen. The cheapest migration is the one whose destination you chose on purpose.
Running the numbers on your own Heroku exit? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
