AWS Elastic Beanstalk Support
Elastic Beanstalk platform upgrade: move to a supported platform branch.
Beanstalk platform branches and the operating systems under them are retired over time. A minor update is routine, but moving to a new OS or runtime branch can change paths, hooks and package commands. We test it on a clone and cut over with a swap so you can go back.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Your platform branch is deprecated or retired
- The Beanstalk console shows a platform update available or a retired warning
- You must move to a newer Node.js, Python, PHP, Java or .NET runtime
- An older Amazon Linux generation is going out of support
- Managed platform updates failed or are disabled
What you get
- Platform status report for every environment
- Compatibility changes to configuration and hooks
- Tested blue/green cutover plan with rollback
- Managed update window configuration
How we do it
A clear, safe process you can follow along with.
1. Identify current and target platforms
We list each environment's platform ARN and check the supported platform branches and their retirement status in Elastic Beanstalk docs, so we know whether this is a minor update or a move to a new branch.
2. Review what changes between branches
A new OS or runtime can change default configuration, file locations, the proxy setup, installed packages, package manager commands, and supported .ebextensions features. We compare our .ebextensions, .platform hooks, Procfile and instance startup scripts against the new platform notes.
3. Decouple stateful resources
If a database is created inside the environment, it will be deleted with it. We confirm RDS and other stateful resources live outside Beanstalk, or move them first.
4. Clone and test
We clone the environment, change the clone to the new platform, deploy the application and run tests, including load, background jobs and scheduled tasks. Findings feed updates to the app and configuration.
5. Choose the update method
For minor and patch versions within a branch we use managed platform updates or an immutable update. For a new branch we create a new environment and use blue/green deployment with a CNAME swap, since changing branches in place carries more risk.
6. Cut over and monitor
We swap URLs or shift Route 53 weighted traffic, watch errors, health and latency, and keep the old environment for a rollback window before terminating it.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Upgrading production in place across branches
Failures can leave the environment unhealthy with no quick path back.
Database inside the environment
Termination or recreation can delete the data.
Forgetting hard-coded CNAME or DNS
A swap changes what the URLs point to, so clients using the old CNAME directly need a stable name such as Route 53.
Assuming .ebextensions run the same
Package and service commands differ across OS generations.
Frequently Asked Questions
What happens when an Elastic Beanstalk platform is retired?
AWS stops supporting and updating it, and you should move to a supported branch. Existing environments may keep running for a time, but without security updates, so we plan the move early.
Do managed platform updates move me to a new branch?
Managed updates apply minor and patch versions within the same platform branch. A new major branch needs a deliberate migration.
Is blue/green deployment the safest approach?
For platform changes it usually is, because the old environment stays untouched until you swap and can be swapped back.
Want Help With Elastic Beanstalk platform upgrade: move to a supported platform branch?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required