What to do about the Elastic Beanstalk PHP 8.2 platform retirement email

If you host a PHP application on AWS Elastic Beanstalk, this email may well be sitting in your inbox now, with reminders to follow:

[Action Required] AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

The short version: your application is not going to stop working, on that date or after it. What "retire" means is that AWS stops looking after the platform your application runs on - no more platform updates or security patches, and no way to create new environments on it. The answer is to move to a newer PHP platform before then, and done properly that's a routine piece of maintenance: a new environment stood up alongside the current one, the application tested on it, and traffic swapped over when everything checks out. I've done a run of these for clients this year, from PHP 8.2 and 8.3 up to 8.4, and this is what the job actually involves.

What the email actually means

Elastic Beanstalk bundles your PHP version and its supporting software into what it calls a platform branch, and AWS retires each branch as the PHP version inside it ages. Retirement is quieter than a shutdown, which is exactly what makes it easy to ignore: your environment carries on running, but it's now unsupported and slowly rotting - no security patches to the platform underneath your application, on a PHP version the PHP community itself stops patching at the end of December 2026, three months before AWS's date. Staying on supported versions is one of the pillars of keeping a PHP application secure and maintained, and retirement quietly takes it away.

The sharper catch is the "no new environments" part. A standard way of deploying, scaling and recovering on Elastic Beanstalk is to create a fresh environment - a clone for a blue/green deployment, or a rebuild after something's gone wrong. Once the branch is retired, that door closes: the environment you have is the only one you can have, and if it breaks there's no recreating it on the same platform. The riskiest moment to discover that is during an incident, which is precisely when you'd need it.

The email suggests PHP 8.3, 8.4 or 8.5 as targets. For the upgrades I've been doing this year the sweet spot is 8.4 - 8.3 buys the least time before the same email arrives again, and 8.5 is new enough that some packages are still catching up with it.

What the upgrade actually involves

The platform bump itself is the small part. The real work is making sure your application is happy on the new PHP version, and that starts away from AWS entirely: running the application locally on the target version, running the test suite if there is one, and reading the deprecation warnings PHP is helpfully specific about. Alongside that come the Composer dependencies - the third-party packages every PHP application is built on - which need bumping to versions that support the new PHP, and occasionally replacing altogether where a package has been abandoned by its maintainer. That's the piece that varies most between applications: sometimes it's an hour of version bumps, sometimes one abandoned package needs properly replacing and testing.

Then the Beanstalk side, and this is where the platform's own machinery makes the job safe: rather than upgrading the live environment in place, I spin up a completely new environment on the new platform branch, deploy the updated application to it, and test it there - same code, same configuration, real AWS, no customers. The live environment carries on serving traffic untouched the whole time. When the new environment checks out, Beanstalk swaps the URLs between the two in one operation, and the old environment sticks around for a few days as the rollback before it's deleted. Done this way there's no big-bang moment, and the swap back is as quick as the swap over if anything surfaces.

If the email is in your inbox

March 2027 sounds comfortably far away, but the PHP version underneath stops receiving community security fixes at the end of 2026, and the work is easier to schedule now than mid-incident later. For most applications this is days of work, not weeks - and if the same inbox also holds retirement notices for older platforms or other AWS deadlines you can't action yourself, that's a familiar situation for a lot of the businesses I work with. If you'd like a hand working out what applies to your systems and getting the upgrade done quietly, get in touch.

Also in this series: the Lambda Node.js 20 end-of-life email and the RDS MySQL 8.0 end of standard support email.