Getting Started Deploying PHP Apps

Page last updated:

This topic is intended to guide you through the process of deploying PHP apps to Cloud Foundry. If you experience a problem deploying PHP apps, review the Troubleshooting section below.

Getting Started


A First PHP Application

$ mkdir my-php-app
$ cd my-php-app
$ mkdir htdocs
$ cat << EOF > htdocs/index.php
$ cf push -m 128M my-php-app

Change “my-php-app” to a unique name or you may see an error and a failed push.

The example above creates and pushes a test application to Cloud Foundry.

Here is a breakdown of what happens when you run the example above:

  • On your workstation…
    • It creates a new directory and one PHP file, which calls phpinfo()
    • Run cf push to push your application. This will create a new application with a memory limit of 128M and upload our test file.
  • On Cloud Foundry…
    • The buildpack detects that your app is a php app
    • The buildpack is executed.
    • Apache HTTPD & PHP are downloaded, configured with the buildpack defaults, and run.
    • Your application is accessible at the default route. Run cf app my-php-app to view the url of your new app.

Folder Structure

The easiest way to use the buildpack is to put your assets and PHP files into a directory and push it to CF. This way, the buildpack will take your files and automatically move them into the WEBDIR (defaults to htdocs) folder, which is the directory where your chosen web server looks for the files.

URL Rewriting

If you select Apache as your web server, you can include .htaccess files with your application.

Alternatively, you can provide your own Apache or Nginx configurations.

Prevent Access To PHP Files

In some cases, you might want to have PHP files that are not publicly accessible. You can do this by storing the files outside of the web directory (defaults to htdocs).

In addition, if you would like to have PHP files on the include_path, you can do that also. To do that, create a lib directory in your project folder and place your protected files there.

For example:

$ ls -lRh
total 0

drwxr-xr-x  3 daniel  staff   102B Feb 27 21:40 htdocs
drwxr-xr-x  3 daniel  staff   102B Feb 27 21:40 lib

total 0
-rw-r--r--  1 daniel  staff     0B Feb 27 21:40 index.php   <-- public, == 200 OK

total 0
-rw-r--r--  1 daniel  staff     0B Feb 27 21:40 my.class.php  <-- not public, == 404

It is possible to pick a different name for the lib directory. This is a configuration option in buildpack.yml that you can set (it defaults to lib). The configuration option is php.libdirectory.


To troubleshoot problems using the buildpack, review the output from the buildpack. The buildpack writes basic information to stdout, for example the files that it downloads. The buildpack also writes information in the form of stack traces when a process fails.

To get additional information out of the buildpack, you can set the BP_DEBUG environment variable to true. This instructs the buildpack to set its log level to DEBUG, and to output more verbose logs to stdout. Follow Environment Variables documentation to set BP_DEBUG.

Increase Log Output with fpm.d

If you use fpm.d, follow the steps below to configure fpm to redirect worker stdout and stderr into the logs.

  1. Create a PHP-FPM configuration snippet as described at the link above.

  2. Add catch_workers_output=yes to the file you created.

  3. Push your app.

For more information about allowed configuration settings in the PHP-FPM configuration snippet, see the List of global php-fpm.conf directives.

Create a pull request or raise an issue on the source for this page in GitHub