# Updating your Elastic Beanstalk environment's platform version
Elastic Beanstalk regularly releases new platform versions to update all Linux-based and Windows Server-based [platforms](concepts.platforms.md). New platform versions provide updates to existing software components and support for new features and configuration options. To learn about platforms and platform versions, see [Elastic Beanstalk platforms glossary](platforms-glossary.md).
You can use the Elastic Beanstalk console or the EB CLI to update your environment's platform version. Depending on the platform version you'd like to update to, Elastic Beanstalk recommends one of two methods for performing platform updates.
+ [Method 1 – Update your environment's platform version](#using-features.platform.upgrade.config). We recommend this method when you're updating to the latest platform version within a platform branch—with the same runtime, web server, application server, and operating system, and without a change in the major platform version. This is the most common and routine platform update.
+ [Method 2 – Perform a Blue/Green deployment](#using-features.platform.upgrade.bluegreen). We recommend this method when you're updating to a platform version in a different platform branch—with a different runtime, web server, application server, or operating system, or to a different major platform version. This is a good approach when you want to take advantage of new runtime capabilities or the latest Elastic Beanstalk functionality, or when you want to move off of a deprecated or retired platform branch.
[Migrating from a legacy platform version](using-features.migration.md) requires a blue/green deployment, because these platform versions are incompatible with currently supported versions.
[Migrating a Linux application to Amazon Linux 2](using-features.migration-al.md) requires a blue/green deployment, because Amazon Linux 2 platform versions are incompatible with previous Amazon Linux AMI platform versions.
For more help with choosing the best platform update method, expand the section for your environment's platform.
## Docker
Use [Method 1](#using-features.platform.upgrade.config) to perform platform updates.
## Multicontainer Docker
Use [Method 1](#using-features.platform.upgrade.config) to perform platform updates.
## Preconfigured Docker
Consider the following cases:
+ If you're migrating your application to another platform, for example from *Go 1.4 (Docker)* to *Go 1.11* or from *Python 3.4 (Docker)* to *Python 3.6*, use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're migrating your application to a different Docker container version, for example from *Glassfish 4.1 (Docker)* to *Glassfish 5.0 (Docker)*, use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're updating to a latest platform version with no change in container version or major version, use [Method 1](#using-features.platform.upgrade.config).
## Go
Use [Method 1](#using-features.platform.upgrade.config) to perform platform updates.
## Java SE
Consider the following cases:
+ If you're migrating your application to a different Java runtime version, for example from *Java 7* to *Java 8*, use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're updating to a latest platform version with no change in runtime version, use [Method 1](#using-features.platform.upgrade.config).
## Java with Tomcat
Consider the following cases:
+ If you're migrating your application to a different Java runtime version or Tomcat application server version, for example from *Java 7 with Tomcat 7* to *Java 8 with Tomcat 8.5*, use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're migrating your application across major Java with Tomcat platform versions (v1.x.x, v2.x.x, and v3.x.x), use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're updating to a latest platform version with no change in runtime version, application server version, or major version, use [Method 1](#using-features.platform.upgrade.config).
## .NET on Windows server with IIS
Consider the following cases:
+ If you're migrating your application to a different Windows operating system version, for example from *Windows Server 2008 R2* to *Windows Server 2016*, use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're migrating your application across major Windows Server platform versions, see [Migrating from earlier major versions of the Windows server platform](dotnet-v2migration.md#dotnet-v2migration.migration), and use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If your application is currently running on a Windows Server platform V2.x.x and you're updating to a latest platform version, use [Method 1](#using-features.platform.upgrade.config).
**Note**
[Windows Server platform versions](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) earlier than v2 aren't semantically versioned. You can only launch the latest version of each of these Windows Server major platform versions and can't roll back after an upgrade.
## Node.js
Use [Method 2](#using-features.platform.upgrade.bluegreen) to perform platform updates.
## PHP
Consider the following cases:
+ If you're migrating your application to a different PHP runtime version, for example from *PHP 5.6* to *PHP 7.2*, use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're migrating your application across major PHP platform versions (v1.x.x and v2.x.x), use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're updating to a latest platform version with no change in runtime version or major version, use [Method 1](#using-features.platform.upgrade.config).
## Python
Consider the following cases:
+ If you're migrating your application to a different Python runtime version, for example from *Python 2.7* to *Python 3.6*, use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're migrating your application across major Python platform versions (v1.x.x and v2.x.x), use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're updating to a latest platform version with no change in runtime version or major version, use [Method 1](#using-features.platform.upgrade.config).
## Ruby
Consider the following cases:
+ If you're migrating your application to a different Ruby runtime version or application server version, for example from *Ruby 2.3 with Puma* to *Ruby 2.6 with Puma*, use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're migrating your application across major Ruby platform versions (v1.x.x and v2.x.x), use [Method 2](#using-features.platform.upgrade.bluegreen).
+ If you're updating to a latest platform version with no change in runtime version, application server version, or major version, use [Method 1](#using-features.platform.upgrade.config).
## Method 1 – Update your environment's platform version
Use this method to update to the latest version of your environment's platform branch. If you've previously created an environment using an older platform version, or upgraded your environment from an older version, you can also use this method to revert to a previous platform version, provided that it's in the same platform branch.
**To update your environment's platform version**
1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.
1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.
1. On the environment overview page, under **Platform**, choose **Change**.
![\[Elastic Beanstalk newer platform available\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/environment-management-platform-change.png)
1. On the **Update platform version** dialog, select a platform version. The newest (recommended) platform version in the branch is selected automatically. You can update to any version that you've used in the past.
![\[Elastic Beanstalk update platform version confirmation\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/environment-management-update-platform-version.png)
1. Choose **Save**.
To further simplify platform updates, Elastic Beanstalk can manage them for you. You can configure your environment to apply minor and patch version updates automatically during a configurable weekly maintenance window. Elastic Beanstalk applies managed updates with no downtime or reduction in capacity, and cancels the update immediately if instances running your application on the new version fail health checks. For details, see [Managed platform updates](environment-platform-update-managed.md).
## Method 2 – Perform a Blue/Green deployment
Use this method to update to a different platform branch—with a different runtime, web server, application server, or operating system, or to a different major platform version. This is typically necessary when you want to take advantage of new runtime capabilities or the latest Elastic Beanstalk functionality. It's also required when you're migrating off of a deprecated or retired platform branch.
When you migrate across major platform versions or to platform versions with major component updates, there's a greater likelihood that your application, or some aspects of it, might not function as expected on the new platform version, and might require changes.
Before performing the migration, update your local development machine to the newer runtime versions and other components of the platform you plan on migrating to. Verify that your application still works as expected, and make any necessary code fixes and changes. Then use the following best practice procedure to safely migrate your environment to the new platform version.
**To migrate your environment to a platform version with major updates**
1. [Create a new environment](using-features.environments.md), using the new target platform version, and deploy your application code to it. The new environment should be in the Elastic Beanstalk application that contains the environment you're migrating. Don't terminate the existing environment yet.
1. Use the new environment to migrate your application. In particular:
+ Find and fix any application compatibility issues that you couldn't discover during the development phase.
+ Ensure that any customizations that your application makes using [configuration files](ebextensions.md) work correctly in the new environment. These might include option settings, additional installed packages, custom security policies, and script or configuration files installed on environment instances.
+ If your application uses a custom Amazon Machine Image (AMI), create a new custom AMI based on the AMI of the new platform version. To learn more, see [Using a custom Amazon machine image (AMI) in your Elastic Beanstalk environment](using-features.customenv.md). Specifically, this is required if your application uses the Windows Server platform with a custom AMI, and you're migrating to a Windows Server V2 platform version. In this case, see also [Migrating from earlier major versions of the Windows server platform](dotnet-v2migration.md#dotnet-v2migration.migration).
Iterate on testing and deploying your fixes until you're satisfied with the application on the new environment.
1. Turn the new environment into your production environment by swapping its CNAME with the existing production environment's CNAME. For details, see [Blue/Green deployments with Elastic Beanstalk](using-features.CNAMESwap.md).
1. When you're satisfied with the state of your new environment in production, terminate the old environment. For details, see [Terminate an Elastic Beanstalk environment](using-features.terminating.md).
# Managed platform updates
AWS Elastic Beanstalk regularly releases [platform updates](using-features.platform.upgrade.md) to provide fixes, software updates, and new features. With managed platform updates, you can configure your environment to automatically upgrade to the latest version of a platform during a scheduled [maintenance window](#environment-platform-update-managed-window). Your application remains in service during the update process with no reduction in capacity. Managed updates are available on both single-instance and load-balanced environments.
**Note**
This feature isn't available on [Windows Server platform versions](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) earlier than version 2 (v2).
You can configure your environment to automatically apply [patch version updates](#environment-platform-update-managed-versioning), or both patch and minor version updates. Managed platform updates don't support updates across platform branches (updates to different major versions of platform components such as operating system, runtime, or Elastic Beanstalk components), because these can introduce changes that are backward incompatible.
You can also configure Elastic Beanstalk to replace all instances in your environment during the maintenance window, even if a platform update isn't available. Replacing all instances in your environment is helpful if your application encounters bugs or memory issues when running for a long period.
On environments created on November 25, 2019 or later using the Elastic Beanstalk console, managed updates are enabled by default whenever possible. Managed updates require [enhanced health](health-enhanced.md) to be enabled. Enhanced health is enabled by default when you select one of the [configuration presets](environments-create-wizard.md#environments-create-wizard-presets), and disabled when you select **Custom configuration**. The console can't enable managed updates for older platform versions that don't support enhanced health, or when enhanced health is disabled. When the console enables managed updates for a new environment, the **Weekly update window** is set to a random day of the week at a random time. **Update level** is set to **Minor and patch**, and **Instance replacement** is disabled. You can disable or reconfigure managed updates before the final environment creation step.
For an existing environment, use the Elastic Beanstalk console anytime to configure managed platform updates.
**Important**
A *high number* of Beanstalk environments in one AWS account may present a risk of throttling issues during managed updates. *High number* is a relative amount that depends on how closely you schedule the managed updates for your environments. Over 200 environments in one account scheduled closely could cause throttling issues, although a lower number may also be problematic.
To balance the resource load for managed updates, we advise that you spread out the scheduled maintenance windows for the environments in one account.
Also, consider a multi‐account strategy. For more information, see [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) on the *AWS Whitepapers & Guides* website.
**To configure managed platform updates**
1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.
1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.
1. In the navigation pane, choose **Configuration**.
1. In the **Managed updates** category, choose **Edit**.
1. Disable or enable **Managed updates**.
1. If managed updates are enabled, select a maintenance window, and then select an **Update level**.
1. (Optional) Select **Instance replacement** to enable weekly instance replacement.
![\[Modify managed updates configuration page\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/environment-platform-update-managed.png)
1. To save the changes choose **Apply** at the bottom of the page.
Managed platform updates depend on [enhanced health reporting](health-enhanced.md) to determine that your application is healthy enough to consider the platform update successful. See [Enabling Elastic Beanstalk enhanced health reporting](health-enhanced-enable.md) for instructions.
**Topics**
+ [Permissions required to perform managed platform updates](#environment-platform-update-managed-perms)
+ [Managed update maintenance window](#environment-platform-update-managed-window)
+ [Minor and patch version updates](#environment-platform-update-managed-versioning)
+ [Immutable environment updates](#environment-platform-update-managed-immutable)
+ [Managing managed updates](#environment-platform-update-managed-managing)
+ [Managed action option namespaces](#environment-platform-update-managed-namespace)
## Permissions required to perform managed platform updates
Elastic Beanstalk needs permission to initiate a platform update on your behalf. To gain these permissions, Elastic Beanstalk assumes the *managed-updates service role*. When you use the default [service role](iam-servicerole.md) for your environment, the Elastic Beanstalk console uses it as the managed-updates service role too. The console assigns the [`AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy`](iam-servicerole.md#iam-servicerole-update) managed policy to your service role. This policy has all permissions that Elastic Beanstalk needs to perform managed platform updates.
For details about other ways to set the managed-updates service role, see [Managing Elastic Beanstalk service roles](iam-servicerole.md).
**Note**
If you use [configuration files](ebextensions.md) to extend your environment to include additional resources, you might need to add permissions to your environment's managed-updates service role. Typically you need to add permissions when you reference these resources by name in other sections or files.
If an update fails, you can find the reason for the failure on the [Managed updates](#environment-platform-update-managed-managing) page.
## Managed update maintenance window
When AWS releases a new version of your environment's platform, Elastic Beanstalk schedules a managed platform update during the next weekly maintenance window. Maintenance windows are two hours long. Elastic Beanstalk starts a scheduled update during the maintenance window. The update might not complete until after the window ends.
**Note**
In most cases, Elastic Beanstalk schedules your managed update to occur during your coming weekly maintenance window. The system considers various aspects of update safety and service availability when scheduling managed updates. In rare cases, an update might not be scheduled for the first coming maintenance window. If this happens, the system tries again during the next maintenance window. To manually apply the managed update, choose **Apply now** as explained in [Managing managed updates](#environment-platform-update-managed-managing) on this page.
## Minor and patch version updates
You can enable managed platform updates to apply patch version updates only, or for both minor and patch version updates. Patch version updates provide bug fixes and performance improvements, and can include minor configuration changes to the on-instance software, scripts, and configuration options. Minor version updates provide support for new Elastic Beanstalk features. You can't apply major version updates, which might make changes that are backward incompatible, with managed platform updates.
In a platform version number, the second number is the minor update version, and the third number is the patch version. For example, a version 2.0.7 platform version has a minor version of 0 and a patch version of 7.
## Immutable environment updates
Managed platform updates perform [immutable environment updates](environmentmgmt-updates-immutable.md) to upgrade your environment to a new platform version. Immutable updates update your environment without taking any instances out of service or modifying your environment, before confirming that instances running the new version pass health checks.
In an immutable update, Elastic Beanstalk deploys as many instances as are currently running with the new platform version. The new instances begin to take requests alongside those running the old version. If the new set of instances passes all health checks, Elastic Beanstalk terminates the old set of instances, leaving only instances with the new version.
Managed platform updates always perform immutable updates, even when you apply them outside of the maintenance window. If you change the platform version from the **Dashboard**, Elastic Beanstalk applies the update policy that you've chosen for configuration updates.
**Warning**
Some policies replace all instances during the deployment or update. This causes all accumulated [Amazon EC2 burst balances](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html) to be lost. It happens in the following cases:
Managed platform updates with instance replacement enabled
Immutable updates
Deployments with immutable updates or traffic splitting enabled
## Managing managed updates
The Elastic Beanstalk console shows detailed information about managed updates on the **Managed updates overview** page.
**To view information about managed updates (console)**
1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.
1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.
1. Choose **Managed updates**.
The **Managed updates overview** section provides information about scheduled and pending managed updates. The **History** section lists successful updates and failed attempts.
You can choose to apply a scheduled update immediately, instead of waiting until the maintenance window.
**To apply a managed platform update immediately (console)**
1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.
1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.
1. Choose **Managed updates**.
1. Choose **Apply now**.
1. Verify the update details, and then choose **Apply**.
When you apply a managed platform update outside of the maintenance window, Elastic Beanstalk performs an immutable update. If you update the environment's platform from the [Dashboard](environments-dashboard.md), or by using a different client, Elastic Beanstalk uses the update type that you selected for [configuration changes](environments-updating.md).
If you don't have a managed update scheduled, your environment might already be running the latest version. Other reasons for not having an update scheduled include:
+ A [minor version](#environment-platform-update-managed-versioning) update is available, but your environment is configured to automatically apply only patch version updates.
+ Your environment hasn't been scanned since the update was released. Elastic Beanstalk typically checks for updates every hour.
+ An update is pending or already in progress.
When your maintenance window starts or when you choose **Apply now**, scheduled updates go into pending status before execution.
## Managed action option namespaces
You can use [configuration options](command-options.md) in the `aws:elasticbeanstalk:managedactions` and `aws:elasticbeanstalk:managedactions:platformupdate` namespaces to enable and configure managed platform updates.
The `ManagedActionsEnabled` option turns on managed platform updates. Set this option to `true` to enable managed platform updates, and use the other options to configure update behavior.
Use `PreferredStartTime` to configure the beginning of the weekly maintenance window in *day*:*hour*:*minute* format.
Set `UpdateLevel` to `minor` or `patch` to apply both minor and patch version updates, or just patch version updates, respectively.
When managed platform updates are enabled, you can enable instance replacement by setting the `InstanceRefreshEnabled` option to `true`. When this setting is enabled, Elastic Beanstalk runs an immutable update on your environment every week, regardless of whether there is a new platform version available.
The following example [configuration file](ebextensions.md) enables managed platform updates for patch version updates with a maintenance window starting at 9:00 AM UTC each Tuesday.
**Example .ebextensions/managed-platform-update.config**
```
option_settings:
aws:elasticbeanstalk:managedactions:
ManagedActionsEnabled: true
PreferredStartTime: "Tue:09:00"
aws:elasticbeanstalk:managedactions:platformupdate:
UpdateLevel: patch
InstanceRefreshEnabled: true
```
# Migrating your application from a legacy platform version
If you have deployed an Elastic Beanstalk application that uses a legacy platform version, you should migrate your application to a new environment using a non-legacy platform version so that you can get access to new features. If you are unsure whether you are running your application using a legacy platform version, you can check in the Elastic Beanstalk console. For instructions, see [To check if you are using a legacy platform version](#using-features.migration-proc).
## What new features are legacy platform versions missing?
Legacy platforms do not support the following features:
+ Configuration files, as described in the [Advanced environment customization with configuration files (`.ebextensions`)](ebextensions.md) topic
+ ELB health checks, as described in the [Basic health reporting](using-features.healthstatus.md) topic
+ Instance Profiles, as described in the [Managing Elastic Beanstalk instance profiles](iam-instanceprofile.md) topic
+ VPCs, as described in the [Using Elastic Beanstalk with Amazon VPC](vpc.md) topic
+ Data Tiers, as described in the [Adding a database to your Elastic Beanstalk environment](using-features.managing.db.md) topic
+ Worker Tiers, as described in the [Elastic Beanstalk worker environments](concepts-worker.md) topic
+ Single Instance Environments, as described in the [Environment types](using-features-managing-env-types.md) topic
+ Tags, as described in the [Tagging resources in your Elastic Beanstalk environments](using-features.tagging.md) topic
+ Rolling Updates, as described in the [Elastic Beanstalk rolling environment configuration updates](using-features.rollingupdates.md) topic
## Why are some platform versions marked legacy?
Some older platform versions do not support the latest Elastic Beanstalk features. These versions are marked **(legacy)** on the environment overview page in the Elastic Beanstalk console.
**To check if you are using a legacy platform version**
1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.
1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.
1. On the environment overview page, view the **Platform** name.
Your application is using a legacy platform version if you see **(legacy)** next to the platform's name.
**To migrate your application**
1. Deploy your application to a new environment. For instructions, go to [Creating an Elastic Beanstalk environment](using-features.environments.md).
1. If you have an Amazon RDS DB Instance, update your database security group to allow access to your EC2 security group for your new environment. For instructions on how to find the name of your EC2 security group using the AWS Management Console, see [EC2 security groups](using-features.managing.ec2.console.md#using-features.managing.ec2.securitygroups). For more information about configuring your EC2 security group, go to the "Authorizing Network Access to an Amazon EC2 Security Group" section of [Working with DB Security Groups](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithSecurityGroups.html) in the *Amazon Relational Database Service User Guide*.
1. Swap your environment URL. For instructions, go to [Blue/Green deployments with Elastic Beanstalk](using-features.CNAMESwap.md).
1. Terminate your old environment. For instructions, go to [Terminate an Elastic Beanstalk environment](using-features.terminating.md).
**Note**
If you use AWS Identity and Access Management (IAM) then you will need to update your policies to include CloudFormation and Amazon RDS (if applicable). For more information, see [Using Elastic Beanstalk with AWS Identity and Access Management](AWSHowTo.iam.md).
# Migrating your Elastic Beanstalk Linux application to Amazon Linux 2023 or Amazon Linux 2
This section describes how to migrate your application using one of the following migration paths.
+ Migrate from an *Amazon Linux 2* platform branch to an *Amazon Linux 2023* platform branch.
+ Migrate from an *Amazon Linux AMI (AL1)* platform branch to either an *Amazon Linux 2023* (recommended) or an *Amazon Linux 2* platform branch.
**Topics**
+ [Migration from Amazon Linux 2 to Amazon Linux 2023](using-features.migration-al.generic.from-al2.md)
+ [Migration from Amazon Linux AMI (AL1) to AL2 or AL2023](using-features.migration-al.generic.from-al1.md)
# Migration from Amazon Linux 2 to Amazon Linux 2023
This topic provides guidance to migrate your application from an Amazon Linux 2 platform branch to an Amazon Linux 2023 platform branch.
## Differences and compatibility
**Between the Elastic Beanstalk AL2 and AL2023 platforms**
There is a high degree of compatibility between Elastic Beanstalk Amazon Linux 2 and Amazon Linux 2023 platforms. Although there are some differences to note:
+ **Instance Metadata Service Version 1 (IMDSv1)** – The [DisableIMDSv1](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) option setting defaults to `true` on AL2023 platforms. The default is `false` on AL2 platforms.
+ **pkg-repo instance tool** – The [pkg-repo](custom-platforms-scripts.md#custom-platforms-scripts.pkg-repo) tool is not available for environments running on AL2023 platforms. However, you can still manually apply package and operating system updates to an AL2023 instance. For more information, see [Managing packages and operating system updates](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) in the *Amazon Linux 2023 User Guide*.
+ **Apache HTTPd configuration** – The Apache `httpd.conf` file for AL2023 platforms has some configuration settings that are different from those for AL2:
+ Deny access to the server’s entire file system by default. These settings are described in *Protect Server Files by Default* on the Apache website [Security Tips](https://httpd.apache.org/docs/2.4/misc/security_tips.html) page.
+ Deny access to set up of `.htaccess` in all directories, except for those specifically enabled. This setting is described in *Protecting System Settings* on the Apache website [Security Tips](https://httpd.apache.org/docs/2.4/misc/security_tips.html) page. The [Apache HTTP Server Tutorial: .htaccess files ](https://httpd.apache.org/docs/2.4/howto/htaccess.html) page states this setting may help improve performance.
+ Deny access to files with name pattern `.ht*`. This setting prevents web clients from viewing `.htaccess` and `.htpasswd` files.
You can change any of the above configuration settings for your environment. For more information, see [Configuring Apache HTTPD](platforms-linux-extend.proxy.md#platforms-linux-extend.proxy.httpd).
+ **Multiline environment variable support** – AL2023 platforms support multiline values for environment variables and secrets in systemd service configurations. Amazon Linux 2 platforms do not support multiline environment variable values. This enhancement allows you to use multiline secrets and configuration values on AL2023 platforms. For more information about using environment variables and secrets, see [Multiline values in Amazon Linux 2 environment variables](AWSHowTo.secrets.env-vars.md#AWSHowTo.secrets.multiline).
+ **CloudWatch custom log forwarding** – The deprecated CloudWatch Logs agent (`awslogs` package) is not available on AL2023 platforms. If you have custom log forwarding configurations that install and use the deprecated `awslogs` agent, you must update your configuration files to use the unified CloudWatch agent when migrating from Amazon Linux 2 to AL2023. For more information, see [Custom log file streaming](AWSHowTo.cloudwatchlogs.md#AWSHowTo.cloudwatchlogs.streaming.custom).
**Platform-specific differences**
In addition to the base operating system differences, there are platform-specific differences between Amazon Linux 2 and AL2023 runtime platforms:
+ **.NET platform branching** – The .NET platform branching strategy differs between Amazon Linux 2 and AL2023. On Amazon Linux 2, the .NET Core platform maintains a rotating window of .NET major versions within a single platform branch. On AL2023, each platform branch is pinned to a specific .NET major version (for example, .NET 9, .NET 10).
If you deploy framework-dependent applications (applications that rely on the platform's installed .NET runtime), you must select a platform branch that matches your application's target .NET version. If you deploy self-contained applications (applications that bundle their own .NET runtime), you can use any AL2023 .NET platform branch regardless of your application's .NET version, as your application is not dependent on the platform's installed runtime. For more information, see [Bundling applications for the .NET Core on Linux Elastic Beanstalk platform](dotnet-linux-platform-bundle-app.md).
+ **Node.js version selection** – The Node.js platform on Amazon Linux 2 supports specifying a Node.js version in your application's `package.json` file. The Node.js platform on AL2023 does not support this feature. You must use the default Node.js version provided by the platform branch. For more information about Node.js version management, see [Configuring your application's dependencies on Elastic Beanstalk](nodejs-platform-dependencies.md).
+ **Ruby Puma server version** – The Ruby platform on Amazon Linux 2 ignores the Puma version specified in your application's `Gemfile.lock` file and uses the platform default Puma version. The Ruby platform on AL2023 honors the Puma version specified in `Gemfile.lock` if present. If no version is specified, the platform installs the platform default Puma version.
+ **PHP package availability** – Some packages available on Amazon Linux 2 PHP platforms are not available on AL2023 PHP platforms:
+ *MySQL client packages* – The `mysql` and `mysql-devel` command-line client packages are not installed on AL2023 PHP platforms. If your application requires MySQL database connectivity, use the PHP `mysqli` or `pdo_mysql` extensions, which are available on both platforms.
+ *Compass and Ruby tools* – The `ruby-devel` and `rubygems` packages for Compass CSS framework support are not installed on AL2023 PHP platforms. Compass has been deprecated. Consider using modern CSS preprocessing tools as alternatives.
+ **Go version control tools** – The Bazaar version control system (`bzr`) is not available on AL2023 Go platforms. Bazaar is deprecated and not included in the AL2023 package repository. Use Git, Mercurial, or Subversion for version control instead, all of which are available on AL2023 Go platforms.
**Between the Amazon Linux operating systems**
For more information about the differences between the Amazon Linux 2 and Amazon Linux 2023 operating systems, see [Comparing Amazon Linux 2 and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) in the *Amazon Linux 2023 User Guide*.
For more information about Amazon Linux 2023, see [What is Amazon Linux 2023?](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) in the *Amazon Linux 2023 User Guide*.
## General migration process
When you're ready to go to production, Elastic Beanstalk requires a blue/green deployment to perform the upgrade. The following are the general best practice steps that we recommend for migration with a blue/green deployment procedure.
**Preparing to test for your migration**
Before you deploy your application and start testing, review the information in the prior section [Differences and compatibility](#using-features.migration-al.generic.from-al2.differences). Also review the reference cited in that section, [Comparing Amazon Linux 2 and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) in the *Amazon Linux 2023 User Guide*. Make a note of the specific information from this content that applies or may apply to your application and configuration set up.
**High level migration steps**
1. Create a new environment that's based on an AL2023 platform branch.
1. Deploy your application to the target AL2023 environment.
Your existing production environment will remain active and unaffected, while you iterate through testing and making adjustments to the new environment.
1. Test your application thoroughly in the new environment.
1. When your destination AL2023 environment is ready to go to production, swap the CNAMEs of the two environments to redirect traffic to the new AL2023 environment.
**More detailed migration steps and best practices**
For a more detailed blue/green deployment procedure, see [Blue/Green deployments with Elastic Beanstalk](using-features.CNAMESwap.md).
For more specific guidance and detailed best practice steps, see [Blue/Green method](using-features.platform.upgrade.md#using-features.platform.upgrade.bluegreen).
## More references to help plan your migration
The following references can offer additional information to plan your migration.
+ [ Elastic Beanstalk supported platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) in *AWS Elastic Beanstalk Platforms*
+ [Retired platform branch history](platforms-schedule.md#platforms-support-policy.retired)
+ [Elastic Beanstalk Linux platforms](platforms-linux.md)
+ [Platform retirement FAQ](using-features.migration-al.FAQ.md)
# Migration from Amazon Linux AMI (AL1) to AL2 or AL2023
If your Elastic Beanstalk application is based on an Amazon Linux AMI platform branch, use this section to learn how to migrate your application's environments to Amazon Linux 2 or Amazon Linux 2023. Previous generation platform branches based on [Amazon Linux AMI](https://aws.amazon.com/amazon-linux-ami/) are now retired.
We highly recommend that you migrate to Amazon Linux 2023, since it's more recent than Amazon Linux 2. The Amazon Linux 2 operating system will reach end of support before Amazon Linux 2023 does, so you'll benefit from a longer time frame of support if you migrate to Amazon Linux 2023.
It's worthwhile to note that there is a high degree of compatibility between the Elastic Beanstalk Amazon Linux 2 and Amazon Linux 2023 platforms. Although some areas do have differences: the Instance Metadata Service Version 1 (IMDSv1) option default, support for the pkg-repo instance tool, and some Apache HTTPd configuration. For more information, see [Amazon Linux 2023](platforms-linux.md#platforms-linux.versions.al2023)
## Differences and compatibility
The AL2023/AL2 based platform branches aren't guaranteed to be backward compatible with your existing application. It's also important to be aware that even if your application code successfully deploys to the new platform version, it might behave or perform differently due to operating system and run time differences.
Although Amazon Linux AMI and AL2023/AL2 share the same Linux kernel, they differ in the following aspects: their initialization system, the `libc` versions, the compiler tool chain, and various packages. For more information, see [Amazon Linux 2 FAQs](https://aws.amazon.com//amazon-linux-2/faqs/).
The Elastic Beanstalk service has also updated platform specific versions of runtime, build tools, and other dependencies.
Therefore we recommend that you take your time, test your application thoroughly in a development environment, and make any necessary adjustments.
## General migration process
When you're ready to go to production, Elastic Beanstalk requires a blue/green deployment to perform the upgrade. The following are the general best practice steps that we recommend for migration with a blue/green deployment procedure.
**Preparing to test for your migration**
Before you deploy your application and start testing, review the information in [Considerations for all Linux platforms](#using-features.migration-al.generic), which follows later in this topic. Also, review the information that applies to your platform in the [Platform specific considerations](#using-features.migration-al.specific) section that follows. Make a note of the specific information from this content that applies or may apply to your application and configuration set up.
**High level migration steps**
1. Create a new environment that's based on an AL2 or AL2023 platform branch. We recommend that you migrate to an AL2023 platform branch.
1. Deploy your application to the target AL2023/AL2 environment.
Your existing production environment will remain active and unaffected, while you iterate through testing and making adjustments to the new environment.
1. Test your application thoroughly in the new environment.
1. When your destination AL2023/AL2 environment is ready to go to production, swap the CNAMEs of the two environments to redirect traffic to the new environment.
**More detailed migration steps and best practices**
For a more detailed blue/green deployment procedure, see [Blue/Green deployments with Elastic Beanstalk](using-features.CNAMESwap.md).
For more specific guidance and detailed best practice steps, see [Blue/Green method](using-features.platform.upgrade.md#using-features.platform.upgrade.bluegreen).
## More references to help plan your migration
The following references can offer additional information to plan your migration.
+ [Comparing Amazon Linux 2 and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) *Amazon Linux 2023 User Guide*.
+ [What is Amazon Linux 2023?](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) in the *Amazon Linux 2023 User Guide*
+ [ Elastic Beanstalk supported platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) in *AWS Elastic Beanstalk Platforms*
+ [Retired platform branch history](platforms-schedule.md#platforms-support-policy.retired)
+ [Elastic Beanstalk Linux platforms](platforms-linux.md)
+ [Platform retirement FAQ](using-features.migration-al.FAQ.md)
## Considerations for all Linux platforms
The following table discusses considerations you should be aware of when planning an application migration to AL2023/AL2. These considerations apply to any of the Elastic Beanstalk Linux platforms, regardless of specific programming languages or application servers.
| **Area** | **Changes and information** |
| --- | --- |
| Configuration Files | On AL2023/AL2 platforms, you can use [configuration files](ebextensions.md) as before, and all sections work the same way. However, specific settings might not work the same as they did on previous Amazon Linux AMI platforms. For example: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) We recommend using platform hooks to run custom code on your environment instances. You can still use commands and container commands in `.ebextensions` configuration files, but they aren't as easy to work with. For example, writing command scripts inside a YAML file can be cumbersome and difficult to test. You still need to use `.ebextensions` configuration files for any script that needs a reference to an AWS CloudFormation resource. |
| Platform hooks | AL2 platforms introduced a new way to extend your environment's platform by adding executable files to hook directories on the environment's instances. With previous Linux platform versions, you might have used custom platform hooks. These hooks weren't designed for managed platforms and weren't supported, but could work in useful ways in some cases. With AL2023/AL2 platform versions, custom platform hooks don't work. You should migrate any hooks to the new platform hooks. For details see [Platform hooks](platforms-linux-extend.hooks.md). |
| Supported proxy servers | AL2023/AL2 platform versions support the same reverse proxy servers as each platform supported in its Amazon Linux AMI platform versions. All AL2023/AL2; platform versions use nginx as their default reverse proxy server, with the exception of the ECS and Docker platforms. The Tomcat, Node.js, PHP, and Python platform also support Apache HTTPD as an alternative. All platforms enable proxy server configuration in a uniform way, as described in this section. However, configuring the proxy server is slightly different than it was on Amazon Linux AMI. These are the differences for all platforms: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) For platform-specific proxy configuration changes, see [Platform specific considerations](#using-features.migration-al.specific). For information about proxy configuration on AL2023/AL2 platforms, see [Reverse proxy configuration](platforms-linux-extend.proxy.md). |
| Proxy Configuration Changes | There are proxy configuration changes that apply uniformly to all platforms in addition to proxy configuration changes that are specific to each platform. It's important to refer to both to accurately configure your environments. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) |
| Instance profile | AL2023/AL2 platforms require an instance profile to be configured. Environment creation might temporarily succeed without one, but the environment might show errors soon after creation when actions requiring an instance profile start failing. For details, see [Managing Elastic Beanstalk instance profiles](iam-instanceprofile.md). |
| Enhanced health | AL2023/AL2 platform versions enable enhanced health by default. This is a change if you don't use the Elastic Beanstalk console to create your environments. The console enables enhanced health by default whenever possible, regardless of platform version. For details, see [Enhanced health reporting and monitoring in Elastic Beanstalk](health-enhanced.md). |
| Custom AMI | If your environment uses a [custom AMI](using-features.customenv.md), create a new AMI based on AL2023/AL2 for your new environment using an Elastic Beanstalk AL2023/AL2 platform. |
| Custom platforms | The managed AMIs of AL2023/AL2 platform versions don't support custom platforms. |
## Platform specific considerations
This section discusses migration considerations specific to particular Elastic Beanstalk Linux platforms.
### Docker
The Docker platform branch family based on Amazon Linux AMI (AL1) includes three platform branches. We recommend a different migration path for each.
| **AL1 Platform branch** | **Migration Path to AL2023/AL2** |
| --- | --- |
| **Area** | **Changes and information** |
| --- | --- |
| Multi-container Docker managed by Amazon ECS running on Amazon Linux AMI (AL1) | ECS based Docker AL2023/AL2 platform branches The *ECS based Docker AL2023/AL2* platform branches offer a straightforward migration path for environments running on the *Multi-container Docker AL1* platform branch. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) For more information about migrating your applications running on the *Multi-container Docker Amazon Linux* platform branch to an *Amazon ECS running on AL2023/AL2* platform branch, see [Migrating your Elastic Beanstalk application from ECS managed Multi-container Docker on AL1 to ECS on Amazon Linux 2023](migrate-to-ec2-AL2-platform.md). |
| Docker running on Amazon Linux AMI (AL1) Preconfigured Docker (Glassfish 5.0) running Amazon Linux AMI (AL1) | Docker Running on AL2023/AL2 platform branch We recommend that you migrate your applications running on environments based on *Preconfigured Docker (Glassfish 5.0)* or *Docker running on Amazon Linux AMI (AL1) * to environments that are based on the *Docker Running on Amazon Linux 2* or *Docker Running on AL2023* platform branches. If your environment is based on the *Preconfigured Docker (Glassfish 5.0)* platform branch, see [Deploying a GlassFish application to the Docker platform: a migration path to Amazon Linux 2023](create_deploy_dockerpreconfig.md#docker-glassfish-tutorial). The following table lists migration information specific to the platform branch *Docker Running on AL2023/AL2*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) |
| Storage | Elastic Beanstalk configures Docker to use [storage drivers](https://docs.docker.com/storage/storagedriver/) to store Docker images and container data. On Amazon Linux AMI, Elastic Beanstalk used the [Device Mapper storage driver](https://docs.docker.com/storage/storagedriver/device-mapper-driver/). To improve performance, Elastic Beanstalk provisioned an extra Amazon EBS volume. On AL2023/AL2 Docker platform versions, Elastic Beanstalk uses the [OverlayFS storage driver](https://docs.docker.com/storage/storagedriver/overlayfs-driver/), and achieves even better performance while not requiring a separate volume anymore. With Amazon Linux AMI, if you used the `BlockDeviceMappings` option of the `aws:autoscaling:launchconfiguration` namespace to add custom storage volumes to a Docker environment, we advised you to also add the `/dev/xvdcz` Amazon EBS volume that Elastic Beanstalk provisions. Elastic Beanstalk doesn't provision this volume anymore, so you should remove it from your configuration files. For details, see [Docker configuration on Amazon Linux AMI (preceding Amazon Linux 2)](create_deploy_docker.container.console.md#docker-alami). |
| Private repository authentication | When you provide a Docker-generated authentication file to connect to a private repository, you no longer need to convert it to the older format that Amazon Linux AMI Docker platform versions required. AL2023/AL2 Docker platform versions support the new format. For details, see [Authenticating with image repositories](docker-configuration.remote-repo.md). |
| Proxy server | AL2023/AL2 Docker platform versions don't support standalone containers that don't run behind a proxy server. On Amazon Linux AMI Docker platform versions, this used to be possible through the `none` value of the `ProxyServer` option in the `aws:elasticbeanstalk:environment:proxy` namespace. |
### Go
The following table lists migration information for the AL2023/AL2 platform versions in the [Go platform](go-environment.md).
| **Area** | **Changes and information** |
| --- | --- |
| Port passing | On AL2023/AL2 platforms, Elastic Beanstalk doesn't pass a port value to your application process through the `PORT` environment variable. You can simulate this behavior for your process by configuring a `PORT` environment property yourself. However, if you have multiple processes, and you're counting on Elastic Beanstalk passing incremental port values to your processes (5000, 5100, 5200 etc.), you should modify your implementation. For details see [Reverse proxy configuration](platforms-linux-extend.proxy.md). |
### Amazon Corretto
The following table lists migration information for the Corretto platform branches in the [Java SE platform](java-se-platform.md).
| **Area** | **Changes and information** |
| --- | --- |
| Corretto vs. OpenJDK | To implement the Java Platform, Standard Edition (Java SE), AL2023/AL2 platform branches use [Amazon Corretto](https://aws.amazon.com/corretto), an AWS distribution of the Open Java Development Kit (OpenJDK). Prior Elastic Beanstalk Java SE platform branches use the OpenJDK packages included with Amazon Linux AMI. |
| Build tools | AL2023/AL2 platforms have newer versions of the build tools: `gradle`, `maven`, and `ant`. |
| JAR file handling | On AL2023/AL2 platforms, if your source bundle (ZIP file) contains a single JAR file and no other files, Elastic Beanstalk no longer renames the JAR file to `application.jar`. Renaming occurs only if you submit a JAR file on its own, not within a ZIP file. |
| Port passing | On AL2023/AL2 platforms, Elastic Beanstalk doesn't pass a port value to your application process through the `PORT` environment variable. You can simulate this behavior for your process by configuring a `PORT` environment property yourself. However, if you have multiple processes, and you're counting on Elastic Beanstalk passing incremental port values to your processes (5000, 5100, 5200 etc.), you should modify your implementation. For details see [Reverse proxy configuration](platforms-linux-extend.proxy.md). |
| Java 7 | Elastic Beanstalk doesn't support an AL2023/AL2 Java 7 platform branch. If you have a Java 7 application, migrate it to Corretto 8 or Corretto 11. |
### Tomcat
The following table lists migration information for the AL2023/AL2 platform versions in the [Tomcat platform](java-tomcat-platform.md).
| **Area** | **Changes and information** |
| --- | --- |
| **Option** | **Migration information** |
| --- | --- |
| Configuration options | On AL2023/AL2 platform versions, Elastic Beanstalk supports only a subset of the configuration options and option values in the `aws:elasticbeanstalk:environment:proxy` namespace. Here's the migration information for each option. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) The `XX:MaxPermSize` option in the `aws:elasticbeanstalk:container:tomcat:jvmoptions` namespace isn't supported on AL2023/AL2 platform versions. The JVM setting to modify the size of the permanent generation applies only to Java 7 and earlier, and is therefore not applicable to AL2023/AL2 platform versions. |
| Application path | On AL2023/AL2 platforms, the path to the application's directory on Amazon EC2 instances of your environment is `/var/app/current`. It was `/var/lib/tomcat8/webapps` on Amazon Linux AMI platforms. |
| `GzipCompression` | Unsupported on AL2023/AL2 platform versions. |
| `ProxyServer` | AL2023/AL2 Tomcat platform versions support both the nginx and the Apache HTTPD version 2.4 proxy servers. However, Apache version 2.2 isn't supported. On Amazon Linux AMI platform versions, the default proxy was Apache 2.4. If you used the default proxy setting and added custom proxy configuration files, your proxy configuration should still work on AL2023/AL2. However, if you used the `apache/2.2` option value, you now have to migrate your proxy configuration to Apache version 2.4. |
### Node.js
The following table lists migration information for the AL2023/AL2 platform versions in the [Node.js platform](create_deploy_nodejs.container.md).
| **Area** | **Changes and information** |
| --- | --- |
| **Option** | **Migration information** |
| --- | --- |
| Installed Node.js versions | On AL2023/AL2 platforms, Elastic Beanstalk maintains several Node.js platform branches, and only installs the latest version of the Node.js major version corresponding with the platform branch on each platform version. For example, each platform version in the Node.js 12 platform branch only has Node.js 12.x.y installed by default. On Amazon Linux AMI platform versions, we installed the multiple versions of multiple Node.js versions on each platform version, and only maintained a single platform branch. Choose the Node.js platform branch that corresponds with the Node.js major version that your application needs. |
| Apache HTTPD log file names | On AL2023/AL2 platforms, if you use the Apache HTTPD proxy server, the HTTPD log file names are `access_log` and `error_log`, which is consistent with all other platforms that support Apache HTTPD. On Amazon Linux AMI platform versions, these log files were named `access.log` and `error.log`, respectively. For details about log file names and locations for all platforms, see [How Elastic Beanstalk sets up CloudWatch Logs](AWSHowTo.cloudwatchlogs.md#AWSHowTo.cloudwatchlogs.loggroups). |
| Configuration options | On AL2023/AL2 platforms, Elastic Beanstalk doesn't support the configuration options in the `aws:elasticbeanstalk:container:nodejs` namespace. Some of the options have alternatives. Here's the migration information for each option. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) |
| `NodeCommand` | Use a `Procfile` or the `scripts` keyword in a `package.json` file to specify the start script. |
| `NodeVersion` | Use the `engines` keyword in a `package.json` file to specify the Node.js version. Be aware that you can only specify a Node.js version that correspondes with your platform branch. For example, if you're using the Node.js 12 platform branch, you can specify only a 12.x.y Node.js version. For details, see [Specifying Node.js dependencies with a package.json file](nodejs-platform-dependencies.md#nodejs-platform-packagejson). |
| `GzipCompression` | Unsupported on AL2023/AL2 platform versions. |
| `ProxyServer` | On AL2023/AL2 Node.js platform versions, this option moved to the `aws:elasticbeanstalk:environment:proxy` namespace. You can choose between `nginx` (the default) and `apache`. AL2023/AL2 Node.js platform versions don't support standalone applications that don't run behind a proxy server. On Amazon Linux AMI Node.js platform versions, this used to be possible through the `none` value of the `ProxyServer` option in the `aws:elasticbeanstalk:container:nodejs` namespace. If your environment runs a standalone application, update your code to listen to the port that the proxy server (nginx or Apache) forwards traffic to. var port = process.env.PORT || 5000;
app.listen(port, function() {
console.log('Server running at http://127.0.0.1:%s', port);
});
|
### PHP
The following table lists migration information for the AL2023/AL2 platform versions in the [PHP platform](create_deploy_PHP.container.md).
| **Area** | **Changes and information** |
| --- | --- |
| PHP file processing | On AL2023/AL2 platforms, PHP files are processed using PHP-FPM (a CGI process manager). On Amazon Linux AMI platforms we used mod\$1php (an Apache module). |
| Proxy server | AL2023/AL2 PHP platform versions support both the nginx and the Apache HTTPD proxy servers. The default is nginx. Amazon Linux AMI PHP platform versions supported only Apache HTTPD. If you added custom Apache configuration files, you can set the `ProxyServer` option in the `aws:elasticbeanstalk:environment:proxy` namespace to `apache`. |
### Python
The following table lists migration information for the AL2023/AL2 platform versions in the [Python platform](create-deploy-python-container.md).
| **Area** | **Changes and information** |
| --- | --- |
| WSGI server | On AL2023/AL2 platforms, [Gunicorn](https://gunicorn.org/) is the default WSGI server. By default, Gunicorn listens on port 8000. The port might be different than what your application used on the Amazon Linux AMI platform. If you're setting the `WSGIPath` option of the `[aws:elasticbeanstalk:container:python](command-options-specific.md#command-options-python)` namespace, replace the value with Gunicorn's syntax. For details, see [Python configuration namespaces](create-deploy-python-container.md#python-namespaces). Alternatively, you can use a `Procfile` to specify and configure the WSGI server. For details, see [Configuring the WSGI server with a Procfile on Elastic Beanstalk](python-configuration-procfile.md). |
| Application path | On AL2023/AL2 platforms, the path to the application's directory on Amazon EC2 instances of your environment is `/var/app/current`. It was `/opt/python/current/app` on Amazon Linux AMI platforms. |
| Proxy server | AL2023/AL2 Python platform versions support both the nginx and the Apache HTTPD proxy servers. The default is nginx. Amazon Linux AMI Python platform versions supported only Apache HTTPD. If you added custom Apache configuration files, you can set the `ProxyServer` option in the `aws:elasticbeanstalk:environment:proxy` namespace to `apache`. |
### Ruby
The following table lists migration information for the AL2023/AL2 platform versions in the [Ruby platform](create_deploy_Ruby.container.md).
| **Area** | **Changes and information** |
| --- | --- |
| Installed Ruby versions | On AL2023/AL2 platforms, Elastic Beanstalk only installs the latest version of a single Ruby version, corresponding with the platform branch, on each platform version. For example, each platform version in the Ruby 2.6 platform branch only has Ruby 2.6.x installed. On Amazon Linux AMI platform versions, we installed the latest versions of multiple Ruby versions, for example, 2.4.x, 2.5.x, and 2.6.x. If your application uses a Ruby version that doesn't correspond to the platform branch you're using, we recommend that you switch to a platform branch that has the correct Ruby version for your application. |
| Application server | On AL2023/AL2 platforms, Elastic Beanstalk only installs the Puma application server on all Ruby platform versions. You can use a `Procfile` to start a different application server, and a `Gemfile` to install it. On the Amazon Linux AMI platform, we supported two flavors of platform branches for each Ruby version—one with the Puma application server and the other with the Passenger application server. If your application uses Passenger, you can configure your Ruby environment to install and use Passenger. For more information and examples, see [Using the Elastic Beanstalk Ruby platform](create_deploy_Ruby.container.md). |
# Platform retirement FAQ
**Note**
Elastic Beanstalk retired all platform branches based on Amazon Linux AMI (AL1) on July 18, 2022 .
The answers in this FAQ reference the following topics:
+ [Elastic Beanstalk platform support policy](platforms-support-policy.md)
+ [Retired platform branch history](platforms-schedule.md#platforms-support-policy.retired)
+ [ Elastic Beanstalk supported platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) in *AWS Elastic Beanstalk Platforms*
+ [Migrating your Elastic Beanstalk Linux application to Amazon Linux 2023 or Amazon Linux 2](using-features.migration-al.md)
+ [Amazon Linux 2 FAQs](https://aws.amazon.com//amazon-linux-2/faqs/).
## 1. What does retirement of a platform branch mean?
Following the announced retirement date of a platform branch, you will no longer be able to create a new environment based on the retired platform branch, unless you already have an active environment based on that platform branch. For more information, see [FAQ \$111](#using-features.migration-al.FAQ.new-env-create). Elastic Beanstalk will stop providing new maintenance updates for these platform branches. A retired platform branch isn't recommended for use in production environments. For more information, see [FAQ \$15](#using-features.migration-al.FAQ.remove-components).
## 2. Why has AWS retired the AL1-based platforms branches?
Elastic Beanstalk retires platform branches when platform components are deprecated or retired by their vendors. In this case, the Amazon Linux AMI (AL1) has ended standard support as of [December 31, 2020](https://aws.amazon.com/blogs/aws/update-on-amazon-linux-ami-end-of-life/). While Elastic Beanstalk continued to offer AL1 based platforms through 2022, we have since released AL2 and AL2023 and based platforms that have the latest features. In order for customers to continue to benefit from the latest security and features going forward, it's critical for customers to migrate to our AL2 or AL2023 based platforms.
## 3. Which platform branches are retired?
For a list of platform components and platform branches that have been retired, see [Retired platform branch history](platforms-schedule.md#platforms-support-policy.retired).
## 4. Which platforms are currently supported?
See [ Elastic Beanstalk supported platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) in *AWS Elastic Beanstalk Platforms*.
## 5. Will Elastic Beanstalk remove or terminate any components of my environment after retirement?
Our policy for retired platform branches does not remove access to environments nor delete resources. However, an environment based on a retired platform branch can end up in an unpredictable situation, because Elastic Beanstalk isn't able to provide security updates, technical support, or hotfixes for retired platform branches due to the supplier marking their component as End of Life (EOL). For example, a detrimental and critical security vulnerability may surface in an environment running on a retired platform branch. Or an EB API action may stop working for the environment if it becomes incompatible with the Elastic Beanstalk service over time. The opportunity for these types of risks increases the longer an environment based on a retired platform branch remains active.
If your application should encounter issues while running on a retired platform branch and you're not able to migrate it to a supported platform, you'll need to consider other alternatives. Workarounds include encapsulating the application into a Docker image to run it as a Docker container. This would allow a customer to use any of our Docker solutions, such as our Elastic Beanstalk AL2023/AL2 Docker platforms, or other Docker based services such as Amazon ECS or Amazon EKS. Non-Docker alternatives include our AWS CodeDeploy service, which allows complete customization of the runtimes you desire.
## 6. Can I submit a request to extend the retirement date?
No. After the retirement date existing environments will continue to function. However, Elastic Beanstalk will no longer provide platform maintenance and security updates. Therefore, it’s critical to migrate to AL2 or AL2023 if you are still running applications on an AL1-based platform. For more information about risks and workarounds, see [FAQ \$15](#using-features.migration-al.FAQ.remove-components).
## 7. What are the workarounds if I can't complete my AL2 or AL2023 migration in time?
Customers may continue to run the environment, although we strongly encourage you to plan to migrate all of your Elastic Beanstalk environments to a supported platform version. Doing so will minimize risk and provide continued benefit from important security, performance, and functionality enhancements offered in more recent releases. For more information about risks and workarounds, see [FAQ \$15](#using-features.migration-al.FAQ.remove-components).
## 8. What is the recommended process to migrate to AL2 or AL2023 platforms?
For comprehensive AL1 to AL2023/AL2 migration instructions, see [Migrating your Elastic Beanstalk Linux application to Amazon Linux 2023 or Amazon Linux 2](using-features.migration-al.md). This topic explains that Elastic Beanstalk requires a blue/green deployment to perform the upgrade.
## 9. If I have an environment running on a retired platform, what would be the impact?
An environment based on a retired platform branch can end up in an unpredictable situation, because Elastic Beanstalk isn't able to provide security updates, technical support, or hotfixes for retired platform branches due to the supplier marking their component as End of Life (EOL). For example, a detrimental and critical security vulnerability may surface in an environment running on a retired platform branch. Or an EB API action may stop working for the environment if it becomes incompatible with the Elastic Beanstalk service over time. The opportunity for these types of risks increases the longer an environment on a retired platform branch remains active. For more information, see [FAQ \$15](#using-features.migration-al.FAQ.remove-components).
## 10. What happens 90 days after the retirement date?
Our policy for retired platform branches does not remove access to environments nor delete resources. However, be aware that an environment based on a retired platform branch can end up in an unpredictable situation, because Elastic Beanstalk isn't able to provide security updates, technical support, or hotfixes for retired platform branches due to the supplier marking their component as End of Life (EOL). For example, a detrimental and critical security vulnerability may surface in an environment running on a retired platform branch. Or an EB API action may stop working for the environment if it becomes incompatible with the Elastic Beanstalk service over time. The opportunity for these types of risks increases the longer an environment on a retired platform branch remains active. For more information see [FAQ \$15](#using-features.migration-al.FAQ.remove-components).
## 11. Can I create a new environment based on a retired platform?
You can create a new environment based on a retired platform branch, if you've already used that platform branch to create an existing environment using the same account and in the same region. The retired platform branch will not be available in the Elastic Beanstalk console. However, for customers that have existing environments based on a retired platform branch, it will be available through the EB CLI, EB API, and AWS CLI. Also, existing customers can use the [Clone environment](using-features.managing.clone.md) and [Rebuild environment](environment-management-rebuild.md) consoles. However, be aware that an environment based on a retired platform branch can end up in an unpredictable situation. For more information, see [FAQ \$15](#using-features.migration-al.FAQ.remove-components).
## 12. If I have an existing environment running on a retired platform branch, until when can I create a new environment based on the retired platform branch? Can I do so using the console, CLI or API?
You can create the environment after the retirement date. However, keep in mind that a retired platform branch can end up in an unpredictable situation. The further out in time such an environment an environment is created or active, the higher the risk for the environment to encounter unexpected issues. For more information about creating a new environment, see [FAQ \$111](#using-features.migration-al.FAQ.new-env-create).
## 13. Can I clone or rebuild my environment which is based on retired platform?
Yes. You can do so using the [Clone environment](using-features.managing.clone.md) and [Rebuild environment](environment-management-rebuild.md) consoles. You can also use the EB CLI, EB API, and AWS CLI. For more information about creating a new environment, see [FAQ \$111](#using-features.migration-al.FAQ.new-env-create).
However, we strongly encourage you to plan to migrate all your Elastic Beanstalk environments to a supported platform version. Doing so will minimize risk and provide continued benefit from important security, performance, and functionality enhancements offered in more recent releases. For more information about risks and workarounds, see [FAQ \$15](#using-features.migration-al.FAQ.remove-components).
## 14. After the retirement date, what would happen to the AWS resources of my Elastic Beanstalk environment that is based on a retired platform branch? For example, if the running EC2 instance gets terminated, would Elastic Beanstalk be able to launch a new AL1 based EC2 instance to maintain capacity?
The environment’s resources would remain active and continue to function. And, yes, Elastic Beanstalk will auto scale for AL1 EC2 instances in the environment. However, Elastic Beanstalk will stop providing new platform maintenance updates to the environment, which can lead to the environment ending up in an unpredictable situation over time. For more information, see [FAQ \$15](#using-features.migration-al.FAQ.remove-components).
## 15. What are key differences between the AL2023/AL2 and Amazon Linux AMI (AL1) operating systems? How are the Elastic Beanstalk AL2023/AL2 platform branches affected?
Although Amazon Linux AMI and AL2023/AL2 share the same Linux kernel, they differ in their initialization system, `libc` versions, the compiler tool chain, and various packages. For more information, see [Amazon Linux 2 FAQs](https://aws.amazon.com//amazon-linux-2/faqs/).
The Elastic Beanstalk service has also updated platform specific versions of runtime, build tools, and other dependencies. The AL2023/AL2 based platform branches aren't guaranteed to be backward compatible with your existing application. Furthermore, even if your application code successfully deploys to the new platform version, it might behave or perform differently due to operating system and run time differences. For a list and description of configurations and customizations that you'll need to review and test, see [Migrating your Elastic Beanstalk Linux application to Amazon Linux 2023 or Amazon Linux 2](using-features.migration-al.md).