A year and half ago, we launched support for PHP on Heroku, built from the ground up with modern features designed to give developers a more elegant and productive experience on the platform. Last week, we made PHP 7 available on top of a new, reworked version of our PHP support, and our users are adopting PHP 7’s exciting new features and stellar performance improvements quickly—we’re already seeing PHP 7 being used in the majority of PHP deploys on Heroku.
Under the hood, much of the logic that handles a deploy has changed, but not the fundamental principles upon which our support for PHP applications is designed. We've always been determined to provide a fully standards-based implementation that does not rely on proprietary configuration or magic behavior, and that means building on top of a great foundation of tools.
Composer Rising
Inspired by an explosion of collaboration in Open Source that had been sparked by GitHub in general and their Pull Requests 2.0 in particular, the PHP ecosystem witnessed the birth of Composer in 2011. Thanks to the inspiring and ongoing work of Jordi Boggiano, Nils Adermann, and all other contributors to the Composer project, the result has been a perpetual cycle of growth in collaboration, quality and popularity across frameworks and libraries.
Today, even competing frameworks make liberal use of each other’s components, because the PHP community at large has adopted a culture of sharing and of working together. Developers benefit from faster release cycles and a wealth of packages to choose from. Packagist, the official Composer package repository, is now serving well over 100 million package installs per month, and will be on the verge of cracking the mark of a billion and a half installs before this year is out.
That's why Heroku has always honored a project’s composer.json (or, more specifically, composer.lock) for not only the installation of dependencies, but also when resolving which language runtimes and extensions to install—there is no admin panel or separate configuration for runtimes and extensions. If a user requires PHP 5.5.*, they get the latest PHP 5.5. If a user wants the latest possible PHP version, but also needs an extension that is not yet available for PHP 7, they get the latest PHP 5.6.
Thanks to this behavior, we've already seen a lot of deploys getting resolved to PHP 7. Currently, over 50% of all PHP application deploys on Heroku are getting built using PHP 7.0.
This number could be even higher, but we're being cautious about the default version—if a user specifies absolutely nothing regarding their required PHP version, they will get the latest PHP 5.6, as that is a safer bet for backwards compatibility with legacy applications. Extensions are also a factor: once common ones like memcached or redis are ready for PHP 7, we're expecting even more applications to make the switch.
The system now actually uses Composer itself during the build to install not only application dependencies, but also language runtimes and extensions. This allows us to give users useful hints about requirements that cannot be satisfied, or conditionally auto-install extensions for add-ons such as New Relic without interfering with the pre-determined set of dependencies. We will be rolling out even more exciting user-facing features and performance improvements that build upon this architecture in the coming weeks and months.
Take It For a Spin
All you need to deploy an application using PHP 7 today is a composer.json that has a sufficiently lenient version selector for PHP 7. You should also ensure that none of your dependencies prevent the use of PHP 7. The PHP Support reference article on Heroku Dev Center provides an overview of available runtimes and extensions.
Our Getting Started with PHP on Heroku guide will walk you through the simple steps of creating a free Heroku account (if you don't have one yet) and deploying your first app—it'll be built using PHP 7!
Alternatively, why not start a new app from scratch, or deploy an existing application? Any suitable version requirement for package php such as >=5.3.3 or ^5.6.0|^7.0.0 will work. You can use the composer require command to quickly update your preferences to allow both 5.6+ and 7, e.g.:
$ composer require "php:^5.6|^7.0"
After that, git add composer.json composer.lock, commit the change, and push!