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, MySQL 8.0 is the default database engine available.
Existing environments that are on 5.7, please submit a Service Desk ticket to upgrade.
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 to 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, please submit 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:
---
Only:
environment: 'dev'
---
DeveloperToolbar:
show: trueIt's 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?
By default, deployments are restricted to some roles. If other members of the team require permission to deploy, the Stack Manager can provide a role that has this ability. 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 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": "[email protected]: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:
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.
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.
Otherwise you will need to contact your Stack Manager or Service Desk for help.
Note, if you are pointing your stack to private git hosts over SSH other than github.com, code.silverstripe.cloud, or bitbucket.org, Service Desk will need to approve this first. Proceed with the setup as normal, then contact Service Desk specifying the hostname. Until this is completed, your code fetches will fail. Service Desk will also provide you with the list of IP addresses to whitelist, if your git host restricts traffic.
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 you can emulate Cloud’s distributed sessions by installing the Hybrid Sessions module.
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.
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.
Can I use symlinks in my codebase?
The usage of symlinks in your deployed repository is disallowed for security reasons. Files checked in as symlinks will appear to be missing from the deployed webroot.
I am getting 404s for GraphQL in CMS Admin
Silverstripe Cloud uses a multi-server setup for environments which can sometimes affect how the application behaves. GraphQL recommends specific considerations for multi-server configurations which if not configured correctly, could result in errors in your application such as 404 (Not Found) errors for files in the /_graphql/ directory.
For Silverstripe Cloud, it is recommended to included the GraphQL data in your deployed application through committing the schema to version control, or building the schema during/before deployment using a custom CI integration with package deployments. These solutions ensure the necessary files are available on all servers.
My question isn’t answered here. What do I do?
If there’s something you need to know which isn’t documented here, 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.