The Common Web Platform (CWP) is designed to accommodate the next generation of government websites, allowing multiple agencies and vendors to work as a community to build a variety of websites, while making use of shared infrastructure, software, and tools.

CWP Technical architecture

The technical architecture of the platform is summarised in the Detailed diagram showing CWP architectureCWP Architecture Overview [PDF, 1.3 MB] (Updated 1 March 2015). If agency staff would like to read the solution architecture document, contact

The architecture of solution:

  • contains built-in controls that offer protection against security attacks, including a Web Application Firewall.
  • uses Infrastructure as a Service to provide hosting, backup, and disaster recovery, with all services hosted in New Zealand.
  • is flexible to accomodate websites changing in size and demand.
  • is based on open source software, including Debian Linux, Apache, MySQL, PHP 5 or PHP 7, Silverstripe CMS, Solr, and GitLab.

Managing, sharing and deploying code

CWP provides online tools to improve the management and deployment of code. These are setup when an agency requests a new stack of CWP. The code repository makes it easy for agencies to share and collaborate on code.

GitLab, the shared code repository

GitLab is used to manage website code on CWP. It enables sharing, collaboration, and audit trails of the code it stores. It is run securely on the CWP infrastructure, to keep code in New Zealand. Agencies can choose whether code they produce is private or shared, on a case by case basis. Find out more about GitLab(external link).

Dashboard, the website deployment tool

Dashboard publishes code from Git Repository to the testing and production servers, and allows databases and files to be transferred from one environment to another. By automating the process using repository numbers, it reduces the risk of error and makes rolling back to a previous version easy.

Deploying code on CWP

CWP standardises how code is deployed to websites. For many agencies this will introduce better change control, and reduces the risk of outages or defects being released to production. It also makes deploying code quicker and easier.

The following graphic illuatrates the deployment pattern. It is explained in the paragraph below.

Deployment pattern for CWP, read explanation in next paragraph.

Deployment pattern for CWP

Code is developed on a local environment, then published GitLab. The developer then deploys to the test server using Dashboard. Once the testing and review is complete, a request is made to release the code to production. Find out more about how to deploy code on CWP.

Using GitLab to start development prior to setting up a Stack

Participating agencies can start using the GitLab code repository for developing a website, before they have set up and begun paying for a Stack. They can then request the Stack when they are ready to start testing.

Commercially Supported Modules

Supported by an active open source community, Silverstripe CMS modules extend SilverStripe CMS, providing additional functionality such as blogging, user customisable forms, workflow, and lots more. Commercially Supported Modules take this one step further. By having the backing Silverstripe Ltd, there is a dedicated team of developers actively maintaining these modules.

As well as having the advantages of being open source community projects, Commercially Supported Modules have:

  • Compatibility with the latest Silverstripe CMS stable release.
  • Security patches applied immediately.
  • Major bugs squashed quickly.
  • High level of testing to ensure quality.
  • User and technical documentation.

By using Commercially Supported Modules, agencies and developers can build projects with confidence, knowing these modules have been tested and have the backing of Silverstripe Ltd.

'Commercially supported' does not necessarily mean we add additional features over time - see how will CWP improve over time.

Agencies can pay to have a module added to the commercially supported modules list - see Module or extension warrantees. This is useful when an agency has developed a module they rely on.

Developers are encouraged to use Community Supported Modules (from the open source community) alongside Commercially Supported Modules. Many of these modules are high quality and provide functionality not available in the Silverstripe CMS Commercially Supported Modules sub-set.

The following warranties are provided for Commercially Supported Modules as part of the CWP Lead Agency Agreement:

(i) there will be no loss of, degradation to, or new defects in the functionality and performance of any of the Participating Agency’s Stacks where the upgrade takes the form of a point release (for example, from version 3.0.2 to 3.0.3);

(ii) there will be no loss of, degradation to, or new defects in the functionality and performance of the version of any extension (module, theme or widget) that was certified by the Service Provider in accordance with the certification process set out in the Operational Procedures Manual prior to the upgrade where the upgrade takes the form of a point release (for example, from version 3.0.2 to 3.0.3) or a minor release within the current major release (for example, from version 3.0.3 to 3.1.0); and

(iii) there will be no loss of, degradation to, or new defects in the functionality and performance of the latest version (prior to the upgrade) of any extension (module, theme or widget) that, prior to the upgrade, came bundled with the Content Management System, where the upgrade is a point release, minor release, or a major release (for example, from version 3.1.0 to 4.0.0), except to the extent that the Service Provider has: (A) deliberately replaced such an extension with a new or substitute extension that, again, is bundled with the Content Management System; or (B) deliberately removed and not replaced such an extension due to its low usage by Participating Agencies and/or other users;

In response to this, Silverstripe Ltd. Commercially Supported Modules meet each of these obligations:

(i) by ensuring that all modules that make up the CWP basic recipe follow “Semantic Versioning”(external link).

(ii) by following Semantic Versioning, and amending the list of Commercially Supported Modules(external link), making sure this is available and up to date.

(iii) in addition to following Semantic Versioning, we have a process for validating whether a feature should be removed from a module or moved to a different Commercially Supported Module, and where a features hasn’t been deliberately dropped by this process treat any missing feature as a bug.

Overall, this means that we should take reasonable steps to avoid bad things happening in the first place, and if they do, we will fix the sites (or, more likely, the product) at our own cost.

Managing data

Dashboard(external link) tool allows you to transfer data to, from and between particular environments that comprise the stack. By automating these processes it avoids common mistakes and makes sure the process is reversible by taking automated backup.

Roles differ in terms of access permissions to specific environments. For example access to production data is restricted due to data confidentiality requirements.

Find out more about data transfers in the tutorial.

Secure access for a CWP website

Agencies can configure websites to be locked down or accessible only via encrypted connections, through a variety of means. This enables the platform to be used for intranets, and for websites, where all or part of the content is restricted to certain users. Specific techniques are available and include:

  • Restricting the environment to a whitelist of IPv4 and IPv6 addresses (which can, in effect, mean the environment is limited to access from a particular VPN)
  • Requiring users to log in with username/password and/or authenticating via an external means such as Active Directory, LDAP, or RealMe login service for any government website that is directly accessible via the internet
  • Forcing some or all of a website to be served over HTTPS

Development and configuration effort and/or costs may apply for anything beyond simple IP whitelisting.

Integrating a CWP website with other systems

Websites can connect to back-office systems and other sources of data through APIs. This allows transactional services to be delivered through the website. API support is built into the CWP install of the Content Management System.

There are various techniques to ensure the secure transmission of data over an API:

  • IP whitelisting
  • Tokens and authentication
  • VPN (Virtual Private Networking)

Websites can connect to verified attributes held by the authoritative source via the RealMe assertion service. Verified identity and verified address are currently supported with plans to add citizenship, visa status and qualifications. Assertion service support is provided by the CWP RealMe module.

Please note, statements on this page may not apply to the Mini stack

Last modified: