Language Support › PHP Support

Heroku PHP Support

Last updated 30 March 2018

This document describes the general behavior of Heroku as it relates to the recognition and execution of PHP applications.

Activation

The Heroku PHP Support will be applied to applications only when the application has a file named composer.json in the root directory. Even if an application has no Composer dependencies, it must include at least an empty ({}) composer.json in order to be recognized as a PHP application.

When Heroku recognizes a PHP application, it will respond accordingly during a push:

$ git push heroku master
-----> PHP app detected
…

If composer.json specifies dependencies of any kind in its require section, the corresponding composer.lock that gets generated by running composer update must also be committed to the repository, or the push will be rejected. This ensures that the dependencies Heroku installs are exactly the same as in any other environment. Please refer to the “Manage Dependencies” section of the Deploying PHP guide for detailed instructions.

PHP runtimes

Heroku allows you to run your application using the official PHP runtime.

Supported runtimes

Heroku’s PHP support extends to applications using PHP 5.6 (64-bit), PHP 7.0 (64-bit), PHP 7.1 (64-bit), or PHP 7.2 (64-bit).

The support for PHP release series on the Heroku platform follows the PHP Group’s support policy, typically with active updates for two years after an initial x.y.0 version, followed by a year of security updates.

The PHP runtimes have OPcache enabled for improved performance, with a configuration optimized for the specific characteristics of Heroku’s dynos.

Default runtime

Applications that do not use a composer.json, or where composer.lock contains no requirements for package php even in any dependent package, will pick the latest possible version of PHP 5.

Applications that have suitably permissive version selectors specified for package php in composer.json and all dependencies in composer.lock will use PHP 7 if all required extensions are also available for that version (see below).

Selecting a runtime

You may select the runtime(s) to use via Composer Platform Packages in composer.json. Upon a push, Heroku will read the necessary information from composer.lock, if present, and fall back to composer.json otherwise.

For example, the following composer.json will instruct Heroku to use the latest version of PHP 5 greater or equal to 5.6.0, but not PHP 7:

{
  "require": {
    "php": "^5.6.0"
  }
}

Never specify an exact version like “7.0.13” for PHP. Instead, use the “^” or “~” next significant release operators to ensure that you get appropriate updates upon push as they become available. For PHP, that means specifying “~7.1.0” will always get you the latest 7.1.x release, which will be fully compatible with other releases from the 7.1 series (but may contain security or performance updates), but not 7.2.0 or later. To get the latest PHP 5.5 or later, but not PHP 7, you’d specify “^5.5.0”.

Heroku will print the versions that were resolved and will be installed:

-----> Installing platform packages...
       - php (7.2.3)

Specifying an unknown or unsupported version will result in an error listing potential alternative versions.

PHP

Specify “php” as a dependency in the require section of your composer.json to use PHP as the runtime; for instance, for PHP 5:

{
  "require": {
    "php": "^5.6.32"
  }
}

Always prefix the minimum version you’d like to receive with the ^ selector. This ensures that you’ll receive updated versions as they become available. In the example above, you’d get PHP 5.6.32 or later, including newer versions in the 5.6.x series, but not PHP 7 (which you may want to test your application against first in case of any unexpected backwards compatibility issues).

Next, ensure that your new requirements are “frozen” to composer.lock by running:

$ composer update

Finally, don’t forget to git add and git commit both files!

Supported versions

PHP

  • 5.6.35
  • 7.0.29
  • 7.1.16
  • 7.2.4

Upgrades

If you deploy an application that does not declare a runtime version dependency, the then-latest version of PHP 5 will be used. Your application will be upgraded to more recent versions of PHP 5 if available automatically upon the next deploy.

If your application declares runtime version dependencies, the most recent version matching the version constraint will be selected for installation.

Extensions

PHP 5.6

The following built-in extensions are enabled automatically on Heroku (this list does not include extensions that PHP enables by default, such as DOM, JSON, PCRE or PDO):

The following built-in extensions have been built “shared” and can be enabled through composer.json (internal identifier names given in parentheses):

The following third-party extensions can be enabled through composer.json (internal identifier names given in parentheses):

PHP 7.0

The following built-in extensions are enabled automatically on Heroku (this list does not include extensions that PHP enables by default, such as DOM, JSON, PCRE or PDO):

The following built-in extensions have been built “shared” and can be enabled through composer.json (internal identifier names given in parentheses):

The following third-party extensions can be enabled through composer.json (internal identifier names given in parentheses):

PHP 7.1

The following built-in extensions are enabled automatically on Heroku (this list does not include extensions that PHP enables by default, such as DOM, JSON, PCRE or PDO):

The following built-in extensions have been built “shared” and can be enabled through composer.json (internal identifier names given in parentheses):

The following third-party extensions can be enabled through composer.json (internal identifier names given in parentheses):

PHP 7.2

The following built-in extensions are enabled automatically on Heroku (this list does not include extensions that PHP enables by default, such as DOM, JSON, PCRE or PDO):

The following built-in extensions have been built “shared” and can be enabled through composer.json (internal identifier names given in parentheses):

The following third-party extensions can be enabled through composer.json (internal identifier names given in parentheses):

Using optional extensions

You may declare any optional extensions you want to use via composer.json using Composer Platform Packages; simply prefix any of the identifiers in the list of extensions above with “ext-” in the package name.

For example, to enable bcmath, MCrypt, Memcached, and the third-party MongoDB:

{
    "require": {
        "ext-bcmath": "*",
        "ext-mcrypt": "*",
        "ext-memcached": "*",
        "ext-mongodb": "^1.1.0"
    }
}

It is recommended that you use “*” as the version selector when specifying extensions that are bundled with PHP, as their version numbers can be highly inconsistent (they often report their version as “0”).

Next, ensure that your new requirements are “frozen” to composer.lock by running:

$ composer update

Finally, don’t forget to git add and git commit both files!

If you do not have the desired extension available locally on your computer, the composer update step would fail because the requirements in composer.json cannot be satisfied. If you cannot install the missing extension on your computer using pecl, brew, or similar methods (something you absolutely should do in the interest of maintaining dev/prod parity), you can instruct composer to ignore the missing (so-called “platform”) requirements:

$ composer update --ignore-platform-reqs

The same --ignore-platform-reqs flag may also be used when running composer install on subsequent dependency installations in new environments, e.g. on other developers’ computers, where the extension is similarly unavailable.

Upon the next push, Heroku will install and enable the corresponding PHP extensions:

-----> Installing platform packages...
       - php (7.1.16)
       - ext-bcmath (bundled with php)
       - ext-mcrypt (bundled with php)
       - ext-mongodb (1.4.2)
       - ext-memcached (3.0.4)
       - apache (2.4.33)
       - nginx (1.8.1)

Any PHP extension required by a dependency of a project pushed to Heroku will be installed automatically, as the list of extensions to be installed is read from composer.lock.

For example, if a project depends on the stripe/stripe-php PHP SDK for Stripe, the mbstring extension required by the Stripe SDK will automatically be installed upon deploy, without the ext-mbstring package having to be listed explicitly in the require section of your main composer.json.

Customizing settings

PHP

Any .user.ini file that is placed into a project according to the instructions in the PHP manual will be loaded after the main php.ini. You can use these to set any directive permitted in PHP_INI_ALL, PHP_INI_USER and PHP_INI_PERDIR contexts.

For additional details on this and other ways of customizing settings for the PHP runtime, please refer to the corresponding Dev Center article.

Build behavior

Installation of dependencies

The following command is run during a deploy to resolve dependencies unless composer.json is empty and no composer.lock is present:

$ composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction

Heroku will not install development dependencies from the require-dev section of composer.json. However, if the require-dev section contains a PHP runtime version requirement or lists a dependency that contains such a requirement, then the require section of composer.json must also contain a PHP runtime version requirement or list a dependency that contains such a requirement. This is to ensure that Heroku does not select a default PHP runtime version that conflicts with what other environments (which include require-dev dependencies) install.

The installed version of Composer will be printed for your reference before installation begins. Builds are currently run using Composer version 1.6.3.

Composer’s cache directory is preserved between pushes to speed up package installation.

Custom compile step

For applications that wish to execute an additional compilation step during a build that shouldn’t be part of a standard post-install-cmd Composer script, for example an asset compilation or cache pre-warming procedure, a compile custom command, if present in composer.json, will be executed using the following command:

$ composer compile --no-dev --no-interaction

Any such custom script command defined in composer.json can either be a single string, or an array of multiple commands to execute; example:

{
  "scripts": {
    "compile": [
      "php app/console assetic:dump --env=prod --no-debug",
      "MyVendor\\MyClass::postDeployComposerCallback"
    ]
  }
}

Composer’s bin-dir is pushed on top of $PATH during command execution, so binaries installed by dependencies are easily accessible as CLI commands when writing scripts without having to use vendor/bin/ or a similar prefix.

Custom Composer versions

If the application contains a composer.phar in the root directory, then that executable will be used instead of the version provided by Heroku.

Running your own version of Composer is not recommended. If you use this feature, you will need to make sure that your version of Composer is up to date. Heroku will not run composer self-update before.

Custom GitHub OAuth tokens

To use code from private GitHub repositories as Composer dependencies, a personal OAuth token can be set for authentication. To use such a token on Heroku, follow these steps:

  1. Create a new Token (you do not need to select any scopes, unless you want to pull packages from private repositories, in which case, selecting only the repo scopes will suffice)
  2. Copy the token for use in the next command
  3. $ heroku config:set COMPOSER_GITHUB_OAUTH_TOKEN=YOURTOKEN (replacing “YOURTOKEN” with the actual token from the previous step, of course).

Now, pushes to Heroku will use your token during composer install, and Heroku will confirm its usage:

-----> Installing dependencies...
       NOTICE: Using custom GitHub OAuth token in $COMPOSER_GITHUB_OAUTH_TOKEN

The private repository URL in your composer.json must use the https:// and not the git:// protocol for Composer to be able to use the OAuth token for authentication.

For more information, you may also refer to the troubleshooting section in the Composer documentation.

Runtime behavior

The $PATH environment variable contains all necessary paths for an application to function at runtime. The Composer bin-dir is appended to $PATH for convenience.

Web servers

Heroku supports Apache 2.4 (2.4.29) and Nginx 1.8 (1.8.1) as dedicated Web servers. For testing purposes, users may of course also use PHP’s built-in Web server, although this is not recommended.

In the absence of a Procfile entry for the “web” dyno type, the Apache Web server will be used together with the PHP runtime.

Apache

Apache interfaces with PHP-FPM via FastCGI using mod_proxy_fcgi.

To start Apache together with PHP-FPM and all the correct settings, use the heroku-php-apache2 script in the Composer vendor bin dir (usually vendor/bin):

web: vendor/bin/heroku-php-apache2

Vendor binaries are usually installed to vendor/bin by Composer, but under some circumstances (e.g. when running a Symfony2 standard edition project), the location will be different. Run composer config bin-dir to find the right location.

By default, the root folder of your project will be used as the document root. To use a sub-directory, you may pass the name of a sub-folder as the argument to the boot script, e.g. “public_html”:

web: vendor/bin/heroku-php-apache2 public_html

You can use regular .htaccess files to customize Apache’s behavior, e.g. for URL rewriting. For additional details on this and other options to customize settings for Apache, please refer to the corresponding Dev Center article.

Nginx

Nginx interfaces with PHP-FPM via FastCGI.

To start Nginx together with PHP-FPM and all the correct settings, use the heroku-php-nginx script in the Composer vendor bin dir (usually vendor/bin):

web: vendor/bin/heroku-php-nginx

Vendor binaries are usually installed to vendor/bin by Composer, but under some circumstances (e.g. when running a Symfony2 standard edition project), the location will be different. Run composer config bin-dir to find the right location.

By default, the root folder of your project will be used as the document root. To use a sub-directory, you may pass the name of a sub-folder as the argument to the boot script, e.g. “public_html”:

web: vendor/bin/heroku-php-nginx public_html

For additional details on different ways of customizing settings for Nginx, please refer to the corresponding Dev Center article.

PHP Built-in Web server

For testing purposes, you may start PHP’s built-in Web server by using php -S 0.0.0.0:$PORT as the entry for “web” in your Procfile:

web: php -S 0.0.0.0:$PORT

The Procfile must contain $PORT in the line shown above. It’s used by Heroku at runtime to dynamically bind the web server instance to the correct port for the dyno.

It is important to bind to all interfaces using 0.0.0.0, otherwise Heroku’s routing won’t be able to forward requests to the web server!

You may also pass an alternative document root or use a so called router script to process requests. For details, please refer to the documentation for the built-in Web server.

Feedback

Log in to submit feedback.