HTTP caching, custom PHP configurations, build dependencies

Augustin Delaporte
Augustin Delaporte
Director of Fleet & Enterprise
10 Nov 2014

Deploy our Node.js template for free

Deploy on


We have been busy! Today, we are happy to announce three important new features of

  • Support for HTTP caching at the web server level, finely configurable on a per-route basis;
  • Support for tweaking the PHP configuration, by enabling / disabling extensions and shipping your own  php.ini ;
  • Support for specifying build dependencies, i.e. PHP, Python, Ruby or Node.js tools (like  sass grunt uglifyjs  and more) that you want to leverage to build your PHP application.

HTTP caching now has an integrated reverse proxy cache, similar to Varnish but built directly into our web server (based on Nginx). The cache strategy is configurable on a route-by-route basis directly in your  .platform/routes.yaml  file.

We decided to go with a simple, easy to understand, caching strategy. As most of the CDNs before us, we do not support the  Vary  HTTP header. Instead, we give you the ability to explicitly specify how the cache key is built. You can specify which cookies are whitelisted and part of the cache key, and which headers (in addition to the default headers) also participate.

The default configuration whitelists all the cookies and some selected headers that are often used for content negotiation ( Accept  and  Accept-Language ):

type: upstream
upstream: php:php
enabled: true
headers: [ "Accept", "Accept-Language" ]
cookies: [ "*" ]

You can tweak this configuration to fit the use case of your application, and you can also completely disable caching on the route:

type: upstream
upstream: php:php
enabled: false

Read more about configuring the cache on our documentation.

Custom PHP configurations now supports custom PHP configurations. You can specify this configuration directly in the  file, and you can also provide a  php.ini  file in your project, for additional configuration tweaks.

In your  configuration file, you can now add a  runtime  key like:

- http
- ssh2
- sqlite3 comes with  pdo mysql mysqli pdo_mysql sqlite3 pdo_sqlite3 gd curl intl mcrypt  and  zendopcache  extensions enabled by default. You can disable those by adding them to the  disabled_extensions  list.

In addition, we ship with  enchant gearman geoip gmp http imagick imap ldap pgsql pdo_pgsql pinba pspell recode redis snmp spplus ssh2 tidy xdebug xmlrpc  and  xsl  that you can enable.

You can also provide a  php.ini  file that will be appended to the configuration maintained by This file needs to be at the root of the application at the end of the build process, so depending on your build process, you might have to move it in place in a  build  hook.

Note: we do not limit what you can put in the php.ini file in any way, but many settings can completely break your application. This is a facility for advanced users.

Build dependencies

Last but not least, the build process of now supports specifying build dependencies. Modern web applications often depend for their build process on tools that are written in a different language than that application itself. So we are now allowing you to specify those dependencies easily, regardless of the stack your application is written in.

We support pulling PHP, Python, Ruby and Node.js dependencies. Those dependencies are independent of the eventual dependencies of your application, and are available in the  PATH , during the build process and in the runtime environment of your application.

You can specify those dependencies directly in your , like this:

drush/drush: "6.4.0"
behave: "*"
sass: "3.4.7"
grunt: "~0.4.5"

And yes, that means that you can now specify the version of  drush  you want for Drupal projects.