What are my database credentials?

You will never need to know your database credentials for Silverstripe Cloud. Database parameters are configured outside of your project in the environment file, which is managed by Silverstripe Cloud.

What database versions are available?

Currently only MySQL 5.6 is available.

How do I add environment-specific configurations?

Environment variables can be added in a few different ways and how you add them may depend on what you’re adding.

Sensitive data such as API credentials should never be stored in the public root of the website. Instead these should be added into the environment file which is managed by Silverstripe Cloud. You can add public values to this file in the variables section of Cloud, or if you’d like some hidden from view, by submitting a Service Desk ticket.

For non-sensitive data you can use the config system as documented in the open-source documentation.

An example of how this could be used:

  environment: 'dev'
  show: true

This is equal to doing the following in mysite/_config.php

if(SS_ENVIRONMENT_TYPE == 'dev') {
  Config::inst()->update('DeveloperToolbar', 'show', true);

Its recommended that you use YAML and limit calls to Config::inst()->update() as much as possible. YAML is cached on flush which brings increased performance over using PHP which must be merged into config on each page load.

Why can’t I deploy to production?

By default production deployments are restricted to release manager and stack manager only. If other members of the team require permission to deploy, the stack manager can request this through a Service Desk ticket.

You can find out more on the roles page.

Why can’t I take a production snapshot?

Just like deployments, the production environment is considered to be sensitive and include restricted data by default. Release managers and stack managers can take a snapshot and transfer ownership to other team members, or the stack manager can request for access to be given to other team members through the Service Desk.

How do I use a private module?

The first step is to add your module using composer. The following solution is taken from the composer documentation.

  "require": {
    "vendor/my-private-repo": "dev-master"
  "repositories": [
      "type": "vcs",
      "url":  "git@bitbucket.org:vendor/my-private-repo.git"

The next step is to give Silverstripe Cloud access to your git repository using the public key present in the project view.

How this is done depends on what your remote git server looks like. If you’re using Silverstripe’s hosted version of Gitlab you should already have the deploy key available to your account. You can simply go into the project’s settings page, click into deploy keys and enable the deploy key which corresponds with your stack name.

If you’re using another service you can follow their documentation on adding deployment keys:

  1. Github
  2. Bitbucket

Why can’t I see my website?

By default, our environments are whitelisted to our offices only. To add your IP addresses to the whitelist, or to remove the whitelist altogether, please see the whitelist section.

Why do error pages return a good HTTP response (HTTP 200)?

In Silverstripe CMS 3, error pages would previously return a good HTTP response. This has since been fixed in Silverstripe CMS 4 to always return the correct status code. To make your Silverstripe CMS 3 site behave the same way, add this YAML config to your site:

  friendly_error_httpcode: true

Can I connect directly to my RDS database?

By default, your RDS database isn’t connected to the outside world, to keep things as secure as possible. However some developers require direct access to the database to run custom queries.

In these cases, we can set up a proxy that will provide you access. To ensure a good amount of security, we require the following:

  • We will restrict incoming connections to an IP whitelist
  • We only support SSL connections

To get started, please raise a support ticket and give us the following information:

  • The IP address ranges that need to be granted access
  • The full names, email addresses and mobile phone numbers of the people that need access

We will set up the services and email each person who needs access the following details:

  • IP address
  • Internal Hostname
  • Username

We will send the Password to the phone number.

To connect to the MySQL server, use the following connection settings:

If you want to verify the SSL certificate to avoid man-in-the-middle attacks,you will need to add a hosts file entry on your computer because the SSL certificate we use is provided by Amazon and uses a domain name that we can’t control. One of the details we send you is an “Internal hostname” that looks something like this:

<your stack>.<something random>.ap-southeast-2.rds.amazonaws.com

You will need to add a “hosts file” entry that maps this Internal Hostname to the IP address we supplied. For instructions on how to do this, see this “Modify your hosts file” guide.

Once you have done that, use the following connection settings for accessing MySQL:

Can I commit files to the assets directory?

Due to the way assets are stored on Cloud, any files committed to the assets directory will not apply to the live servers. If you need to add important files to the assets directory, such as custom .htaccess configuration, you will need to use snapshots to ‘restore’ them to the server.

Why isn’t mod_expires applying to my assets?

Silverstripe Cloud uses Nginx to serve static assets, in front of Apache. This means that any configuration set in an .htaccess file will not be applied unless you specifically tell Nginx to pass it through for Apache to serve. You can do this using url_rules in your .platform.yml file.

How do I change the git repository associated with my stack?

If you are a Stack Manager, then you can change the git repository yourself through Silverstripe Cloud. To do so click on the “Stack edit” button on the environment listing page.

Silverstripe Stack

Otherwise you will need to contact your Stack Manager or Service Desk for help.

How do sessions work on Silverstripe Cloud?

In a typical non-distributed environment, PHP saves session information on the server’s local hard-drive. In a cloud environment, the user can be load balanced between multiple servers and the user session information must be accessible from each server. In Silverstripe Cloud we provide a Silverstripe module, silverstripe/dynamodb, to automatically configure the environment to store session information in AWS DynamoDB, a distributed key-value storage.

You might notice differences between your local environment’s behaviour in regards to sessions versus how Cloud handles them; you can emulate Cloud’s distributed sessions by installing the Hybrid Sessions module and using the following in mysite/_config.php

if (Director::get_environment_type() !== 'live') {
  Config::inst()->remove('HybridSessionStore', 'dependencies');
  Config::inst()->update('HybridSessionStore', 'dependencies', ['handlers' => ['%$HybridSessionStore_Database']]

Which version of [software package] am I running?

Versions for system packages like PHP or Apache are largely dependent on your infrastructure version. Check the changelog for more details on a particular infrastructure release.

The database version can’t be configured yet, and is not updated as part of an infrastructure release. Please (contact support) to find out which version you’re running. All databases on Silverstripe Cloud are compatible with at least MySQL 5.6.

How do I configure my stack for silverstripe/secureassets?

silverstripe/secureassets is a module for Silverstripe CMS 3 that lets you control access to particular asset files. It relies on .htaccess to do that, so all requests to files that could potentially be restricted must be forced to go through apache.

Ordinarily, your stack will serve asset files directly from nginx to speed things up. To make your stack compatible with the silverstripe/secureassets you will need to add some URL rules into the base stack’s .platform.yml.

The easiest, but least-performant way, is to use the catch-all rule:

    - '^/assets/': 'apache'

If your site is on a virtual stack, you will need to reconfigure URL rules in your base stack’s .platform.yml instead:

    - '^/assets/': 'apache'
    - '^/assets/': 'apache'

If you find your overall site’s response times suffer too much, you can try writing the URL rules to cover just some sub-paths. We don’t recommend this approach as it comes with the risk of files leaking out - files outside of the configured paths will remain public, even if the CMS user sets them to private.

Alternative solution is to upgrade to Silverstripe CMS 4, which bundles secure assets in core.

Where can I find more in-depth technical details?

Detailed documentation about the technical infrastructure, security considerations and processes behind Silverstripe Cloud is available through a Solution Architecture Document. Please contact support to gain access.

My question isn’t answered here. What do I do?

If there’s something you need to know which isn’t documented please submit a Service Desk ticket. We’d be happy to answer your question there and we can update the documentation as part of our continuous improvement.