Web server configuration

Silverstripe Cloud uses a combination of webservers for improved performance. Web server settings that affect both Apache and nginx use the http_settings .platform.yml option for changing configuration that affects both web servers, for example:

http_settings:
  max_upload_size: '128' # This value will be converted into MB
  timezone: 'Europe/London'

The max_upload_size setting will adjust PHP and nginx limits accordingly to increase the maximum upload size for your stack. This will also increase the post_max_size in PHP, so there is no need to change that setting as well. The max upload size by default is 16MB if not configured in the .platform.yml or in your site code. 

Note that this setting will not work if the PHP INI settings for upload_max_filesize and post_max_size have been changed in .htaccess or calls to ini_set in your site code. We don't recommend using either of these methods for setting config from code.

The timezone setting will adjust the PHP date.timezone setting, the system timezone of the host machine, and the SS_DATABASE_TIMEZONE configuration in the environment file.

Please see the PHP documentation for a list of valid timezones. Please also be aware that these settings will apply across all virtual stacks on the environment.

Apache-specific settings

Apache prefork settings can be tuned by setting the following:

apache:
  prefork:
    startservers: 3
    minspareservers: 2
    maxspareservers: 5
    maxclients: 30
    serverlimit: 30
    maxrequestsperchild: 10000

See Apache MPM prefork docs for more information on individual settings above.

URL rules

As a rule of thumb, media files and assets are served directly by nginx by default, while everything else is passed to Apache/PHP. Media file and assets served by nginx include:

• CSS
• JavaScript
• Images (JPG, PNG, GIF, BMP, ICO, SVG)
• Plain-text files (TXT, HTM, HTML)
• Fonts (WOFF, WOFF2, OTF, TTF, EOT)

URL rules allow you to customise this behaviour and choose where requests to a certain path or file are routed. This can aid in improving the performance of your website or ensuring that certain paths are processed through your website code.

When defining rules, “mysite” to denote base stack, but the rules can be defined for virtual stacks too. There is a limit of 49 rules for the base stack and each virtual stack.

url_rules:
  mysite:
    - '<regex>': '<rule>'
    - '<regex>': '<rule>'
    - ...
  <virtual stack name>:
    - '<regex>': '<rule>'
    - '<regex>': '<rule>'
    - ...

The regex must be in a format accepted by nginx. This will be used as a case-insensitive location matcher and is compared against the full URL - some examples are provided in the table below. For a better explanation of what this means, please see Nginx location docs.

• \.(gif|jpg|jpeg)$ - match extensions at the end of the URL
• ^/assets/ - match all URLs pointing to the assets directory

Each URL must be accompanied by one of the following rules:

• apache - requests are passed through to Apache. If they were previously served by nginx, they will now be several orders of magnitude slower, but .htaccess will be respected.
• nginx - Nginx will attempt to serve these URLs directly from disk. This is a rule normally associated with assets and media files.
• deny - deny all access through nginx.
• nginx-with-passthrough - nginx will attempt to serve these URLs directly from disk, if the file is not found it will be served by Apache. Note that this means all 404s from the specified directory will be served by Apache which can be bad for performance.

Example: set up base stack to use secure assets, and myvstack to deny access to a hidden file:

url_rules:
  mysite:
    - '^/assets/': 'apache'
  myvstack:
    - '^/assets/secretassets/topsecretfile.pdf: 'deny'