# Elastic Beanstalk platforms
AWS Elastic Beanstalk provides a variety of platforms on which you can build your applications. You design your web application to one of these platforms, and Elastic Beanstalk deploys your code to the platform version you selected to create an active application environment.
Elastic Beanstalk provides platforms for different programming languages, application servers, and Docker containers. Some platforms have multiple concurrently-supported versions.
**Topics**
+ [
# Elastic Beanstalk platforms glossary
](platforms-glossary.md)
+ [
# Shared responsibility model for Elastic Beanstalk platform maintenance
](platforms-shared-responsibility.md)
+ [
# Elastic Beanstalk platform support policy
](platforms-support-policy.md)
+ [
# Elastic Beanstalk platform release schedule
](platforms-schedule.md)
+ [
# Elastic Beanstalk supported platforms
](concepts.platforms.md)
+ [
# Elastic Beanstalk Linux platforms
](platforms-linux.md)
+ [
# Extending Elastic Beanstalk Linux platforms
](platforms-linux-extend.md)
# Elastic Beanstalk platforms glossary
Following are key terms related to AWS Elastic Beanstalk platforms and their lifecycle.
**Runtime**
The programming language-specific runtime software (framework, libraries, interpreter, vm, etc.) required to run your application code.
**Elastic Beanstalk Components**
Software components that Elastic Beanstalk adds to a platform to enable Elastic Beanstalk functionality. For example, the enhanced health agent is necessary for gathering and reporting health information.
**Platform**
A combination of an operating system (OS), runtime, web server, application server, and Elastic Beanstalk components. Platforms provide components that are available to run your application.
**Platform Version**
A combination of specific versions of an operating system (OS), runtime, web server, application server, and Elastic Beanstalk components. You create an Elastic Beanstalk environment based on a platform version and deploy your application to it.
A platform version has a semantic version number of the form *X.Y.Z*, where *X* is the major version, *Y* is the minor version, and *Z* is the patch version.
A platform version can be in one of the following states:
+ *Recommended* – The latest platform version in a supported platform branch. This version contains the most up-to-date components and is recommended for use in production environments. When Elastic Beanstalk releases a new platform version, the new version supersedes the previous version and becomes the recommended platform version for the corresponding platform branch.
+ *Not Recommended* – Any platform version that is not the latest version in its platform branch. While these versions may remain functional, we strongly recommend updating to the latest platform version. You can use [managed platform updates](environment-platform-update-managed.md) to help stay up-to-date automatically.
You can verify if a platform version is recommended using the AWS CLI command **[describe-platform-version](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/describe-platform-version.html)** and checking the `PlatformLifecycleState` field.
**Platform Branch**
A line of platform versions sharing specific (typically major) versions of some of their components, such as the operating system (OS), runtime, or Elastic Beanstalk components. For example: *Python 3.13 running on 64bit Amazon Linux 2023*; *IIS 10.0 running on 64bit Windows Server 2025*. Platform branches receive updates in the form of new platform versions. Each successive platform version in a branch is an update to the previous one.
The recommended version in each supported platform branch is available to you unconditionally for environment creation. Previous platform versions remain accessible to accounts with active or terminated environments using them at the time they were superseded by a new version. Previous platform versions lack the most up-to-date components and aren't recommended for use.
If you need access to previous platform versions beyond the standard availability described above, you can reach out to the [AWS Support Center](https://console.aws.amazon.com/support/home#/) for assistance.
A platform branch can be in one of the following states:
+ *Supported* – A current platform branch. It consists entirely of *supported components*. Supported components have not reached End of Life (EOL), as designated by their suppliers. It receives ongoing platform updates, and is recommended for use in production environments. For a list of supported platform branches, see [Elastic Beanstalk supported platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) in the *AWS Elastic Beanstalk Platforms* guide.
+ *Beta* – A preview, pre-release platform branch. It's experimental in nature. It may receive ongoing platform updates for a while, but has no long-term support. A beta platform branch isn't recommended for use in production environments. Use it only for evaluation. For a list of beta platform branches, see [Elastic Beanstalk Platform Versions in Public Beta](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-beta.html) in the *AWS Elastic Beanstalk Platforms* guide.
+ *Deprecated* – A platform branch where one or more components (such as the runtime or operating system) are approaching End of Life (EOL) or have reached EOL, as designated by their suppliers. While a deprecated platform branch continues to receive new platform versions until its retirement date, components that have reached EOL don't receive updates. For example, if a runtime version reaches EOL, the platform branch will be marked as deprecated but will continue to receive operating system updates until the platform branch retirement date. The platform branch will not continue to receive updates to the EOL runtime version. A deprecated platform branch isn't recommended for use.
+ *Retired* – A platform branch that no longer receives any updates. Retired platform branches aren't available to create new Elastic Beanstalk environments using the Elastic Beanstalk console. If your environment uses a retired platform branch, you must update to a supported platform branch to continue receiving updates. A retired platform branch isn't recommended for use. For more details about retired platform branches, see [Elastic Beanstalk platform support policy](platforms-support-policy.md). For a list of platform branches scheduled for retirement, see [Retiring platform branch schedule](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-schedule.html#platforms-support-policy.depracation). To see past retired platform branches, see [Retired platform branch history](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-schedule.html#platforms-support-policy.retired).
If your environment uses a deprecated or retired platform branch, we recommend that you update it to a platform version in a supported platform branch. For details, see [Updating your Elastic Beanstalk environment's platform version](using-features.platform.upgrade.md).
You can verify the state of a platform branch using the AWS CLI command **[describe-platform-version](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/describe-platform-version.html)** and checking the `PlatformBranchLifecycleState` field.
**Platform Update**
A release of a new platform version that contains updates to some components of the platform—OS, runtime, web server, application server, and Elastic Beanstalk components. When Elastic Beanstalk releases a new platform version, the new version supersedes the previous version and becomes the recommended platform version for the corresponding platform branch. Platform updates follow semantic version taxonomy, and can have three levels:
+ *Major update* – An update that has changes that are incompatible with existing platform versions. You may need to modify your application to run correctly on a new major version. A major update has a new major platform version number.
+ *Minor update* – An update that has changes that are backward compatible with existing platform versions in most cases. Depending on your application, you may need to modify your application to run correctly on a new minor version. A minor update has a new minor platform version number.
+ *Patch update* – An update that consists of maintenance releases (bug fixes, security updates, and performance improvements) that are backward compatible with an existing platform version. A patch update has a new patch platform version number.
**Managed Updates**
An Elastic Beanstalk feature that automatically applies patch and minor updates to the operating system (OS), runtime, web server, application server, and Elastic Beanstalk components for an Elastic Beanstalk supported platform version. A managed update applies a newer platform version in the same platform branch to your environment. You can configure managed updates to apply only patch updates, or minor and patch updates. You can also disable managed updates completely.
For more information, see [Managed platform updates](environment-platform-update-managed.md).
# Shared responsibility model for Elastic Beanstalk platform maintenance
AWS and our customers share responsibility for achieving a high level of software component security and compliance. This shared model reduces your operational burden.
For details, see the AWS [Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/).
AWS Elastic Beanstalk helps you perform your side of the shared responsibility model by providing a *managed updates* feature. This feature automatically applies patch and minor updates for an Elastic Beanstalk supported platform version. If a managed update fails, Elastic Beanstalk notifies you of the failure to ensure that you are aware of it and can take immediate action.
For more information, see [Managed platform updates](environment-platform-update-managed.md).
In addition, Elastic Beanstalk does the following:
+ Publishes its [platform support policy](platforms-support-policy.md) and retirement schedule for the coming 12 months.
+ Releases patch, minor, and major updates of operating system (OS), runtime, application server, and web server components typically within 30 days of their availability. Elastic Beanstalk is responsible for creating updates to Elastic Beanstalk components that are present on its supported platform versions. All other updates come directly from their suppliers (owners or community).
We announce all updates to our supported platforms in our [release notes](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/relnotes.html) in the *AWS Elastic Beanstalk Release Notes* guide. We also provide a list of all supported platforms and their components, along with a platform history, in the *AWS Elastic Beanstalk Platforms* guide. For more information see [Supported platforms and component history](concepts.platforms.md#concepts.platforms.list).
You are responsible to do the following:
+ Update all the components that you control (identified as **Customer** in the AWS [Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/)). This includes ensuring the security of your application, your data, and any components that your application requires and that you downloaded.
+ Ensure that your Elastic Beanstalk environments are running on a supported platform version, and migrate any environment running on a retired platform version to a supported version.
+ If you’re using a custom Amazon machine image (AMI) for your Elastic Beanstalk environment, patch, maintain, and test your custom AMI so that it remains current and compatible with a supported Elastic Beanstalk platform version. For more information about managing environments with a custom AMI, see [Using a custom Amazon machine image (AMI) in your Elastic Beanstalk environment](using-features.customenv.md).
+ Resolve all issues that come up in failed managed update attempts and retry the update.
+ Patch the OS, runtime, application server, and web server yourself if you opted out of Elastic Beanstalk managed updates. You can do this by [applying platform updates manually](using-features.platform.upgrade.md) or directly patching the components on all relevant environment resources.
+ Manage the security and compliance of any AWS services that you use outside of Elastic Beanstalk according to the AWS [Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/).
# Elastic Beanstalk platform support policy
Elastic Beanstalk supports platform branches that still receive ongoing minor and patch updates from their suppliers (owners or community). For a complete definition of related terms, see [Elastic Beanstalk platforms glossary](platforms-glossary.md).
## Retired platform branches
When a component of a supported platform branch is marked End of Life (EOL) by its supplier, Elastic Beanstalk marks the platform branch as retired. Components of a platform branch include the following: operating system (OS), runtime language version, application server, or web server.
Once a platform branch is marked as retired the following policies apply:
+ Elastic Beanstalk stops providing maintenance updates, including security updates.
+ Elastic Beanstalk no longer provides technical support for retired platform branches.
+ Elastic Beanstalk no longer makes the platform branch available to new Elastic Beanstalk customers for deployments to new environments. There is a 90 day grace period from the published retirement date for existing customers with active environments that are running on retired platform branches.
**Note**
A retired platform branch will not be available in the Elastic Beanstalk console. However, it will be available through the AWS CLI, EB CLI and EB API for customers that have existing environments based on the retired platform branch. Existing customers can also use the [Clone environment](using-features.managing.clone.md) and [Rebuild environment](environment-management-rebuild.md) consoles.
For a list of platform branches that are scheduled for retirement see the [Retiring platform branch schedule](platforms-schedule.md#platforms-support-policy.depracation) in the *Elastic Beanstalk platform schedule* topic that follows.
For more information about what to expect when your environment’s platform branch retires, see [Platform retirement FAQ](using-features.migration-al.FAQ.md).
## Beyond the 90 day grace period
Our policy for retired platform branches does not remove access to environments nor delete resources. However, existing customers running an Elastic Beanstalk environment on a retired platform branch should be aware of the risks of doing so. Such environments 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 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. To continue to benefit from important security, performance, and functionality enhancements offered by component suppliers in more recent releases, we strongly encourage you to update all your Elastic Beanstalk environments to a supported platform version.
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.
# Elastic Beanstalk platform release schedule
In addition to the monthly cadence release of new platform branch versions, our release maintenance also includes the following processes:
+ *Release of new platform branches* – These typically introduce a new major version of a run-time language, operating system or application server.
+ *Retirement of platform branches* – We must retire a platform branch when one of its components reaches End of Life (EOL). For more information about our policy for retired branches, see [Elastic Beanstalk platform support policy](platforms-support-policy.md)
**Topics**
+ [
## Planning resources
](#platforms-support-policy.resources)
+ [
## Upcoming platform branch releases
](#platforms-support-policy.upcoming-releases)
+ [
## Retiring platform branch schedule
](#platforms-support-policy.depracation)
+ [
## Retired platform branch history
](#platforms-support-policy.retired)
+ [
## Retired server and operating system history
](#platforms-support-policy.retired.components)
## Planning resources
The following resources can help you plan maintenance and support for your application running on an Elastic Beanstalk platform.
+ [AWS Elastic Beanstalk Platforms guide](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/welcome.html) — This guide provides a detailed component list for each of our platform branches. It also provides a platform history by release date with the same details. This guide can inform you when specific components of your platform branch changed. If your application starts behaving differently, you can also cross-reference the date of the occurrence in the platforms guide to see if there were any platform changes that might have affected your application.
+ [AWS Elastic Beanstalk Release Notes](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/relnotes.html) — Our Release Notes announce all of our platform releases, both minor and major. This includes our monthly platform updates, security releases, hotfixes, and retirement announcements. You can subscribe to our RSS feeds from the Release Notes documentation.
## Upcoming platform branch releases
The following table lists upcoming Elastic Beanstalk platform branches and their target release date. These dates are tentative and subject to change.
| Runtime version / platform branch | Operating System | Target release date |
| --- | --- | --- |
| Python 3.15 | Amazon Linux 2023 | November 2026 |
| Node.js 26 | Amazon Linux 2023 | November 2026 |
| .NET 11 | Amazon Linux 2023 | December 2026 |
| PHP 8.6 | Amazon Linux 2023 | January 2027 |
| Ruby 4.1 | Amazon Linux 2023 | February 2027 |
## Retiring platform branch schedule
This following table lists Elastic Beanstalk platform branches that are scheduled for retirement, because some of their components are reaching their End of Life (EOL). All AL2-based platform branches have retirement dates no later than June 30, 2026, when Amazon Linux 2 reaches EOL. For more information about Amazon Linux 2, see [Amazon Linux 2 FAQs](https://aws.amazon.com/amazon-linux-2/faqs/).
For a more detailed list of retiring platform branches that includes their specific components, see [retiring platform versions](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-retiring.html) in the *AWS Elastic Beanstalk Platforms* guide.
| Runtime version / platform branch | Target retirement date |
| --- | --- |
| PHP 8.1 AL2023 | March 31, 2026 |
| PHP 8.1 AL2 | March 31, 2026 |
| Docker AL2 | June 30, 2026 |
| ECS AL2 | June 30, 2026 |
| Go 1 AL2 | June 30, 2026 |
| Corretto 8 AL2 | June 30, 2026 |
| Corretto 11 AL2 | June 30, 2026 |
| Corretto 17 AL2 | June 30, 2026 |
| Corretto 8 with Tomcat 9 AL2 | June 30, 2026 |
| Corretto 11 with Tomcat 9 AL2 | June 30, 2026 |
| .NET Core AL2 | June 30, 2026 |
| Python 3.9 AL2023 | July 31, 2026 |
| Ruby 3.2 AL2023 | July 31, 2026 |
| Node.js 20 AL2023 | July 31, 2026 |
| IIS 10.0 on Windows Server 2016 (& Core) | September 30, 2026 |
| PHP 8.2 AL2023 | March 31, 2027 |
| .NET 9 AL2023 | March 31, 2027 |
| .NET 8 AL2023 | March 31, 2027 |
## Retired platform branch history
The following tables list Elastic Beanstalk platform branches that are already in retired status. You can see a detailed history of these platform branches and their components in the [Platform history](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history.html) of the *AWS Elastic Beanstalk Platforms* guide.
**Amazon Linux 2023 (AL2023)**
| Runtime version / platform branch | Retirement date |
| --- | --- |
| .NET 6 AL2023 | April 8, 2025 |
| Node.js 18 AL2023 | August 11, 2025 |
**Amazon Linux 2 (AL2)**
| Runtime version / platform branch | Retirement date |
| --- | --- |
| Corretto 11 with Tomcat 8.5 AL2 | October 10, 2024 |
| Corretto 8 with Tomcat 8.5 AL2 | October 10, 2024 |
| Corretto 11 with Tomcat 7 AL2 | June 29, 2022 |
| Corretto 8 with Tomcat 7 AL2 | June 29, 2022 |
| Node.js 18 AL2 | August 11, 2025 |
| Node.js 16 AL2 | October 10, 2024 |
| Node.js 14 AL2 | October 10, 2024 |
| Node.js 12 AL2 | December 23, 2022 |
| Node.js 10 AL2 | June 29, 2022 |
| PHP 8.0 AL2 | October 10, 2024 |
| PHP 7.4 AL2 | June 9, 2023 |
| PHP 7.3 AL2 | June 29, 2022 |
| PHP 7.2 AL2 | June 29, 2022 |
| Python 3.8 AL2 | April 8, 2025 |
| Python 3.7 AL2 | October 10, 2024 |
| Ruby 3.0 AL2 | October 10, 2024 |
| Ruby 2.7 AL2 | October 10, 2024 |
| Ruby 2.6 AL2 | December 23, 2022 |
| Ruby 2.5 AL2 | June 29, 2022 |
**Amazon Linux AMI (AL1)**
| Runtime version / platform branch | Retirement date |
| --- | --- |
| Single Container Docker | July 18, 2022 |
| Multicontainer Docker | July 18, 2022 |
| Preconfigured Docker - GlassFish 5.0 with Java 8 | July 18, 2022 |
| Go 1 | July 18, 2022 |
| Java 8 | July 18, 2022 |
| Java 7 | July 18, 2022 |
| Java 8 with Tomcat 8.5 | July 18, 2022 |
| Java 7 with Tomcat 7 | July 18, 2022 |
| Node.js | July 18, 2022 |
| PHP 7.2 - 7.3 | July 18, 2022 |
| Python 3.6 | July 18, 2022 |
| Ruby 2,4, 2.5, 2.6 with Passenger | July 18, 2022 |
| Ruby 2.4, 2.5, 2.6 with Puma | July 18, 2022 |
| Go 1.3–1.10 | October 31, 2020 |
| Java 6 | October 31, 2020 |
| Node.js 4.x–8.x | October 31, 2020 |
| PHP 5.4–5.6 | October 31, 2020 |
| PHP 7.0–7.1 | October 31, 2020 |
| Python 2.6, 2.7, 3.4 | October 31, 2020 |
| Ruby 1.9.3 | October 31, 2020 |
| Ruby 2.0–2.3 | October 31, 2020 |
**Note**
On [July 18, 2022](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-07-18-linux-al1-retire.html), Elastic Beanstalk set the status of all platform branches based on Amazon Linux AMI (AL1) to **retired**. For more information, see [Platform retirement FAQ](using-features.migration-al.FAQ.md).
**Windows Server**
| Runtime version / platform branch | Retirement date |
| --- | --- |
| IIS 8.5 running on 64bit Windows Server (& Core) 2012 R2 | December 4, 2023 |
| IIS 8.5 running on 64bit Windows Server (& Core) 2012 R2 version 0.1.0 | June 29, 2022 |
| IIS 8.5 running on 64bit Windows Server (& Core) 2012 R2 version 1.2.0 | June 29, 2022 |
| IIS 10.0 running on 64bit Windows Server 2016 (& Core) version 1.2.0 | June 29, 2022 |
| IIS 8 running on 64bit Windows Server 2012 R1 Platform Branch | June 22, 2022 |
| IIS 8 running on 64bit Windows Server 2012 R1 version 0.1.0 | June 22, 2022 |
| IIS 8 running on 64bit Windows Server 2012 R1 version 1.2.0 | June 22, 2022 |
**Note**
For more information about the retirement of the *Windows 2012 R2* platform branches, see [Windows Server 2012 R2 platform branches retired](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2023-12-04-windows-2012-retire.html) in the *AWS Elastic Beanstalk Release Notes*.
## Retired server and operating system history
The following tables provide a history of the operating systems, application servers, and web servers that are no longer supported by Elastic Beanstalk platforms. All of the platform branches that utilized these components are now retired. The dates reflect the retirement date of the last Elastic Beanstalk platform branch that included the component.
**Operating Systems**
| OS version | Platform retirement date |
| --- | --- |
| Windows Server 2012 R2 running IIS 8.5 | December 4, 2023 |
| Windows Server Core 2012 R2 running IIS 8.5 | December 4, 2023 |
| Amazon Linux AMI (AL1) | July 18, 2022 |
| Windows Server 2012 R1 | June 22, 2022 |
| Windows Server 2008 R2 | October 28, 2019 |
**Application servers**
| Application server version | Platform retirement date |
| --- | --- |
| Tomcat 7 | June 29, 2022 for Amazon Linux 2 (AL2) platforms July 18, 2022 for Amazon Linux AMI (AL1) platforms |
| Tomcat 8 | October 31, 2020 |
| Tomcat 6 | October 31, 2020 |
**Web servers**
| Web server version | Platform retirement date |
| --- | --- |
| IIS 8 running on 64bit Windows Server | June 22, 2022 |
| Apache HTTP Server 2.2 | October 31, 2020 |
| Nginx 1.12.2 | October 31, 2020 |
# Elastic Beanstalk supported platforms
AWS Elastic Beanstalk provides a variety of platforms on which you can build your applications. You design your web application to one of these platforms, and Elastic Beanstalk deploys your code to the platform version you selected to create an active application environment.
Elastic Beanstalk provisions the resources needed to run your application, including one or more Amazon EC2 instances. The software stack running on the Amazon EC2 instances depends on the specific platform version you've selected for your environment.
**The solution stack name for a platform branch**
You can use the *solution stack name* for a given platform branch version to launch an environment with the [EB CLI](eb-cli3.md), [Elastic Beanstalk API](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/), or the [AWS CLI](https://aws.amazon.com/cli/). The *AWS Elastic Beanstalk Platforms* guide lists the *solution stack name* under the platform branch version in both the [Elastic Beanstalk Supported Platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) and [Platform history](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history.html) sections.
To retrieve all of the solution stack names that you can use to create an environment, use the [ListAvailableSolutionStacks](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_ListAvailableSolutionStacks.html) API or the [https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/list-available-solution-stacks.html](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/list-available-solution-stacks.html) in the AWS CLI.
You can customize and configure the software that your application depends on in your platform. Learn more at [Customizing software on Linux servers](customize-containers-ec2.md) and [Customizing software on Windows servers](customize-containers-windows-ec2.md). Detailed release notes are available for recent releases at [AWS Elastic Beanstalk Release Notes](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/).
## Supported platforms and component history
The *AWS Elastic Beanstalk Platforms* guide lists all of the current platform branch versions in the [Elastic Beanstalk Supported Platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) section. The *Platforms* guide also lists a *platform history* for each platform, which includes a list of previous branch platform versions. To view the *platform history* for each platform, select one of the following links.
+ [Docker](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-docker.html)
+ [Go](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-go.html)
+ [Java SE](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-javase.html)
+ [Tomcat (running Java SE)](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-java.html)
+ [.NET Core on Linux](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-dotnetlinux.html)
+ [.NET on Windows Server](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-dotnet.html)
+ [Node.js](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-nodejs.html)
+ [PHP](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-php.html)
+ [Python](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-python.html)
+ [Ruby](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-ruby.html)
# Elastic Beanstalk Linux platforms
The Elastic Beanstalk Linux platforms provide an extensive amount of functionality out of the box. You can extend the platforms in several ways to support your application. For details, see [Extending Elastic Beanstalk Linux platforms](platforms-linux-extend.md).
Most of the platforms that Elastic Beanstalk supports are based on the Linux operating system. Specifically, these platforms are based on Amazon Linux, a Linux distribution provided by AWS. Elastic Beanstalk Linux platforms use Amazon Elastic Compute Cloud (Amazon EC2) instances, and these instances run Amazon Linux.
**Topics**
+ [
## Supported Amazon Linux versions
](#platforms-linux.versions)
+ [
## List of Elastic Beanstalk Linux platforms
](#platforms-linux.list)
+ [
# Instance deployment workflow
](platforms-linux-extend.workflow.md)
+ [
# Instance deployment workflow for ECS running on Amazon Linux 2 and later
](platforms-linux-extend.workflow.ecs-al2.md)
+ [
# Platform script tools for your Elastic Beanstalk environments
](custom-platforms-scripts.md)
## Supported Amazon Linux versions
AWS Elastic Beanstalk supports platforms based on Amazon Linux 2 and Amazon Linux 2023.
For more information about Amazon Linux 2 and Amazon Linux 2023, see the following:
+ **Amazon Linux 2** – [Amazon Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html) in the *Amazon EC2 User Guide*.
+ **Amazon Linux 2023** – [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*
For details about supported platform versions, see [Elastic Beanstalk supported platforms](concepts.platforms.md).
**Note**
You can migrate your application from an Elastic Beanstalk AL1 or AL2 platform branch to the equivalent AL2023 platform branch. For more information, see [Migrating your Elastic Beanstalk Linux application to Amazon Linux 2023 or Amazon Linux 2](using-features.migration-al.md).
### Amazon Linux 2023
AWS announced the [general availability](https://aws.amazon.com//blogs/aws/amazon-linux-2023-a-cloud-optimized-linux-distribution-with-long-term-support/) of Amazon Linux 2023 in March of 2023. The *Amazon Linux 2023 User Guide* summarizes key differences between Amazon Linux 2 and Amazon Linux 2023. For more information, see [Comparing Amazon Linux 2 and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) in the user guide.
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.
## List of Elastic Beanstalk Linux platforms
The following list provides the Linux platforms that Elastic Beanstalk supports for different programming languages as well as for Docker containers. Elastic Beanstalk offers platforms based on Amazon Linux 2 and Amazon Linux 2023 for all of them. To learn more about a platform, select the corresponding link.
+ [Docker (and ECS Docker)](create_deploy_docker.md)
+ [Go](create_deploy_go.md)
+ [Tomcat (running Java SE)](create_deploy_Java.md)
+ [Java SE](create_deploy_Java.md)
+ [.NET Core on Linux](create-deploy-dotnet-core-linux.md)
+ [Node.js](create_deploy_nodejs.md)
+ [PHP](create_deploy_PHP_eb.md)
+ [Python](create-deploy-python-apps.md)
+ [Ruby](create_deploy_Ruby.md)
# Instance deployment workflow
**Note**
The information in this section doesn't apply to the *ECS running on Amazon Linux 2 and Amazon Linux 2023* platform branches. For more information, see the next section [Instance deployment workflow for ECS running on Amazon Linux 2 and laterInstance deployment workflow for ECS on AL2 and later](platforms-linux-extend.workflow.ecs-al2.md).
With many ways to extend your environment's platform, it's useful to know what happens whenever Elastic Beanstalk provisions an instance or runs a deployment to an instance. The following diagram shows this entire deployment workflow. It depicts the different phases in a deployment and the steps that Elastic Beanstalk takes in each phase.
**Notes**
The diagram doesn't represent the complete set of steps that Elastic Beanstalk takes on environment instances during deployment. We provide this diagram for illustration, to provide you with the order and context for the execution of your customizations.
For simplicity, the diagram mentions only the `.platform/hooks/*` hook subdirectories (for application deployments), and not the `.platform/confighooks/*` hook subdirectories (for configuration deployments). Hooks in the latter subdirectories run during exactly the same steps as hooks in corresponding subdirectories shown in the diagram.
![\[Workflow for extensions execution order on an environment instance running on a Amazon Linux-based platform.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/platforms-linux-extend-order.png)
The following list details the deployment phases and steps.
1. **Initial steps**
Elastic Beanstalk downloads and extracts your application. After each one of these steps, Elastic Beanstalk runs one of the extensibility steps.
1. Runs commands found in the [commands:](customize-containers-ec2.md#linux-commands) section of any configuration file.
1. Runs any executable files found in the `.platform/hooks/prebuild` directory of your source bundle (`.platform/confighooks/prebuild` for a configuration deployment).
1. **Configure**
Elastic Beanstalk configures your application and the proxy server.
1. Runs the commands found in the `Buildfile` in your source bundle.
1. Copies your custom proxy configuration files, if you have any in the `.platform/nginx` directory of your source bundle, to their runtime location.
1. Runs commands found in the [container\$1commands:](customize-containers-ec2.md#linux-container-commands) section of any configuration file.
1. Runs any executable files found in the `.platform/hooks/predeploy` directory of your source bundle (`.platform/confighooks/predeploy` for a configuration deployment).
1. **Deploy**
Elastic Beanstalk deploys and runs your application and the proxy server.
1. Runs the command found in the `Procfile` file in your source bundle.
1. Runs or reruns the proxy server with your custom proxy configuration files, if you have any.
1. Runs any executable files found in the `.platform/hooks/postdeploy` directory of your source bundle (`.platform/confighooks/postdeploy` for a configuration deployment).
# Instance deployment workflow for ECS running on Amazon Linux 2 and later
The previous section describes the supported extensibility features throughout the phases of the application deployment workflow. There are some differences for the Docker platform branches [*ECS running on Amazon Linux 2 and later*](create_deploy_docker_ecs.md). This section explains how those concepts apply to this specific platform branch.
With many ways to extend your environment's platform, it's useful to know what happens whenever Elastic Beanstalk provisions an instance or runs a deployment to an instance. The following diagram shows this entire deployment workflow for an environment based on the *ECS running on Amazon Linux 2* and *ECS running on Amazon Linux 2023* platform branches. It depicts the different phases in a deployment and the steps that Elastic Beanstalk takes in each phase.
Unlike the workflow described in the prior section, the deployment Configuration phase doesn't support the following extensibility features: `Buildfile` commands, `Procfile` commands, reverse proxy configuration.
**Notes**
The diagram doesn't represent the complete set of steps that Elastic Beanstalk takes on environment instances during deployment. We provide this diagram for illustration, to provide you with the order and context for the execution of your customizations.
For simplicity, the diagram mentions only the `.platform/hooks/*` hook subdirectories (for application deployments), and not the `.platform/confighooks/*` hook subdirectories (for configuration deployments). Hooks in the latter subdirectories run during exactly the same steps as hooks in corresponding subdirectories shown in the diagram.
![\[Workflow for extensions execution order on an environment instance on the ECS-based Docker platform.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/platform-ecs-al2-extended-order.png)
The following list details the deployment workflow steps.
1. Runs any executable files found in the `appdeploy/pre` directory under `EBhooksDir`.
1. Runs any executable files found in the `.platform/hooks/prebuild` directory of your source bundle (`.platform/confighooks/prebuild` for a configuration deployment).
1. Runs any executable files found in the `.platform/hooks/predeploy` directory of your source bundle (`.platform/confighooks/predeploy` for a configuration deployment).
1. Runs any executable files found in the `appdeploy/enact` directory under `EBhooksDir`.
1. Runs any executable files found in the `appdeploy/post` directory under `EBhooksDir`.
1. Runs any executable files found in the `.platform/hooks/postdeploy` directory of your source bundle (`.platform/confighooks/postdeploy` for a configuration deployment).
The reference to `EBhooksDir` represents the path of the platform hooks directory. To retrieve directory path name use the [get-config](custom-platforms-scripts.md#custom-platforms-scripts.get-config) script tool on the command line of your environment instance as shown:
```
$ /opt/elasticbeanstalk/bin/get-config platformconfig -k EBhooksDir
```
# Platform script tools for your Elastic Beanstalk environments
This topic describes tools that AWS Elastic Beanstalk provides for environments that use Amazon Linux platforms. The tools are located on the Amazon EC2 instances of the Elastic Beanstalk environments.
## get-config
Use the `get-config` tool to retrieve plain text environment variable values and other platform and instance information. The tool is available at `/opt/elasticbeanstalk/bin/get-config`.
### get-config commands
Each `get-config` tool command returns a specific type of information. Use the following syntax to run the commands of any of the tools.
```
$ /opt/elasticbeanstalk/bin/get-config command [ options ]
```
The following example runs the `environment` command.
```
$ /opt/elasticbeanstalk/bin/get-config environment -k PORT
```
Depending on the command and options you choose, the tool returns an object (JSON or YAML) with key-value pairs or a single value.
You can test `get-config` by using SSH to connect to an EC2 instance in your Elastic Beanstalk environment.
**Note**
When you run `get-config` for testing, some commands might require root user privileges to access the underlying information. If you get an access permission error, run the command again under `sudo`.
You don't need to add `sudo` when using the tool in the scripts that you deploy to your environment. Elastic Beanstalk runs all your scripts as the root user.
The following sections describe the commands for the tools.
#### optionsettings – Configuration options
The `get-config optionsettings` command returns an object that's listing the configuration options that are set on the environment and used by the platform on environment instances. They're organized by namespace.
```
$ /opt/elasticbeanstalk/bin/get-config optionsettings
{"aws:elasticbeanstalk:application:environment":{"JDBC_CONNECTION_STRING":""},"aws:elasticbeanstalk:container:tomcat:jvmoptions":{"JVM Options":"","Xms":"256m","Xmx":"256m"},"aws:elasticbeanstalk:environment:proxy":{"ProxyServer":"nginx","StaticFiles":[""]},"aws:elasticbeanstalk:healthreporting:system":{"SystemType":"enhanced"},"aws:elasticbeanstalk:hostmanager":{"LogPublicationControl":"false"}}
```
To return a specific configuration option value, use the `--namespace` (`-n`) option to specify a namespace, and the `--option-name` (`-o`) option to specify an option name.
```
$ /opt/elasticbeanstalk/bin/get-config optionsettings -n aws:elasticbeanstalk:container:php:phpini -o memory_limit
256M
```
#### environment – Environment properties
The `get-config environment` command returns an object containing a list of environment properties, including both user-configured and provided by Elastic Beanstalk. The user-configured properties are defined in the [console](environments-cfg-softwaresettings.md#environments-cfg-softwaresettings-console) as *Plain text* or with the configuration option namespace [aws:elasticbeanstalk:application:environment](command-options-general.md#command-options-general-elasticbeanstalkapplicationenvironment).
```
$ /opt/elasticbeanstalk/bin/get-config environment
{"JDBC_CONNECTION_STRING":"","RDS_PORT":"3306","RDS_HOSTNAME":"anj9aw1b0tbj6b.cijbpanmxz5u.us-west-2.rds.amazonaws.com","RDS_USERNAME":"testusername","RDS_DB_NAME":"ebdb","RDS_PASSWORD":"testpassword1923851"}
```
For example, Elastic Beanstalk provides environment properties for connecting to an integrated Amazon RDS DB instance (for example, `RDS_HOSTNAME`). These RDS connection properties appear in the output of `get-config environment`. However, they don't appear in the output of `get-config optionsettings`. This is because they weren't set in configuration options.
To return a specific environment property, use the `--key` (`-k`) option to specify a property key.
```
$ /opt/elasticbeanstalk/bin/get-config environment -k TESTPROPERTY
testvalue
```
**Note**
The `get-config` tool cannot retrieve [environment variables that store secrets](AWSHowTo.secrets.env-vars.md). For more information about how to programmatically retrieve values from secret or parameter stores, see [Using Secrets Manager](AWSHowTo.secrets.Secrets-Manager-and-Parameter-Store.md#AWSHowTo.secrets.Secrets-Manager) or [Using Systems Manager Parameter Store](AWSHowTo.secrets.Secrets-Manager-and-Parameter-Store.md#AWSHowTo.secrets.SSM-parmameter-store).
#### container – On-instance configuration values
The `get-config container` command returns an object that lists platform and environment configuration values for environment instances.
The following example shows the output for the command on an Amazon Linux 2 Tomcat environment.
```
$ /opt/elasticbeanstalk/bin/get-config container
{"common_log_list":["/var/log/eb-engine.log","/var/log/eb-hooks.log"],"default_log_list":["/var/log/nginx/access.log","/var/log/nginx/error.log"],"environment_name":"myenv-1da84946","instance_port":"80","log_group_name_prefix":"/aws/elasticbeanstalk","proxy_server":"nginx","static_files":[""],"xray_enabled":"false"}
```
To return the value of a specific key, use the `--key` (`-k`) option to specify the key.
```
$ /opt/elasticbeanstalk/bin/get-config container -k environment_name
myenv-1da84946
```
#### addons – Add-on configuration values
The `get-config addons` command returns an object that contains configuration information of environment add-ons. Use it to retrieve the configuration of an Amazon RDS database that's associated with the environment.
```
$ /opt/elasticbeanstalk/bin/get-config addons
{"rds":{"Description":"RDS Environment variables","env":{"RDS_DB_NAME":"ebdb","RDS_HOSTNAME":"ea13k2wimu1dh8i.c18mnpu5rwvg.us-east-2.rds.amazonaws.com","RDS_PASSWORD":"password","RDS_PORT":"3306","RDS_USERNAME":"user"}}}
```
You can restrict the result in two ways. To retrieve values for a specific add-on, use the `--add-on` (`-a`) option to specify the add-on name.
```
$ /opt/elasticbeanstalk/bin/get-config addons -a rds
{"Description":"RDS Environment variables","env":{"RDS_DB_NAME":"ebdb","RDS_HOSTNAME":"ea13k2wimu1dh8i.c18mnpu5rwvg.us-east-2.rds.amazonaws.com","RDS_PASSWORD":"password","RDS_PORT":"3306","RDS_USERNAME":"user"}}
```
To return the value of a specific key within an add-on, add the `--key` (`-k`) option to specify the key.
```
$ /opt/elasticbeanstalk/bin/get-config addons -a rds -k RDS_DB_NAME
ebdb
```
#### platformconfig – Constant configuration values
The `get-config platformconfig` command returns an object that contains platform configuration information that's constant to the platform version. The output is the same on all environments that run the same platform version. The output object for the command has two embedded objects:
+ `GeneralConfig` – Contains information that's constant across the latest versions of all Amazon Linux 2 and Amazon Linux 2023 platform branches.
+ `PlatformSpecificConfig` – Contains information that's constant for the platform version and is specific to it.
The following example shows the output for the command on an environment that uses the *Tomcat 8.5 running Corretto 11* platform branch.
```
$ /opt/elasticbeanstalk/bin/get-config platformconfig
{"GeneralConfig":{"AppUser":"webapp","AppDeployDir":"/var/app/current/","AppStagingDir":"/var/app/staging/","ProxyServer":"nginx","DefaultInstancePort":"80"},"PlatformSpecificConfig":{"ApplicationPort":"8080","JavaVersion":"11","TomcatVersion":"8.5"}}
```
To return the value of a specific key, use the `--key` (`-k`) option to specify the key. These keys are unique across the two embedded objects. You don't need to specify the object that contains the key.
```
$ /opt/elasticbeanstalk/bin/get-config platformconfig -k AppStagingDir
/var/app/staging/
```
### get-config output options
Use the `--output` option to specify the output object format. Valid values are `JSON` (default) and `YAML`. This is a global option. You must specify it before the command name.
The following example returns configuration option values in the YAML format.
```
$ /opt/elasticbeanstalk/bin/get-config --output YAML optionsettings
aws:elasticbeanstalk:application:environment:
JDBC_CONNECTION_STRING: ""
aws:elasticbeanstalk:container:tomcat:jvmoptions:
JVM Options: ""
Xms: 256m
Xmx: 256m
aws:elasticbeanstalk:environment:proxy:
ProxyServer: nginx
StaticFiles:
- ""
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
aws:elasticbeanstalk:hostmanager:
LogPublicationControl: "false"
```
## pkg-repo
**Note**
The `pkg-repo` tool is not available for environments based on Amazon Linux 2023 platforms. However, you can 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*
In some urgent circumstances, you might need to update your Amazon EC2 instances with an Amazon Linux 2 security patch that hasn't yet been released with the required Elastic Beanstalk platform versions. You can't perform a manual update on your Elastic Beanstalk environments by default. This is because the platform versions are locked to a specific version of the Amazon Linux 2 repository. This lock ensures that instances run supported and consistent software versions. For urgent cases, the `pkg-repo` tool allows a workaround to manually update yum packages on Amazon Linux 2 if you need to install it on an environment before it's released in a new Elastic Beanstalk platform version.
The `pkg-repo` tool on Amazon Linux 2 platforms provides the capability to unlock the `yum` package repositories. You can then manually perform a **yum update** for a security patch. Conversely, you can follow the update by using the tool to lock the yum package repositories to prevent further updates. The `pkg-repo` tool is available at the `/opt/elasticbeanstalk/bin/pkg-repo` directory of all the EC2 instances in your Elastic Beanstalk environments.
Changes using the `pkg-repo` tool are made only on the EC2 instance that the tool is used on. They don’t affect other instances or prevent future updates to the environment. The examples that are provided later in this topic explain how to apply the changes across all instances by calling the `pkg-repo` commands from scripts and configuration files.
**Warning**
We don't recommend this tool for most users. Any manual changes applied to an unlocked platform version are considered out of band. This option is only viable for those users in urgent circumstances that can accept the following risks:
Package versions can't be guaranteed to be consistent across all instances in your environments.
Environments that are modified using the `pkg-repo` tool aren't guaranteed to function properly. They haven't been tested and verified on Elastic Beanstalk supported platforms.
We strongly recommend applying best practices that include testing and backout plans. To help facilitate best practices, you can use the Elastic Beanstalk console and EB CLI to clone an environment and swap environment URLs. For more information about using these operations, see [Blue/Green deployments](using-features.CNAMESwap.md) in the *Managing environments* chapter of this guide.
If you plan to manually edit yum repository configuration files, run the `pkg-repo` tool first. The `pkg-repo` tool might not work as intended in an Amazon Linux 2 environment with manually edited yum repository configuration files. This is because the tool might not recognize the configuration changes.
For more information about the Amazon Linux package repository, see the [Package repository](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html#package-repository) topic in the *Amazon EC2 User Guide*.
### pkg-repo commands
Use the following syntax to run the `pkg-repo` tool commands.
```
$ /opt/elasticbeanstalk/bin/pkg-repo command [options]
```
The `pkg-repo` commands are the following:
+ **lock** – locks the `yum` package repositories to a specific version
+ **unlock** – unlocks the `yum` package repositories from a specific version
+ **status** – lists all the `yum` package repositories and their current lock status
+ **help** – shows general help or help for one command
The options apply to the commands as follows:
+ `lock`, `unlock` and `status ` – options: `-h`, `--help`, or none (default).
+ `help` – options: `lock`, `unlock`, `status`, or none (default).
The following example runs the **unlock** command.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo unlock
Amazon Linux 2 core package repo successfully unlocked
Amazon Linux 2 extras package repo successfully unlocked
```
The following example runs the **lock** command.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo lock
Amazon Linux 2 core package repo successfully locked
Amazon Linux 2 extras package repo successfully locked
```
The following example runs the **status** command.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo status
Amazon Linux 2 core package repo is currently UNLOCKED
Amazon Linux 2 extras package repo is currently UNLOCKED
```
The following example runs the **help** command for the **lock** command.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo help lock
```
The following example runs the **help** command for the `pkg-repo` tool.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo help
```
You can test `pkg-repo` by using SSH to connect to an instance in your Elastic Beanstalk environment. One SSH option is the EB CLI [**eb ssh**](eb3-ssh.md) command.
**Note**
The `pkg-repo` tool requires root user privileges to run. If you get an access permission error, run the command again under `sudo`.
You don't need to add `sudo` when using the tool in the scripts or configuration files that you deploy to your environment. Elastic Beanstalk runs all your scripts as the root user.
### pkg-repo examples
The previous section provides command line examples for testing on an individual EC2 instance of an Elastic Beanstalk environment. This approach can be helpful for testing. However, it updates only one instance at a time, so it isn’t practical for applying changes to all of the instances in an environment.
A more pragmatic approach is to use [platform hook](platforms-linux-extend.hooks.md) scripts or an [`.ebextensions`](ebextensions.md) configuration file to apply the changes across all instances in a consistent manner.
The following example calls `pkg-repo` from a configuration file in the [`.ebextensions`](ebextensions.md) folder. Elastic Beanstalk runs the commands in the `update_package.config` file when you deploy your application source bundle.
```
.ebextensions
└── update_package.config
```
To receive the latest version of the *docker* package, this configuration specifies the *docker* package in the **yum update** command.
```
### update_package.config ###
commands:
update_package:
command: |
/opt/elasticbeanstalk/bin/pkg-repo unlock
yum update docker -y
/opt/elasticbeanstalk/bin/pkg-repo lock
yum clean all -y
rm -rf /var/cache/yum
```
This configuration doesn't specify any packages in the **yum update** command. All available updates are applied as a result.
```
### update_package.config ###
commands:
update_package:
command: |
/opt/elasticbeanstalk/bin/pkg-repo unlock
yum update -y
/opt/elasticbeanstalk/bin/pkg-repo lock
yum clean all -y
rm -rf /var/cache/yum
```
The following example calls `pkg-repo` from a bash script as a [platform hook](platforms-linux-extend.hooks.md). Elastic Beanstalk runs the `update_package.sh` script file that's located in the `prebuild` subdirectory.
```
.platform
└── hooks
└── prebuild
└── update_package.sh
```
To receive the latest version of the *docker* package, this script specifies the *docker* package in the **yum update** command. If the package name is omitted, all the available updates are applied. The prior configuration file example demonstrates this.
```
### update_package.sh ###
#!/bin/bash
/opt/elasticbeanstalk/bin/pkg-repo unlock
yum update docker -y
/opt/elasticbeanstalk/bin/pkg-repo lock
yum clean all -y
rm -rf /var/cache/yum
```
## download-source-bundle (Amazon Linux AMI only)
On Amazon Linux AMI platform branches (preceding Amazon Linux 2), Elastic Beanstalk provides an additional tool, which is `download-source-bundle`. Use this tool to download your application source code when deploying your platform. The tool is available at `/opt/elasticbeanstalk/bin/download-source-bundle`.
The example script `00-unzip.sh` is located in the `appdeploy/pre` folder on environment instances. It demonstrates how to use `download-source-bundle` to download the application source code to the `/opt/elasticbeanstalk/deploy/appsource` folder during deployment.
# Extending Elastic Beanstalk Linux platforms
This topic describes how to extend your Linux platforms with your own commands, scripts, software, and configurations. You may need to extend your platform to change the default proxy server and configuration. Or you may need to customize how the platform builds or starts up your application.
**Topics**
+ [
# Buildfile and Procfile
](platforms-linux-extend.build-proc.md)
+ [
# Platform hooks
](platforms-linux-extend.hooks.md)
+ [
# Configuration files
](platforms-linux-extend.config-files.md)
+ [
# Reverse proxy configuration
](platforms-linux-extend.proxy.md)
+ [
# Application example with extensions
](platforms-linux-extend.example.md)
# Buildfile and Procfile
Some platforms allow you to customize how you build or prepare your application, and to specify the processes that run your application. Each individual platform topic specifically mentions *Buildfile* and/or *Procfile* if the platform supports them. Look for your specific platform under [Elastic Beanstalk platforms](concepts-all-platforms.md).
For all supporting platforms, syntax and semantics are identical, and are as described on this page. Individual platform topics mention specific usage of these files for building and running applications in their respective languages.
## Buildfile
To specify a custom build and configuration command for your application, place a file named `Buildfile` in the root directory of your application source. The file name is case sensitive. Use the following syntax for your `Buildfile`.
```
:
```
The command in your `Buildfile` must match the following regular expression: `^[A-Za-z0-9_-]+:\s*[^\s].*$`
Elastic Beanstalk doesn't monitor the application that is run with a `Buildfile`. Use a `Buildfile` for commands that run for short periods and terminate after completing their tasks. For long-running application processes that should not exit, use a [Procfile](#platforms-linux-extend.proc).
All paths in the `Buildfile` are relative to the root of the source bundle. In the following example of a `Buildfile`, `build.sh` is a shell script located at the root of the source bundle.
**Example Buildfile**
```
make: ./build.sh
```
If you want to provide custom build steps, we recommend that you use `predeploy` platform hooks for anything but the simplest commands, instead of a `Buildfile`. Platform hooks allow richer scripts and better error handling. Platform hooks are described in the next section.
## Procfile
To specify custom commands to start and run your application, place a file named `Procfile` in the root directory of your application source. The file name is case sensitive. Use the following syntax for your `Procfile`. You can specify one or more commands.
```
:
:
...
```
Each line in your `Procfile` must match the following regular expression: `^[A-Za-z0-9_-]+:\s*[^\s].*$`
Use a `Procfile` for long-running application processes that shouldn't exit. Elastic Beanstalk expects processes run from the `Procfile` to run continuously. Elastic Beanstalk monitors these processes and restarts any process that terminates. For short-running processes, use a [Buildfile](#platforms-linux-extend.build).
All paths in the `Procfile` are relative to the root of the source bundle. The following example `Procfile` defines three processes. The first one, called `web` in the example, is the *main web application*.
**Example Procfile**
```
web: bin/myserver
cache: bin/mycache
foo: bin/fooapp
```
Elastic Beanstalk configures the proxy server to forward requests to your main web application on port 5000, and you can configure this port number. A common use for a `Procfile` is to pass this port number to your application as a command argument. For details about proxy configuration, see [Reverse proxy configuration](platforms-linux-extend.proxy.md).
Elastic Beanstalk captures standard output and error streams from `Procfile` processes in log files. Elastic Beanstalk names the log files after the process and stores them in `/var/log`. For example, the `web` process in the preceding example generates logs named `web-1.log` and `web-1.error.log` for `stdout` and `stderr`, respectively.
# Platform hooks
Platform hooks are specifically designed to extend your environment's platform. These are custom scripts and other executable files that you deploy as part of your application's source code, and Elastic Beanstalk runs during various instance provisioning stages.
**Note**
Platform hooks aren't supported on Amazon Linux AMI platform versions (preceding Amazon Linux 2).
## Application deployment platform hooks
An *application deployment* occurs when you provide a new source bundle for deployment, or when you make a configuration change that requires termination and recreation of all environment instances.
To provide platform hooks that run during an application deployment, place the files under the `.platform/hooks` directory in your source bundle, in one of the following subdirectories.
+ `prebuild` – Files here run after the Elastic Beanstalk platform engine downloads and extracts the application source bundle, and before it sets up and configures the application and web server.
The `prebuild` files run after running commands found in the [commands](customize-containers-ec2.md#linux-commands) section of any configuration file and before running `Buildfile` commands.
+ `predeploy` – Files here run after the Elastic Beanstalk platform engine sets up and configures the application and web server, and before it deploys them to their final runtime location.
The `predeploy` files run after running commands found in the [container\$1commands](customize-containers-ec2.md#linux-container-commands) section of any configuration file and before running `Procfile` commands.
+ `postdeploy` – Files here run after the Elastic Beanstalk platform engine deploys the application and proxy server.
This is the last deployment workflow step.
## Configuration deployment platform hooks
A *configuration deployment* occurs when you make configuration changes that only update environment instances without recreating them. The following option updates cause a configuration update.
+ [Environment properties and platform-specific settings](environments-cfg-softwaresettings.md)
+ [Static files](environment-cfg-staticfiles.md)
+ [AWS X-Ray daemon](environment-configuration-debugging.md)
+ [Log storage and streaming](environments-cfg-logging.md)
+ Application port (for details see [Reverse proxy configuration](platforms-linux-extend.proxy.md))
To provide hooks that run during a configuration deployment, place them under the `.platform/confighooks` directory in your source bundle. The same three subdirectories as for application deployment hooks apply.
## More about platform hooks
Hook files can be binary files, or script files starting with a `#!` line containing their interpreter path, such as `#!/bin/bash`. All files must have execute permission. Use `chmod +x` to set execute permission on your hook files. For all Amazon Linux 2023 and Amazon Linux 2 based platforms versions that were released on or after April 29, 2022, Elastic Beanstalk automatically grants execute permissions to all of the platform hook scripts. In this case you don't have to manually grant execute permissions. For a list of these platform versions, refer to the [April 29, 2022 ](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-04-29-linux.html#release-2022-04-29-linux.platforms) Linux release notes in the *AWS Elastic Beanstalk Release Notes Guide*.
Elastic Beanstalk runs files in each one of these directories in lexicographical order of file names. All files run as the `root` user. The current working directory (cwd) for platform hooks is the application's root directory. For `prebuild` and `predeploy` files it's the application staging directory, and for `postdeploy` files it's the current application directory. If one of the files fails (exits with a non-zero exit code), the deployment aborts and fails.
A platform hooks text script may fail if it contains Windows *Carriage Return / Line Feed* (CRLF) line break characters. If a file was saved in a Windows host, then transferred to a Linux server, it may contain Windows CRLF line breaks. For platforms released on or after [December 29, 2022](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-12-29-linux.html), Elastic Beanstalk automatically converts Windows CRLF characters to Linux *Line Feed* (LF) line break characters in platform hooks text files. If you application runs on any Amazon Linux 2 platforms that were release prior to this date, you'll need to convert the Windows CRLF characters to Linux LF characters. One way to accomplish this is to create and save the script file on a Linux host. Tools that convert these characters are also available on the internet.
Hook files have access to all environment properties that you've defined in application options, and to the system environment variables `HOME`, `PATH`, and `PORT`.
To get values of environment variables and other configuration options into your platform hook scripts, you can use the `get-config` utility that Elastic Beanstalk provides on environment instances. For details, see [Platform script tools for your Elastic Beanstalk environments](custom-platforms-scripts.md).
# Configuration files
You can add [configuration files](ebextensions.md) to the `.ebextensions` directory of your application's source code to configure various aspects of your Elastic Beanstalk environment. Among other things, configuration files let you customize software and other files on your environment's instances and run initialization commands on the instances. For more information, see [Customizing software on Linux servers](customize-containers-ec2.md).
You can also set [configuration options](command-options.md) using configuration files. Many of the options control platform behavior, and some of these options are [platform specific](command-options-specific.md).
For platforms based on Amazon Linux 2 and Amazon Linux 2023, we recommend using *Buildfile*, *Procfile*, and *platform hooks* to configure and run custom code on your environment instances during instance provisioning. These mechanisms are described in the previous sections on this page. 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 challenging from a syntax standpoint. You still need to use `.ebextensions` configuration files for any script that needs a reference to a AWS CloudFormation resource.
# Reverse proxy configuration
All Amazon Linux 2 and Amazon Linux 2023 platform versions use nginx as their default reverse proxy server. The Tomcat, Node.js, PHP, and Python platform also support Apache HTTPD as an alternative. To select Apache on these platforms, set the `ProxyServer` option in the `aws:elasticbeanstalk:environment:proxy` namespace to `apache`. All platforms enable proxy server configuration in a uniform way, as described in this section.
**Note**
On Amazon Linux AMI platform versions (preceding Amazon Linux 2) you might have to configure proxy servers differently. You can find these legacy details under the [respective platform topics](concepts-all-platforms.md) in this guide.
Elastic Beanstalk configures the proxy server on your environment's instances to forward web traffic to the main web application on the root URL of the environment; for example, `http://my-env.elasticbeanstalk.com`.
By default, Elastic Beanstalk configures the proxy to forward requests coming in on port 80 to your main web application on port 5000. You can configure this port number by setting the `PORT` environment property using the [aws:elasticbeanstalk:application:environment](command-options-general.md#command-options-general-elasticbeanstalkapplicationenvironment) namespace in a configuration file, as shown in the following example.
```
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: PORT
value:
```
For more information about setting environment variables for your application, see [Option settings](ebextensions-optionsettings.md).
Your application should listen on the port that is configured for it in the proxy. If you change the default port using the `PORT` environment property, your code can access it by reading the value of the `PORT` environment variable. For example, call `os.Getenv("PORT")` in Go, or `System.getenv("PORT")` in Java. If you configure your proxy to send traffic to multiple application processes, you can configure several environment properties, and use their values in both proxy configuration and your application code. Another option is to pass the port value to the process as a command argument in the `Procfile`. For more information see [Buildfile and Procfile](platforms-linux-extend.build-proc.md).
## Configuring nginx
Elastic Beanstalk uses nginx as the default reverse proxy to map your application to your Elastic Load Balancing load balancer. Elastic Beanstalk provides a default nginx configuration that you can extend or override completely with your own configuration.
**Note**
When you add or edit an nginx `.conf` configuration file, be sure to encode it as UTF-8.
To extend the Elastic Beanstalk default nginx configuration, add `.conf` configuration files to a folder named `.platform/nginx/conf.d/` in your application source bundle. The Elastic Beanstalk nginx configuration includes `.conf` files in this folder automatically.
```
~/workspace/my-app/
|-- .platform
| `-- nginx
| `-- conf.d
| `-- myconf.conf
`-- other source files
```
Configuration files in `.platform/nginx/conf.d/` are included in the `http` block of the nginx configuration. Use this location for configurations that apply globally.
To extend the default nginx `server` block configuration, add `.conf` configuration files to a folder named `.platform/nginx/conf.d/elasticbeanstalk/` in your application source bundle. The Elastic Beanstalk nginx configuration includes `.conf` files in this folder within the `server` block.
```
~/workspace/my-app/
|-- .platform
| `-- nginx
| `-- conf.d
| `-- elasticbeanstalk
| `-- server.conf
`-- other source files
```
Use this location to add server-specific configurations, such as additional location blocks, custom error pages, or server-level directives. The following example adds a custom location block.
**Example .platform/nginx/conf.d/elasticbeanstalk/server.conf**
```
location /test {
return 200 "Hello World!";
add_header Content-Type text/plain;
}
```
To override the Elastic Beanstalk default nginx configuration completely, include a configuration in your source bundle at `.platform/nginx/nginx.conf`:
```
~/workspace/my-app/
|-- .platform
| `-- nginx
| `-- nginx.conf
`-- other source files
```
If you override the Elastic Beanstalk nginx configuration, add the following line to your `nginx.conf` to pull in the Elastic Beanstalk configurations for [Enhanced health reporting and monitoring in Elastic Beanstalk](health-enhanced.md), automatic application mappings, and static files.
```
include conf.d/elasticbeanstalk/*.conf;
```
## Configuring Apache HTTPD
The Tomcat, Node.js, PHP, and Python platforms allow you to choose the Apache HTTPD proxy server as an alternative to nginx. This isn't the default. The following example configures Elastic Beanstalk to use Apache HTTPD.
**Example .ebextensions/httpd-proxy.config**
```
option_settings:
aws:elasticbeanstalk:environment:proxy:
ProxyServer: apache
```
You can extend the Elastic Beanstalk default Apache configuration with your additional configuration files. Alternatively, you can override the Elastic Beanstalk default Apache configuration completely.
To extend the Elastic Beanstalk default Apache configuration, add `.conf` configuration files to a folder named `.platform/httpd/conf.d` in your application source bundle. The Elastic Beanstalk Apache configuration includes `.conf` files in this folder automatically.
```
~/workspace/my-app/
|-- .ebextensions
| -- httpd-proxy.config
|-- .platform
| -- httpd
| -- conf.d
| -- port5000.conf
| -- ssl.conf
-- index.jsp
```
For example, the following Apache 2.4 configuration adds a listener on port 5000.
**Example .platform/httpd/conf.d/port5000.conf**
```
listen 5000
Require all granted
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
```
To override the Elastic Beanstalk default Apache configuration completely, include a configuration in your source bundle at `.platform/httpd/conf/httpd.conf`.
```
~/workspace/my-app/
|-- .ebextensions
| -- httpd-proxy.config
|-- .platform
| `-- httpd
| `-- conf
| `-- httpd.conf
`-- index.jsp
```
If you override the Elastic Beanstalk Apache configuration, add the following lines to your `httpd.conf` to pull in the Elastic Beanstalk configurations for [Enhanced health reporting and monitoring in Elastic Beanstalk](health-enhanced.md), automatic application mappings, and static files.
```
IncludeOptional conf.d/elasticbeanstalk/*.conf
```
# Application example with extensions
The following example demonstrates an application source bundle with several extensibility features that Elastic Beanstalk Amazon Linux 2 and Amazon Linux 2023 platforms support: a `Procfile`, `.ebextensions` configuration files, custom hooks, and proxy configuration files.
```
~/my-app/
|-- web.jar
|-- Procfile
|-- readme.md
|-- .ebextensions/
| |-- options.config # Option settings
| `-- cloudwatch.config # Other .ebextensions sections, for example files and container commands
`-- .platform/
|-- nginx/ # Proxy configuration
| |-- nginx.conf
| `-- conf.d/
| |-- custom.conf
| `-- elasticbeanstalk/
| `-- server.conf
|-- hooks/ # Application deployment hooks
| |-- prebuild/
| | |-- 01_set_secrets.sh
| | `-- 12_update_permissions.sh
| |-- predeploy/
| | `-- 01_some_service_stop.sh
| `-- postdeploy/
| |-- 01_set_tmp_file_permissions.sh
| |-- 50_run_something_after_app_deployment.sh
| `-- 99_some_service_start.sh
`-- confighooks/ # Configuration deployment hooks
|-- prebuild/
| `-- 01_set_secrets.sh
|-- predeploy/
| `-- 01_some_service_stop.sh
`-- postdeploy/
|-- 01_run_something_after_config_deployment.sh
`-- 99_some_service_start.sh
```
**Note**
Some of these extensions aren't supported on Amazon Linux AMI platform versions (preceding Amazon Linux 2).