The high level CWP infrastructure is outlined on cwp.govt.nz. More detail is available through a solution architecture document on request to participating agencies. See technical and architecture information. Please review our Performance Guide for recommendations on how to use the available infrastructure efficiently.

HTTP request time limit

The PHP execution limit (max_execution_time) is 30 seconds, after which a 503 (Service Unavailable) error will be returned.

The CWP "Gateway" server which fronts all CWP stacks has a HTTP request timeout limit of 120 seconds, after which it will generate a 504 (Gateway Timeout) error. This is preventing overloading of the shared parts of the infrastructure.

Your publicly accessible URLs should never take a long time to process, as this leaves your environment open to denial of service attacks. You should definitely hide these behind a login or a captcha, or use caching and other optimisations to bring down the processing time.

The preferred way to handle your long-running processes is via the queuedjobs module. You can extend the time limit of a PHP process by using:

  • SilverStripe Framework v4's \SilverStripe\Core\Environment::increaseTimeLimitTo()
  • SilverStripe Framework v3's increase_time_limit_to

Consider using caching to speed up request execution.

PHP configuration

CWP environments run PHP 7.3 by default. Silverstripe CMS sites running Framework/CMS version 3.6 and up support PHP 7. Environments with your stack can be modified to run either PHP 7.3 or PHP 7.4 via a request to the helpdesk, or using a .platform.yml file in the root of your project if your stack has been enabled for self-service:

  version: '7.4'

PHP versions are supported for two years after their initial release, with an additional year for critical security issues only. We recommend keeping your PHP version up to date and set to either 7.2, 7.3, or 7.4.

  • PHP 5.6: no longer supported
  • PHP 7.1: no longer supported
  • PHP 7.2: no longer supported
  • PHP 7.3: security support ends 6th December 2021
  • PHP 7.4: security support ends 28th November 2022

We generally don't recommend configuring PHP via ini_set calls inside your custom PHP code, nor by using php_value inside .htaccess files (exception: memory_limit, see below).

Reconfiguring PHP using those methods may conflict with platform internals and lead to instability and security issues.

The following configuration settings are explicitly reserved for internal purposes:

  • auto_prepend_file
  • auto_append_file


The default memory_limit configuration is 128 MB. You can increase this to 256 MB with ini_set('memory_limit', '256M'); in your code. Please call this on a per-script basis. Increasing the limit for all requests increases the likelihood of server instability with high traffic. If you have a script which requires more than 256 MB, we typically recommend making it a task, runnable from a cron job on a schedule. Please raise a ticket via the CWP Service Desk for help with this.

PHP extensions

Environments within a CWP stack are turnkey deployments of a standardised environment. For security and supportability reasons we don't allow the installation of binaries, PHP extensions or other deviations from the standard environment that are not encapsulated within the PHP code deployed into the environment.

These PHP extensions are part of the standard environment, and can be relied on to be available:

  • curl
  • gd
  • mbstring
  • mcrypt
  • tidy


CWP environments are running Apache 2.4 (see Debian "Buster" packages). Note that there's other caching infrastructure in front of your CWP environment.

Document root

Apache's DocumentRoot directive is currently configured to point to the root path of the code repository.

For Silverstripe CMS Recipe 4.x (CWP Recipe 2.x), we strongly recommend retaining the recipe's .htaccess file verbatim. Additional .htaccess directives, such as redirects, should be added to public/.htaccess. For future-compatibility, the new redirects should be tested against both DocumentRoot pointing to repository root and pointing to public directory within the repository.


CWP is running on MariaDB 10.3 (see Debian "Buster" packages). For local development, you can also choose MySQL 5.7.

Hosting video

CWP stacks don't provide built-in hosting of video content, and we recommend you don't attempt to do so.

Instead, we recommend hosting video on a third-party service, such as vimeo.com. They provide a simple, turn-key solution optimised for hosting video that is easily integrated with CWP environments.

Since the resource allocated to a CWP environment is directly related to the cost per month for a stack, we have optimised the network bandwidth allocated to an environment for hosting standard HTML content and regular files such as pdfs, docs, etc. Video files are much larger than most other assets, and exceed this network bandwidth. Attempting to host video files will cause severely degraded performance for your other users.

If you do need to host video within CWP, please contact us to have a quote provided for a custom stack with sufficient bandwidth for hosting. You will also need to provide your own solution for other elements of video hosting, such as:

  1. Transcoding the video to the variety of formats needed by different web-enabled devices
  2. A player that provides the necessary controls and accessibility extensions to the devices' built-in video playing support

Code patching

Some Silverstripe CMS security vulnerabilities are live-patched using a post-deploy script. This script applies patch files to your codebase based on the version detected from the composer.lock file.

We currently require the lock file to use tagged versions of the silverstripe-framework and silverstripe-multivaluefield modules. Branch aliases such as 3.2.x-dev are not permitted and will cause deployments to fail with "integer expression expected" message. This is because the current solution is unable to resolve if the version being aliased is vulnerable.

Other features

Process for new infrastructure features

Where your business requirements necessitate a server-side feature that is not currently present, there are several options available:

  • Wrapping of the feature as a web application hosted outside the CWP infrastructure (either at your own cost or through an external provider)
  • Integration of the feature as a CWP standard feature, either through directly funded work or through the co-fund pool (we are unlikely to accept requests to integrate features that duplicate functionality already present within CWP)

Was this article helpful?