Heroku to AWS in One Command, With an Agent Doing the Work (Webinar Replay)
Replay and recap of our live session: an AI agent reads a Heroku Rails app and deploys the full stack to AWS through Qovery from one prompt. Chapters, timestamps, the four ways teams leave Heroku, and the steps a human should still own.
In our September 24 live session, Guillaume Da Silva, Staff Solutions Architect at Qovery, took a Rails app running on Heroku and moved it to AWS by typing one sentence into Claude Code: migrate my application to Qovery. The agent read the code, mapped every Heroku component to its equivalent, and deployed the whole stack to a Kubernetes cluster in his AWS account while we watched. Romaric Philogene, CEO and co-founder of Qovery, co-hosted and asked the questions Heroku users bring to us every week.
This page has the full replay, a chapter list, and the points worth keeping. Every section links to the exact moment in the video.
An agent can run the first three steps of a Heroku migration from one prompt. In the demo, Claude Code with the Qovery skills and MCP server turned a Rails app with web and worker dynos, Postgres, Redis and a scheduler into a running AWS environment.
Leaving Heroku means rebuilding a workflow. Git push deploys, review apps, add-ons, rollback and one-off dynos all need a replacement, and AWS has no service for some of them.
Build the platform layer before moving services. Teams that move services first rebuild the platform later under pressure.
Keep humans on approvals and the database. Let the agent plan and execute, have a person validate configuration, and run the Postgres migration by hand.
Heroku Postgres has no zero-downtime exit. Pick dump and restore, pg_dump in a maintenance window, or WAL shipping to S3, based on database size and how long you can stop the app.
Guillaume opened with the point that shapes the rest of the session. Teams pay Heroku for a workflow, and that workflow has five parts:
Git push deploys. Heroku detects your stack with buildpacks and ships it. No Dockerfile, no CI pipeline to write. Watch at 05:50
Review apps. Every pull request gets its own URL with a database, so you can test before production.
Add-ons. You ask for Postgres or Redis and Heroku runs it, updates included. In Guillaume's words: "it could be at 3 am, I don't care."
Rollback. A failed release goes back to the previous version (the application, not the data).
One-off dynos.heroku run opens a shell on a copy of your container for debugging, migrations and data fixes. Watch at 07:22
Leaving Heroku means rebuilding all five yourself (watch at 08:40). A git push becomes a GitHub Actions, GitLab CI or CircleCI pipeline. Buildpacks become Dockerfiles you maintain and patch for CVEs. Add-ons become databases you operate. Some pieces have no equivalent on AWS at all: no AWS service gives you a one-off dyno. As Guillaume put it, you move from a managed platform to a bunch of managed services, and orchestrating them becomes your job (watch at 10:59).
In February 2026, Heroku moved into sustaining engineering mode and stopped selling Enterprise contracts to new customers. Existing apps keep running, but the roadmap has mostly stopped, and teams that need Enterprise features have nowhere left to buy them. Many customers now want their infrastructure back under their own ownership.
Guillaume works on pre-sales and talks to Heroku users every day. These four limits come up the most:
The 30 second request timeout. Anything slower, like report generation or an AI call, fails with an H12 error. The limit is part of the architecture, so there is no setting to raise it. Watch at 11:35
Two regions. The default runtime is the US or Europe. That hurts data residency and disaster recovery: if your data must stay in Europe, you have no second European site to fail over to. Watch at 12:08
Private networking needs Enterprise. Private Spaces and extra regions require the Enterprise plan, which new customers can no longer buy. Watch at 12:46
Multi-tenancy. A SaaS that isolates customers ends up with one Heroku environment per client. Watch at 13:05
Guillaume was fair to Heroku here. For a small engineering team spending a couple of thousand dollars a month or less, it still works well, and he told those teams to stay (watch at 13:23). The case for leaving starts when you need scale, more regions, private networking or tenant isolation. For most teams that points to a public cloud, and in this session, to AWS.
A six-figure engagement. The knowledge leaves with the contractor, and your team still needs someone accountable for operations.
Guillaume did that last one for customers for twelve years. His verdict: it suits large enterprises with time and budget. A startup wants production running on AWS in a day.
All four routes share one mistake. Teams move the services first and plan to rebuild the platform layer later, under pressure. Guillaume quoted a line from an earlier post on this blog: "Rebuild the platform layer first, or the migration will fail later." On every migration he ran, the landing zone (accounts, environments, CI/CD between them) took the longest.
The six steps of a migration, and the three an agent compresses
After the assessment phase, when your apps are grouped into migration waves, a migration follows six steps:
Build the platform layer. AWS account, cluster, CI/CD.
Move the stateless services. They are the easiest to roll back.
Move workers and cron tasks.
Move the data. The slowest step, because it scales with your data volume.
Test, run both stacks side by side, then cut DNS over.
Decommission the Heroku app.
Steps 1 to 3 are where an agent, working on top of the right orchestration layer, saves the most time (watch at 20:38). Romaric added some history: after hundreds of customer migrations, Qovery had already brought this work down from weeks to a few days before agents existed. With agents, new customers now do it from one command (watch at 21:17). The target for the live demo was about twenty minutes.
The Qovery skills, which are open source. They teach the agent how Qovery works (organizations, projects, environments, services, databases) and which API calls to make.
The Qovery MCP server, which is how the agent talks to the Qovery API. It keeps the agent inside the permissions you define in Qovery. Watch at 25:57
In plan mode, Guillaume typed: migrate my application to Qovery.
He was open about one shortcut. The repository already contained a Dockerfile. The agent can generate one, but that step is trivial for an LLM and would only slow the live demo down.
The agent read the repository and the Heroku setup and came back with a plan covering:
the web dyno and the worker dyno
a lifecycle job to create the database schema and seed data
the cron job that sends reminders
PostgreSQL and Redis, with Qovery blueprints available for both
It also noticed the Qovery session had expired and asked Guillaume to log in again with qovery auth --headless (watch at 29:36).
For the databases, Guillaume asked for container databases to keep the demo fast (watch at 31:32). Qovery supports two modes:
Container databases run PostgreSQL, MariaDB and others inside your cluster. They start quickly and cost only compute, which suits development and testing.
Managed databases such as Amazon RDS take 15 to 20 minutes to provision and give you high availability, Multi-AZ and backups. Use these in production.
A few minutes later, a new dev environment held Postgres, Redis, the web service, the worker, the lifecycle job and the cron job, and the deployment was running (watch at 35:02). "I've done nothing, just asking AI to do that for me."
An organization holds your projects. A project groups the components that work together.
An environment is a Kubernetes namespace on your cluster.
Connecting a cluster takes a name and cloud credentials. Qovery creates the cluster and the VPC, or uses a VPC you already have.
Workloads and data stay in your AWS account. Qovery runs the control plane that manages deployments (watch at 33:36).
Romaric stressed that this demo matches what customers run in production, on a platform that is SOC 2 Type II, HIPAA, GDPR and DORA compliant (watch at 35:41).
Guillaume shared a story from a POC kickoff three weeks earlier (watch at 36:19). A platform engineer on the customer's side ran the same skill during the meeting. By the end of the kickoff, their first application was running on Qovery.
Run the same migration on your Heroku app.
Install the Qovery skills, point your agent at your repo, and deploy your web dynos, workers, Postgres and Redis into your own AWS account. Workloads and data stay in your account.
Romaric raised the obvious objection: this is a demo app, and real migrations always break on the first attempt. Through Qovery, the agent sees each service's deployment status and live logs. When something fails, it reads the logs, adjusts the Qovery configuration, or asks you when the fix belongs in your code.
The live demo had its own hiccup. The app came up with an empty database because the seed script had not run (watch at 39:16). Guillaume asked Claude to seed it, and the data appeared shortly after (watch at 41:50).
Guillaume never handled a single secret during the migration. Qovery generated the database credentials and exposed built-in variables for the namespace, environment name, commit and database endpoints. Secret values cannot be read back once set; to change one, you set a new value (watch at 40:02). The app reads them through aliases, so no developer needs direct access.
Romaric added that variable management covers scopes, interpolation, overrides and aliases, so you avoid duplicating values across services. Every change is recorded in the audit log, which matters in regulated environments (watch at 41:32).
Custom domains. Add your domain to the service, create a CNAME, and Qovery issues and renews the TLS certificate. If you use Cloudflare, you can enable the CDN option.
Shell access. Open a shell into a running service from the Console or the CLI. Watch at 44:03
One-off dynos. Ephemeral pods give you the heroku run workflow. Watch at 44:54
Monitoring and autoscaling, plus integrations with the tools you used as Heroku add-ons. Watch at 45:30
Terraform when you want it. Teams coming from Heroku rarely start with infrastructure as code. Once things run, the agent can export the whole setup to the Qovery Terraform provider in one go. Watch at 30:50
Everything shown in the Console also works through the CLI, the API, the Terraform provider and the MCP server, so the agent can do all of it (watch at 43:38).
Qovery acts as the harness for your agent. With role-based access control you can give developers, non-technical teammates or an agent rights limited to specific projects and environments (watch at 46:32). Platform teams keep control and developers keep their autonomy.
Guillaume's split of responsibilities for a production migration (watch at 46:59):
The agent generates the migration plan and executes it.
A human validates variables and configuration and approves the resources before they are created in the target account.
DNS cutover can go to the agent if your registrar has an API and you pass the key securely. Guillaume changed his mind on this one live. Watch at 47:34
The database migration stays with humans. Watch at 47:51
There is no zero-downtime path out of Heroku Postgres. It does not support the extensions AWS Database Migration Service relies on, so you cannot keep the two databases in continuous sync (watch at 48:30). Guillaume laid out three options:
Under 20 to 30 GB, and you can stop the app for a few minutes: dump and restore with Heroku backups. Watch at 48:42
Larger databases: Heroku's own documentation says its backups are not reliable at that size, so use pg_dump. The bigger the database, the longer the app stays down, so plan a night or a weekend. Watch at 49:09
You cannot stop the app: ask Heroku to ship the write-ahead logs (WAL) to an S3 bucket, replay them to keep the new database nearly in sync, then cut over in a few minutes. Watch at 49:35
Lower infrastructure cost. Heroku charges its service margin on top of the underlying compute. On AWS you pay for the infrastructure, and Qovery provides the service layer that keeps the Heroku experience.
Ownership. The infrastructure is yours to change. If you ever leave, you take the Terraform state with you, with no support ticket in the way. Watch at 51:49
Room to scale. AWS capacity grows with you, and Qovery configures the scaling policies. Watch at 52:02
Preview environments, the equivalent of review apps. Qovery clones the environment for every pull request. Watch at 52:54
Disaster recovery in any AWS region, or on GCP or Azure. Watch at 53:15
Cost control. Clusters run Karpenter, which bin-packs workloads onto the best-priced instances, plus right-sizing recommendations. Watch at 53:46
Guillaume's closing advice (watch at 54:20): choose a target you will not need to leave again in two years. He has met companies that move every two years to collect each cloud provider's credits. At some point you need to stop.
Questions after watching? Leave them under the video on YouTube and we will answer them there.
Frequently asked questions
Can an AI agent really migrate a Heroku app to AWS in one command?
For the platform layer, stateless services, workers and cron jobs, yes. In the demo, one prompt in Claude Code produced a full environment on AWS with Postgres, Redis, web, worker, a lifecycle job and a cron job. The database migration and final approvals should stay with a human.
Does my data leave my AWS account?
No. Workloads and data run in your own AWS account. Qovery runs the control plane that manages deployments.
Can I migrate Heroku Postgres with zero downtime?
No. Heroku Postgres does not support what AWS DMS needs for continuous replication. Small databases can move with a short dump and restore. Large ones need pg_dump in a maintenance window, or WAL shipping from Heroku to S3 for a cutover of a few minutes.
What replaces review apps and `heroku run`?
Preview environments cloned for each pull request, and ephemeral pods plus shell access from the Console or CLI.
Do I need to know Terraform or Kubernetes?
No. You can start from the Console, the CLI or an agent, and export everything to Terraform later if you want infrastructure as code.
Romaric founded Qovery to make Kubernetes accessible to every engineering team. He writes about platform strategy, developer experience, and the future of cloud infrastructure.
Next step
Run the same migration on your Heroku app.
Install the Qovery skills, point your agent at your repo, and deploy your web dynos, workers, Postgres and Redis into your own AWS account. Workloads and data stay in your account.
