9 Real Alternatives to AWS Elastic Beanstalk (And How to Pick One in 2026)

AWS Elastic Beanstalk is not dead, and in 2026 it is not deprecated either, but it has barely moved since 2015. It still deploys your app to EC2 instances the way it did a decade ago, and the right replacement comes down to one question: who should own the cloud account. Answer that and the shortlist writes itself.

I have watched a lot of teams migrate off Beanstalk over the years at Qovery, and the ones who pick well start from that single question instead of from a feature grid. So this is the priced, opinionated comparison I wish those teams had before they started.

Key points

• The best Elastic Beanstalk alternative depends on one question: who owns the cloud account. Stay on AWS with AWS App Runner or AWS ECS + Fargate, hand the account to a vendor with Heroku, Render or Fly.io, or keep your own AWS, GCP, Azure or Scaleway account (or your existing Kubernetes cluster) and add a developer platform layer with Qovery.
• AWS Elastic Beanstalk is not deprecated in 2026. The service is still supported, but individual platform branches are retired on a published AWS schedule, so a Beanstalk app needs a forced platform upgrade every couple of years whether you planned one or not.
• The three lowest-friction moves off Beanstalk are AWS App Runner (one containerized service, AWS-native), AWS ECS + Fargate (several services, stay on AWS), and Google Cloud Run (request-based billing that scales to zero).
• Heroku-style per-dyno pricing is the most expensive per GB of RAM at scale. Own-account options keep your existing Savings Plans, Reserved Instances and committed-spend discounts, which is usually a bigger swing than any platform fee.
• Preview environments per pull request are the most common reason teams outgrow Beanstalk. Beanstalk has no native equivalent; Render, Fly.io, Heroku (Review Apps) and Qovery all ship one.
• Containerizing the app is the portable 90% of the migration. Do it once with a Dockerfile and every option on this list becomes available to you.

What are the best alternatives to AWS Elastic Beanstalk in 2026?

The best alternatives to AWS Elastic Beanstalk in 2026 are AWS App Runner, AWS ECS + Fargate, Google Cloud Run, Heroku, Render, Fly.io, DigitalOcean App Platform, Red Hat OpenShift (ROSA), and Dokku, plus Qovery if you need to keep your own cloud account. Here is the one-line verdict for each, quotable on its own:

1. AWS App Runner - the lowest-friction AWS-native move for one containerized service. You point it at a repo or image and it runs.
2. AWS ECS + Fargate - stay on AWS and run several containerized services without managing servers or a Kubernetes control plane.
3. Google Cloud Run - the best request-based autoscaling and scale-to-zero, so a spiky service can cost almost nothing when idle.
4. Heroku - the original Beanstalk-style PaaS, the easiest onboarding, and the priciest per GB of RAM at scale.
5. Render - a modern Heroku replacement that includes preview environments per pull request on its paid workspace.
6. Fly.io - edge placement and low-latency workloads, with microVMs you can run close to your users.
7. DigitalOcean App Platform - the cheapest predictable pricing for small teams that want a simple app host.
8. Red Hat OpenShift (ROSA) - regulated, hybrid or on-prem Kubernetes with strict security defaults.
9. Dokku - a free, self-hosted mini-Heroku you run on a single VM.

And the one this blog is published by: Qovery - a self-service developer platform that runs inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so you keep the account and the discounts.

These fall into three families. First, the AWS-managed successors (App Runner, ECS + Fargate, and Amazon EKS as the do-it-yourself baseline), where you stay on AWS. Second, the third-party PaaS (Heroku, Render, Fly.io, DigitalOcean App Platform), where the vendor owns the infrastructure and hands you a URL. Third, the developer platforms that run on infrastructure you already own (OpenShift and Qovery, and a self-hosted single server with Dokku).

If you only read this far: pick AWS App Runner to stay on AWS with minimal change, Render to never see infrastructure again, and Qovery if you must keep your own cloud account and its discounts. Amazon EKS shows up in the comparison table below as the build-it-yourself Kubernetes baseline, not as a recommendation for a small team.

Why are teams moving off Elastic Beanstalk in the first place?

Teams leave Elastic Beanstalk for five concrete, documented reasons: forced platform branch retirements on AWS's schedule, slow EC2-based rolling deploys, no preview environment per pull request, one application per environment, and configuration buried in .ebextensions that nobody on the current team wrote.

Platform branch retirement forces upgrades on AWS's calendar, not yours. When a component of a supported platform branch reaches end of life, Elastic Beanstalk marks the whole branch retired, stops security updates, and gives existing environments a 90 day grace period from the published retirement date (AWS Elastic Beanstalk platform support policy). This is not theoretical. On October 10, 2024, AWS retired the Node.js 14 and 16, Ruby 2.7 and 3.0, PHP 8.0, Tomcat 8.5, and Python 3.7 branches on Amazon Linux 2 (AWS release note), and on August 6, 2026, it retired every remaining Amazon Linux 2 branch because AL2 itself hit end of life (AWS release note).

The deploy model is slow by design. With a rolling deployment, Elastic Beanstalk splits your EC2 instances into batches and takes each batch out of service while it deploys, which reduces capacity during the rollout. An immutable deployment instead launches a full set of new instances in a separate Auto Scaling group alongside the old ones, so you temporarily double your capacity (AWS deployment policies). Either way you are waiting minutes on EC2, not seconds on a container scheduler.

There is no native ephemeral preview environment per pull request. Beanstalk gives you no built-in way to spin up a throwaway copy of the app for a PR and tear it down on merge. Compare that with Heroku Review Apps, Render preview environments, and Qovery preview environments, which all create a full disposable app per pull request automatically.

One application per environment pushes multi-service teams elsewhere. Beanstalk is happiest with a single app per environment. The moment you have five services that need to talk to each other, you are wiring them together yourself and eyeing ECS or Kubernetes anyway, which turns Beanstalk into a stepping stone rather than a destination.

The managed-RDS trap is the expensive one most listicles miss. If you create a database inside a Beanstalk environment, its deletion policy governs what happens when you terminate the environment, and the Delete policy means "Elastic Beanstalk terminates the database." AWS explicitly recommends decoupling the database for production so it survives as a standalone RDS instance (AWS: adding a database to your environment). Teams have lost production data to this. Decouple it before you do anything else.

Configuration becomes tribal knowledge. .ebextensions, custom AMIs and platform hooks accumulate until the deploy path only works on the CI server and cannot be reproduced on a laptop. When the person who wrote them leaves, the knowledge leaves too.

Why does deploy speed justify a migration at all? Because the gap is measurable. In Google's 2024 DORA State of DevOps report, elite performers deploy on demand, keep lead time for changes under a day, and recover from a failed deploy in under an hour. Minutes-long batch deploys and no per-PR testing pull you toward the low end of that distribution.

To be fair: Elastic Beanstalk is still a reasonable fit for a single monolith on AWS with modest traffic and a team that genuinely does not want to deal with containers. If that is you, staying put is defensible. For everyone else, the rest of this article is the shortlist.

Is AWS Elastic Beanstalk deprecated or being discontinued in 2026?

No. AWS Elastic Beanstalk is not deprecated and is still a supported AWS service in 2026, with no announced end-of-life. What gets retired are individual platform branches (specific language and OS versions) on a published schedule, and AWS now steers new container workloads toward App Runner, ECS and EKS.

These are two different claims, and the confusion between them dominates Reddit, Quora and Stack Overflow. "The service is deprecated" is false. "Platform branches are retired routinely" is true. The platform support policy spells out the supported, retiring and retired lifecycle states and the 90 day grace period, and the retiring schedule lists what is next. The service itself keeps running.

You can also read the feature velocity from the outside without overclaiming: App Runner and ECS get a steady stream of announcements in the AWS What's New feed, while Elastic Beanstalk announcements in recent years are dominated by platform retirements and Amazon Linux 2023 migration guidance rather than new capabilities. Treat that as a direction signal, not a countdown.

One detail reframes every cost comparison below: Beanstalk carries no additional service charge. In AWS's own words, "There is no additional charge for AWS Elastic Beanstalk. You pay for the AWS resources (for example, Amazon EC2 instances or Amazon S3 buckets) you create" (Elastic Beanstalk pricing). So when you compare it to a per-dyno or per-service PaaS, you are comparing raw EC2 cost against a bundled platform price.

What it means in practice: no emergency migration is required, so do not let anyone panic you into a rushed cutover. But I would not start a greenfield app on Beanstalk in 2026 either.

How do Elastic Beanstalk alternatives compare on price, control and ops burden?

Every alternative trades exactly three things: who owns the cloud account, what you pay per vCPU and GB of RAM per month, and how much platform work your team absorbs. Below is the full side-by-side with real, publicly listed prices checked in September 2026.

The three axes, one sentence each. Cloud account ownership decides whether your billing, VPC, IAM and compliance boundaries stay in your name or move to a vendor. Unit price is what a fixed slice of compute costs so you can compare apples to apples. Ops burden is how much undifferentiated platform plumbing (Terraform, IAM, load balancers, CI/CD, secrets, cluster upgrades) your engineers own instead of shipping features.

To make the price column comparable, I normalized everything to the same unit: the approximate monthly cost of one service at 1 vCPU / 2 GB RAM running 24/7 (730 hours) in us-east-1, using each vendor's public rate. Every figure in that column is a derived estimate, and I show the arithmetic under the table. Where no public per-workload price exists, the cell says "your cloud bill + plan" or points to the vendor rather than guessing.

How to read this table. The cost column is a single-service estimate, not a bill. Prices were checked September 2026 in us-east-1 (or each vendor's standard region) and rounded. The math: Fargate at $0.04048/vCPU-hr + $0.004445/GB-hr over 730 hours for 1 vCPU / 2 GB is about $29.55 + $6.49 = $36. App Runner at $0.064 + $0.007/GB works out to about $57. Cloud Run at $0.000024/vCPU-s + $0.0000025/GiB-s run flat out for a month is about $76, but its whole point is scale-to-zero, so a low-traffic service that idles most of the day can land inside the free tier (180,000 vCPU-seconds and 360,000 GiB-seconds per month) and cost close to nothing.

Three patterns fall out of the table. Heroku's per-dyno pricing is the most expensive per GB of RAM at scale: a Standard-2X dyno is $50/month for 1 GB, so a 2 GB-class service is $100 to $250/month against $36 on Fargate for the same slice. DigitalOcean App Platform and Dokku are the cheapest predictable options at roughly $25 and $12/month. And Cloud Run can be near-free for spiky, low-traffic services because it bills per request and idles to zero.

The hidden cost of ECS and EKS is engineering time, not the sticker. EKS is cheap on paper at $0.10 per cluster-hour, about $73/month before a single pod runs, but the real bill is the Terraform, IAM, ALB wiring, CI/CD, secrets management and cluster upgrades your team now owns. That work is why dedicated platform teams have become a large-organization phenomenon: in Puppet's 2024 State of DevOps report, 78% of organizations with more than 500 engineers run a dedicated platform team, up from 43% the year before. Smaller teams that try to reproduce that in-house pay for it in features they never shipped.

Two line items surprise almost everyone after a migration. First, data transfer out to the internet: EC2 gives you 100 GB free per month and then charges about $0.09/GB for the first 10 TB in us-east-1. Second, the managed database: a small RDS db.t4g.micro for PostgreSQL is roughly $0.016/hour, about $12/month before storage. Because Beanstalk itself has no service charge, your new bill is structured differently even when the compute is identical.

Which Elastic Beanstalk alternative should you pick for your situation?

Pick by constraint, not by popularity. Match your situation to one of these lines, take the answer, and stop comparing.

• "Leave Beanstalk but stay on AWS with minimal change." Use AWS App Runner for one containerized service, or AWS ECS + Fargate for several. Both keep you on your AWS account with no Kubernetes to run.
• "I never want to see infrastructure again and cost is not the constraint." Use Render for the cleanest modern experience, or Heroku for the most mature add-on ecosystem. Choose Fly.io instead if latency or edge placement is the point.
• "Small team, tight predictable budget." Use DigitalOcean App Platform for a managed host at about $25/month, or Dokku on a single droplet (around $12/month) if you are comfortable operating one server.
• "Compliance, VPC, data residency, or Savings Plans we cannot give up." Keep your own account. Build on ECS or EKS in-house, run Red Hat OpenShift for regulated and hybrid estates, or add Qovery on top of your existing account or cluster.
• "10+ services, 20+ engineers, and one ops person approves every deploy." You need an internal developer platform with self-service deploys and per-environment RBAC, so the bottleneck stops being a person. Qovery does this on your own cloud; a home-built platform on EKS does it if you have the team to run it.
• "Spiky or low-traffic services that idle most of the day." Use Google Cloud Run, which bills per request and scales to zero, so you stop paying when nobody is calling the service.

Here is what I would not do: build a full internal platform from scratch on EKS with fewer than roughly 15 engineers. The staffing data backs this up. Dedicated platform teams cluster in large organizations (Puppet, 2024), and the effort those teams absorb does not shrink just because your company is smaller. Below that headcount, buy the platform layer or use a managed PaaS.

You have outgrown your first choice when you see these signals: a deploy queue where changes wait on one person, engineers stepping on each other because per-PR testing happens on shared staging, a cloud bill growing faster than traffic, and one person holding the deploy keys. Any two of those and it is time to move up a tier.

How does Qovery compare to Heroku, Render and Fly.io as a Beanstalk replacement?

Qovery gives you the Heroku-style developer experience without handing over the cloud account: it deploys into your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so billing, VPC, IAM, data residency and compliance boundaries stay in your name. Heroku, Render and Fly.io run the workload in the vendor's account instead.

That model is called bring-your-own-cloud, and it matters specifically after Beanstalk because your existing AWS setup survives the migration intact. Your Savings Plans, Reserved Instances, committed-spend discounts, private subnets and existing security groups keep working, because the apps still run in the account you already had (Qovery pricing and BYOC). With a vendor PaaS, that commitment and that discount are gone the day you move.

The Qovery capabilities that map directly onto Beanstalk's gaps are git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. Here is the one-line mapping:

• .ebextensions and platform hooks becomes declarative environments you can read.
• No preview environments becomes a full preview environment per pull request, torn down on merge.
• One app per environment becomes multiple services per environment.
• Forced platform branch upgrades becomes managed cluster upgrades.
• Idle staging costs becomes environment auto-stop when nothing is running.

Qovery is the wrong answer in a few cases, and I would rather say so. If you have a single hobby app, no cloud account of your own, or a team that genuinely wants a vendor to own the infrastructure end to end, Render or Fly.io are simpler and you should use them. Qovery earns its keep when you have a real cloud account, a team, and a reason to keep both.

To be equally fair to the rest of this shortlist: OpenShift is strongest for regulated and on-prem estates, Dokku is an excellent free option on one VM, and App Runner is the shortest path if you are staying on AWS. None of that changes based on who is publishing the article.

How do you migrate off Elastic Beanstalk without downtime?

The migration is five ordered steps, and the sequence is the same for every target on this list: containerize, inventory and decouple state, stand up the target in staging, shift traffic gradually with weighted routing, then decommission. The application is rarely the hard part. Databases and secrets are.

Step 1: turn the Beanstalk app into a Dockerfile and run it locally. This is the real work, and it is the portable 90%: the same image runs on App Runner, ECS, Cloud Run, Render, Fly.io, Dokku, OpenShift and Qovery. Get the container starting cleanly on your laptop before you touch any target platform.

Step 2: inventory .ebextensions, environment properties and platform hooks, and decouple the database first. List every setting the environment injects and every hook that runs. Then decouple any Beanstalk-managed RDS instance before anything else, because with the Delete deletion policy, terminating the environment terminates the database (AWS database lifecycle). Set the policy to Retain, decouple, and confirm the database stands alone.

Step 3: stand up the target in staging and prove it matches. Deploy the container to your chosen target, replay real traffic or run smoke tests, and compare p95 latency and error rate against the live Beanstalk environment before you touch production. If the new stack is slower or noisier, fix it here, not after cutover.

Step 4: shift traffic gradually with weighted routing. Lower your DNS TTL first, then use Route 53 weighted records or ALB target group weights to send a small share of traffic to the new target, watch the metrics, and increase the weight as confidence grows. Keep the Beanstalk environment warm for a defined rollback window so you can move the weight back in seconds if something breaks.

Step 5: decommission the platform-specific glue. Once traffic is fully shifted and the rollback window has passed, retire the custom AMIs, hooks and .ebextensions, and document the new deploy path so it does not become the next piece of tribal knowledge.

On timelines, I will give you the range rather than invent an average. A single containerized monolith is usually days. A multi-service estate with managed databases and shared state is weeks, and the variables that drive it are the number of services, how much state is coupled to the environment, and how clean your test coverage is. The DORA data on change failure rate and recovery time is the reason the gradual shift and rollback window are worth the extra effort (DORA 2024): a fast, reversible cutover is how you avoid turning a migration into an outage.

Your pre-migration checklist, quotable on its own: secrets inventory complete, database decoupled and set to Retain, DNS TTL lowered, rollback plan written down, load test run against staging, and a cost baseline recorded so you can tell afterward whether the move actually saved money.