HTTP caching, custom PHP configurations, build dependencies

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

• 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

Platform.sh 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 ):

http://{default}/:
type: upstream
upstream: php:php
cache:
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:

http://{default}/:
type: upstream
upstream: php:php
cache:
enabled: false

Read more about configuring the cache on our documentation.

Custom PHP configurations

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

In your  .platform.app.yaml  configuration file, you can now add a  runtime  key like:

runtime:
extensions:
- http
- ssh2
disabled_extensions:
- sqlite3

Platform.sh 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 Platform.sh. 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 Platform.sh 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  .platform.app.yaml , like this:

dependencies:
php:
drush/drush: "6.4.0"
python:
behave: "*"
ruby:
sass: "3.4.7"
nodejs:
grunt: "~0.4.5"

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