Configure Strapi for Platform.sh

You now have a project running on Platform.sh. In many ways, a project is just a collection of tools around a Git repository. Just like a Git repository, a project has branches, called environments. Each environment can then be activated. Active environments are built and deployed, giving you a fully isolated running site for each active environment.

Once an environment is activated, your app is deployed through a cluster of containers. You can configure these containers in three ways, each corresponding to a YAML file:

• Configure apps in a .platform.app.yaml file. This controls the configuration of the container where your app lives.
• Add services in a .platform/services.yaml file. This controls what additional services are created to support your app, such as databases or search servers. Each environment has its own independent copy of each service. If you’re not using any services, you don’t need this file.
• Define routes in a .platform/routes.yaml file. This controls how incoming requests are routed to your app or apps. It also controls the built-in HTTP cache. If you’re only using the single default route, you don’t need this file.

Start by creating empty versions of each of these files in your repository:

# Create empty Platform.sh  configuration files
mkdir -p .platform && touch .platform/services.yaml && touch .platform/routes.yaml && touch .platform.app.yaml

Now that you’ve added these files to your project, configure each one for Strapi in the following sections. Each section covers basic configuration options and presents a complete example with comments on why Strapi requires those values.

Configure apps in .platform.app.yaml

Your app configuration in a .platform.app.yaml file is allows you to configure nearly any aspect of your app. For all of the options, see a complete reference. The following example shows a complete configuration with comments to explain the various settings.

In the Strapi template, yarn is run during the build hook to install all of Strapi’s dependencies, and then yarn build is run to build the site. If you would rather use npm to manage your dependencies, you can:

1. Delete yarn from the build hook.
2. Replace yarn build in the build hook with npm run build.
3. Delete the build.flavor block. When this is set to none, Platform.sh to rely solely on the build hook to define the build process. By default, Node.js containers run npm install prior to the build hook, so this block can be removed entirely from the configuration.
4. Delete the dependencies block, which includes yarn.

The relationships block is responsible for providing access to the data sources (services) that the Strapi application needs.

Since Platform.sh is read-only during build, mainly for security purposes, certain folders need to be mounted. Platform.sh allows you to mount directories that need write access during the deploy phase with the mounts key. In this case, the following folders are mounted for Strapi.

• .cache file
• .tmp file
• database folder
• extensions folder
• uploads folder in the public directory

Add services in .platform/services.yaml

You can add the managed services you need for you app to run in the .platform/services.yaml file. You pick the major version of the service and security and minor updates are applied automatically, so you always get the newest version when you deploy. You should always try any upgrades on a development branch before pushing to production.

Strapi requires a database to deploy. By default, it uses a SQLite database but other database types are also supported. These other database types are Oracle MySQL, PostgreSQL, or MongoDB (available only in Strapi v3 and below). The Strapi template defines a PostgreSQL database service. To use another service, replace postgresql:12 in the example below with the name and version of the database you want.

You can add other services if desired, such as Solr or Elasticsearch. You need to configure to use those services once they’re enabled.

Each service entry has a name (db in the example) and a type that specifies the service and version to use. Services that store persistent data have a disk key, to specify the amount of storage.

# The services of the project.

# Each service listed is deployed
# to power your Platform.sh project.

db:
  type: postgresql:12
  disk: 256

# Uncomment the line below to use a MySQL database
# dbmysql:
#   type: oracle-mysql:8.0
#   disk: 256

Define routes

All HTTP requests sent to your app are controlled through the routing and caching you define in a .platform/routes.yaml file.

The two most important options are the main route and its caching rules. A route can have a placeholder of {default}, which is replaced by your domain name in production and environment-specific names for your preview environments. The main route has an upstream, which is the name of the app container to forward requests to.

You can enable HTTP cache. The router includes a basic HTTP cache. By default, HTTP caches includes all cookies in the cache key. So any cookies that you have bust the cache. The cookies key allows you to select which cookies should matter for the cache.

You can also set up routes as HTTP redirects. In the following example, all requests to www.{default} are redirected to the equivalent URL without www. HTTP requests are automatically redirected to HTTPS.

If you don’t include a .platform/routes.yaml file, a single default route is used. This is equivalent to the following:

https://{default}/:
  type: upstream
  upstream: <APP_NAME>:http

Where <APP_NAME> is the name you’ve defined in your app configuration.

The following example presents a complete definition of a main route for a Strapi app:

Back Deploy Strapi