How to deploy Strapi with a Gatsby frontend on Platform.sh

Platform.sh maintains a template that you can quickly deploy, and then use this guide as a reference for the Platform.sh specific changes that have been made to Gatsby and Strapi to make it work. Click the button below to sign up for a free trial account and deploy the project.

Shared configuration

Your local clone of the template has the following project structure:

├── .platform
│   ├── routes.yaml
│   └── services.yaml
├── strapi
│   ├── # App code
│   └── .platform.app.yaml
├── gatsby
│   ├── # App code
│   └── .platform.app.yaml
└── README.md

From this repository, you deploy a Gatsby app and a Strapi app. The code for each of them resides in their own directories. When deploying a single app project such as Gatsby, the repository needs three configuration files that describe its infrastructure, described below in detail. For multi-app projects, two of those files remain in the project root and are shared between Gatsby and Strapi. Each app keeps its own app configuration file (.platform.app.yaml) in its subdirectory.

Service configuration

This file describes which service containers (such as a database) your project should include. Gatsby does not require services to deploy, but Strapi does. So the following examples shows these service configurations:

Routes configuration

This .platform/routes.yaml file defines how requests are handled by Platform.sh. The following example shows Gatsby being served from the primary domain and Strapi being accessible from the backend subdomain.

Strapi

The multi-app template has a single modification to Platform.sh’s standard Strapi template: the name attribute in Strapi’s .platform/services.yaml has been updated to strapi. This value is used to define the relationship between Gatsby and Strapi and in the routes configuration.

The only additional setup required to prepare the backend is to install a package that enables GraphQL on Strapi.

In your Strapi directory, add the dependency:

yarn add strapi-plugin-graphql

Gatsby

The frontend Gatsby app has a slightly different configuration from the basic Gatsby deployment. Below is the gatsby/.platform.app.yaml file that configures the app.

In particular, notice:

• relationships

  Access to another service or app container in the cluster is given through relationships. In this case, one has been defined to the backend Strapi container using it’s name.

• post_deploy

  Platform.sh containers reside in separate build containers at build time, before their images are moved to the final app container at deploy time. These build containers are isolated and so Gatsby can’t access Strapi during the build hook, where you would normally run the gatsby build command. Strapi isn’t available until after the deploy hook. So the Gatsby build is postponed until the post_deploy hook.

  To run gatsby build on-demand, or to trigger a rebuild from the backend when content is updated, define a runtime operation.

• mounts

  There are consequences to postponing the Gatsby build, as you don’t generally have write access to the container this late in the pipeline. To allow Gatsby to write to public, that directory has been defined as a mount.

You can then modify gatsby-config.js to read from the backend Strapi container through the strapi relationship defined above to configure the apiURL attribute for gatsby-source-strapi. Notice that the source plugin requires that you explicitly define the contentTypes you would like to retrieve from Strapi. At this point you have not built out the API, and the Content Types article and category are included to support the post-install instructions outlined in the template’s README. Adjust these values to fit your current API if your are planning on migrating an existing Strapi repository.

This is facilitated by Platform.sh’s Config Reader library. So be sure to install this to the Gatsby dependencies first when replicating. When used, Gatsby pulls the information to communicate with the Strapi container on the current branch.

Lastly, the Gatsby app itself needs to include GraphQL queries to handle the data coming from Strapi and create content pages. The most important files in the template you should consult are:

• gatsby/gatsby-node.js

  Dynamically creates individual pages from the data source using Gatsby’s Node API. It retrieves all of Strapi’s articles and categories (see post-install below) using the GraphQL queries allStrapiArticle and allStrapiCategory respectively. For each, a page is created (createPage) with an assigned path and formatting described by one of the template files below (component).

• gatsby/src/templates/article.js

  The template file that defines how a single Strapi article should be formatted on Gatsby, retrieving the data from that article using the strapiArticle GraphQL query.

• gatsby/src/templates/category.js

  The template file that defines how a list of articles that belong to a single Category are formatted by Gatsby. It uses the Category query, and then filters a specific category id on allStrapiArticle.

• gatsby/src/pages/index.js

  Retrieves all of Strapi’s content to generate a list of articles on the homepage using the allStrapiArticle GraphQL query.

Deploy and post-install

Next steps

With Gatsby now deployed and pulling content from a backend Strapi application, there are a few things you may wish to change about your project going forward.

Shared application configuration

You can optionally combine the application configuration (.platform/services.yaml) for Gatsby and Strapi into a single configuration file. Like .platform/services.yaml and .platform/routes.yaml, this file is shared across the project and resides in the .platform subdirectory. You need to explicitly define the source of each application.

Multiple content sources

Gatsby supports pulling multiple sources into its build. This can include external services like Stripe, or additional backend CMSs for different sets of content. Like shown here with Strapi, you can branch off your repository and add an additional subdirectory that contains the codebase for another frontend.

Plan size

As mentioned previously, you should have at least a Medium plan for your multi-app projects. This size gives the project enough resources for all of your containers as well as the memory necessary to actually pull content from Strapi into Gatsby during its build.

Keep in mind that the increased plan size applies only to your production environment, and not to preview environments (which default to Standard ). As you continue to work with Gatsby and a backend headless CMS, you may want to upsize your preview environments.