[everfrustrated]

It's certainly a valid option. The company I'm at did a migration from Heroku to Beanstalk (manually created).

This was done because the lack of Infra/DevOps specialisation in the company at the time and Beanstalk was the most similar service to Heroku. Biggest change was dockerising.

Advantage is EB has a somewhat friendly UI so you can do everything point and click if that's what you're used to with Heroku.

Disadvantages are the docker support is an afterthought (which is fair as EB predates docker). Trying to manage it through terraform is quite clunky. Release rollouts aren't the quickest (but depends on what you're used to). It works, is reliable, but it's not the future and hard to attract talent to work with it (doesn't make hiring any easier). AWS is maintaining and supporting it but it's not getting any new feature development.

Now we have grown and have Infra specialists we're moving to ECS fargate.

Using EB wasn't the path I'd have chosen for the company to take, but it was probably the best one given our company requirements/skills at the time. I don't regret it, but happy we have the skills to move off it. We were very glad to have been off Heroku when the recent security troubles became known. We moved off because of Heroku's constant instability and our increasing lack of confidence in them as a vendor. Which we were sad about as we loved Heroku.

Your mileage may vary.

[Rodeoclash]

I've found the docker support to be quite good these days, you can run docker compose yml files directly now (the kludgy old way they had has been deprecated)

I'm a big fan of beanstalk. It is tricky to work out exactly how to deploy to it when it's managed by Terraform but if you can put up with that then you get a well thought out app hosting + deploy with an escape hatch of being able to interact with the underlying machine using the hooks system they have.

It's and older service but still valuable for medium sized sites.