Beginning on September 24, we started rolling out the new PHP Runtime Generation 2 to all sites on the platform. This is the first major update to our PHP runtime. This post will dive into what this actually means and why we are doing this.
What’s a PHP runtime?
Pantheon uses a containerized architecture based on Google Cloud. In the early days of the internet, a single machine could run your entire site: web server software (Apache, Nginx, Lighttpd, etc.), database server software (MSSQL, MySQL, MariaDB, etc.), application logic for whatever language you intended to use (PHP, Node.js, Perl, .NET, Python, Ruby, etc.) and probably a Linux operating system as the foundation of it all (Debian, Ubuntu, Red Hat, Suse, etc.).
Today, cloud-based architecture splits these responsibilities across many different containers. This allows processing time to be distributed between the disparate systems, so a large database query doesn’t affect your PHP application’s ability to render a page. Containerization also means that those systems can be scaled up or down depending on usage, rather than requiring a physical server in a data center somewhere that would manually need a hardware upgrade to increase its memory or storage capacity.
Your WordPress or Drupal site runs on the application server. But the application server isn’t a single entity. It’s not a physical machine in a data center. Rather, it’s a collection of smaller containers, each performing a specific task, while one of them handles the PHP runtime.
When Nginx receives a request, your PHP runtime processes that request. The PHP extensions and libraries included in your runtime determine what features your site can use to render pages for visitors. So, the PHP runtime plays a pretty important role in the overall Pantheon stack. Why are we changing it?
What’s changing and why?
We’ve been maintaining Debian-based PHP runtime images for some of our cloud-based infrastructure for some time. We’re already familiar with the maintenance requirements for Debian-based systems. Additionally, Debian has a long history of prioritizing stability and maintainability over bleeding-edge updates. This makes it more predictable, reliable and easy to maintain. And we have partnered with Freexian to provide long-term support for our Debian-based PHP runtimes for end-of-life versions of PHP (which is currently anything 8.0 and below), ensuring that our old PHP images continue receiving security patches while you plan and implement PHP upgrades.
Our Generation 1 PHP runtime is running on CentOS, a Linux distribution that shares much of its code with Red Hat Enterprise Linux (RHEL). Originally, CentOS was a free, open-source alternative to RHEL that took its open source code and redistributed it without the paid support from Red Hat. Ultimately, Red Hat acquired CentOS and discontinued it as a standalone distribution in 2021. That left us in a bind – either upgrade to Red Hat Enterprise Linux (and incur the associated costs) or migrate away from CentOS entirely. PHP Runtime Generation 2 represents the latter.
Debian-based imagery
Ultimately, we’re changing the PHP runtime for several reasons. First and foremost, we are ready to move to Debian-based images. This will make overall maintenance of the runtime images easier and ensure that our systems are more reliable and consistent. Secondly, to provide a higher layer of security through the Freexian LTS PHP versions and to run updated versions of PHP extensions and server software that were not compatible with the old operating system or required manual compilation to make it compatible (not needing to manually compile the PHP runtime image also makes our containers spin up faster).
Running an entirely new operating system means that essentially everything needs to change. While we were using Debian for Cloud Run images for site maintenance services, those images lacked most of the PHP extensions and application-layer packages, which we’ve been adding over the years to support various use cases. In fact, those runtimes are intentionally minimalist – installing only the bare essentials – to ensure they are faster to create on demand. And in the grand ecosystem of Linux, there are significant differences between Debian-based systems and Red Hat-based systems, from the package managers down to what packages are even available.
We couldn’t just build all the same stuff on Debian in the same way we were doing it on CentOS, and in many cases, we needed to find the “Debian way” of doing the same thing we had been doing in CentOS. This meant that we needed to make careful choices about what and how we were going to install packages, all with an aim to keep build times down and manually compile packages as little as possible (instead, favoring pre-built packages we can just install).
Therefore, we’re happy with the fact that we’ve been able to move over the majority of the packages and extensions we were running on Generation 1. Most of the packages that are not currently supported are things that were already at the end of life.
No more support for TLS 1.0 and 1.1
Another significant change in Runtime Generation 2 is that we’re dropping support for TLS (Transport Layer Security) 1.0 and 1.1. TLS is a cryptographic protocol that protects your data from being intercepted. It’s the “s” in https. TLS 1.0 dates back to 1999, and 1.1 came 7 years later in 2006. They’ve been deprecated since 2018, lack support for modern encryption ciphers and may be vulnerable to exploits.
Most connections use the more modern TLS 1.2 or 1.3 versions, and many browsers and libraries don’t support old TLS versions. In our Runtime Generation 1 images, we’ve intentionally added back support for the outdated TLS 1.0 and 1.1, while in Generation 2, we’ve stopped doing that. If you’re concerned that this update might break outgoing connections to external APIs or servers your site is making, I wrote a WordPress plugin and Drupal module to check the TLS support of URLs found in your codebase.
What you can expect during the rollout
The planned rollout will be gradual. We’re rolling changes out to sites over the course of 60 days beginning in September 2025. Within that timeframe, Dev and Multidev environments will get the update first, with Test and Live environments receiving the automatic update last.
In practice, the update could happen faster (or slower) if you want. When code changes are pushed to Test and Live from a Dev environment that has received the Runtime Generation 2 update, the PHP runtime will be updated on those environments with the change. This allows you to test in Dev and Test to ensure everything is working before pushing to Live. However, if you need more time or you run into issues in testing Runtime Generation 2, you can opt out by fixing your version to Generation 1 in your pantheon.yml file.
We will discontinue Runtime Generation 1 in early 2026. Offering both runtime versions increases our maintenance burden. But also, we want people to upgrade. The old runtime is, well, old. While it’s served us well, it’s time to retire it and move to a more maintained and maintainable solution. Runtime Generation 2 is also the only way you can upgrade your servers to PHP 8.4. Future releases, such as PHP 8.5 and 9.0, will also be available exclusively on Runtime Generation 2 (or its successors). Generation 1 will only ever support a max of PHP 8.3 (which will drop to security-only updates in January 2026 and End of Life in January 2028).
Our goal is for you not to notice any changes after the 60 days when the rollout is complete. Your sites should automatically migrate over to the new runtime version. For our part, this is an important step in updating our infrastructure, making it easier to update and reduce the time needed to push out updates. PHP Runtime Generation 2 (and future versions) is a significant yet largely invisible part of how we work behind the scenes to ensure your sites run smoothly and use modern, secure software.
